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

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

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

On Fri, 15 Jul 2022, Matthieu Baerts wrote:

> Hi Mat,
>
> On 15/07/2022 00:50, Mat Martineau wrote:
>>
>> 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
>
> Thank you for this v2!
>
> This looks really good. I have one general comment below:
>
>> 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.
>
> Should we insist on the fact that these discussions are not specific to
> MPTCP but this is more general and MPTCP is used as one typical use-case?
>
> I would suggest to explain that before this 2nd paragraph. Maybe saying
> that we are trying to get answers to questions like: what's the
> recommended way to extend a subsystem(?)? The recommended ways seems to
> be with BPF and Netlink and they both have limitations. allowing
> customisations with BPF bring more questions for us, e.g.: what about
> long-term API stability and other questions you raised here at the end.
>
> Then we can introduce the two use cases. The first one with the Packet
> Scheduler where we need something on the kernel side as it is a decision
> to take per packet. There are some uncertainties when using BPF but a
> proof-of-concept implementation exists.
>
> Then for the Path Manager, the decision can be done from the userspace
> because the communications are per connections and not per packet. So
> this is a another use-case where exposing a Netlink API seems to be a
> good fit (even if there are some limitations if there is a very high
> number of connections to deal with).
>
> We can then compare BPF and Netlink and trying to get answers to our
> questions.
>
> What do you think?
>

I think that's a good way to frame the talk: emphasizes that the content 
can be useful for understanding general ideas about extending/customizing 
kernel functionality, and also cover what we've done in MPTCP for these 
two cases. I'll update the draft and post a v3 on Monday.


--
Mat Martineau
Intel