Draft talk proposal for MPTCP @ Linux Plumbers '22

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

At our recent weekly MPTCP meetings, I've talked about proposing a Linux 
Plumbers talk this year. Matthieu and I have discussed collaborating on 
it.

My high-level idea was to focus on our new customization features: 
userspace path management and BPF packet schedulers.

Since MPTCP is a community effort, I'd like to share this draft so I 
can be sure to focus in the right areas and represent the community well. 
Please review and comment!

Side note: I've included the https://mptcp.dev URL even though it's not 
working yet. Matthieu, do you think we could get something set up there 
before September? The old https://is.gd/mptcp_upstream URL we used for the 
2019 talk doesn't work any more.

----

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. The first phase of development focused on solid support of server 
use cases. Two current projects are intended to make MPTCP more 
customizable for client devices and unique use cases without requiring 
custom kernel modules.

The first of these customization features is the userspace path manager 
added in v5.19. On the kernel side, MPTCP's generic netlink API was 
updated with new commands that allow a userspace process to control 
multipath address advertisements and the additional subflows that can 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 remains available, has configuration options 
that affect all connections in a network namespace. We will show what the 
userspace and in-kernel path managers are best suited for and explain the 
tradeoffs between them.

A BPF packet scheduler framework is also in active development. 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 is not tunable. Customizable schedulers 
could optimize for latency, redundancy, cost, carrier policy, or other 
factors. We will review the progress that MPTCP Linux developers have made 
on this feature to date, along with some of the challenges of integrating 
BPF into the MPTCP transmit path.

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