Re: Draft talk proposal for MPTCP @ Linux Plumbers '22 (2nd draft)

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

After some discussion at out last couple of weekly meetings, here's an 
updated draft.

Changes:

  * Moved BPF section up (before userspace PM)
  * Emphasized interactive discussion for BPF issues we've been trying to 
resolve, like the BPF/kernel API.
  * General edits

Suggestions, edits, feedback, etc, all welcome!


---

Multipath TCP (MPTCP) was initially supported in v5.6 of the Linux kernel. 
In later releases, the MPTCP development community has steadily expanded 
from the initial baseline feature set to now support a broad range of 
MPTCP features on the wire and through the socket and generic netlink 
APIs. Two current projects are intended to make MPTCP more customizable 
for client devices and unique use cases without requiring custom kernel 
modules.

One of these projects is the BPF MPTCP packet scheduler framework. When 
there are multiple active TCP subflows in a MPTCP connection, the MPTCP 
stack must decide which of those subflows to use to transmit each data 
packet. The default in-kernel scheduler tries to utilize all the available 
subflows to favor throughput, but it is not tunable. Customizable 
schedulers can optimize for latency, redundancy, cost, carrier policy, or 
other factors. We have patches implementing a proof-of-concept BPF packet 
scheduler, and hope to discuss with the netdev/BPF maintainers and 
audience how we might best structure the BPF/kernel API to balance 
long-term API stability, future evolution of MPTCP scheduler features, and 
usability for scheduler authors.

The next customization feature is the userspace path manager added in 
v5.19. On the kernel side, MPTCP's generic netlink API has new commands 
that allow a userspace process to control multipath address advertisements 
and the additional subflows that add paths to a MPTCP connection. The 
Multipath TCP Daemon (mptcpd) is the first userspace daemon to support 
these commands. With these components, systems can now customize MPTCP 
behavior on a per-connection basis. The in-kernel path manager, which is 
enabled by default, only has per-namespace configuration. We will show 
what the userspace and in-kernel path managers are best suited for and 
explain the tradeoffs between them.

MPTCP development for the Linux kernel and mptcpd are public and open. You 
can find us at mptcp@lists.linux.dev, https://mptcp.dev, and 
https://github.com/intel/mptcpd


--
Mat Martineau
Intel