Re: Draft talk proposal for MPTCP @ Linux Plumbers '22 (3rd draft)

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

Here's a new draft based on Matthieu's feedback for v2 
(https://lore.kernel.org/mptcp/7cd436ad-6c05-d788-7af3-2ff08d647dfd@tessares.net/).

The main goal was to frame the proposal as an illustration of tradeoffs 
between different kernel extensibility options (BPF & genl).


---

Multipath TCP (MPTCP) was initially supported in v5.6 of the Linux kernel. 
In subsequent 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.

With core MPTCP functionality established, our next goal is to make MPTCP 
more extensible and customizable at runtime. The two most common tools in 
the kernel's networking subsystem for these purposes are generic netlink 
and BPF. Each has tradeoffs that make them better suited for different 
scenarios. Our choices for extending MPTCP show some of those tradeoffs, 
and also leave our community with some open questions about how to best 
use these interfaces and frameworks.

As one example, we are extending the MPTCP packet scheduler using BPF. 
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. This requires low latency and low overhead, and direct access 
to low-level TCP connection information. 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. MPTCP path managers advertise addresses available for multipath 
connections, and establish or close additional TCP subflows using the 
available interfaces. There are a limited number of interactions with a 
path manager during the life of a MPTCP connection. Operations are not 
very sensitive to latency, and may need access to data from userspace. 
This led us to expand the MPTCP generic netlink API and update the 
Multipath TCP Daemon (mptcpd) to support the new commands. Generic netlink 
has been a good fit for path manager commands and events, the concepts are 
familiar and the message format makes it possible to maintain forward and 
backward compatibility between different kernel versions and userspace 
binaries.

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