Hello,
To avoid having a meeting in the middle of all those pumpkins, it has
been decided that there would not be any meeting this week. The next
one would then be the 8th of November but at 17:00 UTC (9am PST, 6pm
CET).
The list of topics will be available here:
https://annuel2.framapad.org/p/mptcp_upstreaming_20181108
Feel free to add/modify topics!
Have a good week,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

Hello,
We just had our 26th meeting with Mat, Peter and Ossama (Intel OTC),
Christoph (Apple) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
podcast:
- Invited to participate to
https://www.ipspace.net/Podcast/Software_Gone_Wild/About
- after the 19th of November (but still at 7AM :-D )
- With Mat and Christoph (Matthieu as backup if they don't wake up!
:-D )
Design:
- new page by Mat:
https://github.com/multipath-tcp/mptcp_net-next/wiki/Design#api-design
- sock = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP);
- IPPROTO_MPTCP: Various combinations of AF_INET, AF_INET6, and
the IPV6_V6ONLY socket option provide a way to control v4/v6 selection
for the initial subflow and whether later subflows may be mixed v4/v6.
- important: we could also use BPF to force IPPROTO_MPTCP (or
AF_MULTIPATH) not to modified other apps
tests:
- netdevsim: not for us, for hardware devs, at least for the moment
- packetdrill:
- no news
- Intel team might participate, just some admin stuff to do before
tools: gerrit
- http://gerrithub.io/
- had some issues but should be fixed on the service side
- Matth: I can do a demo next week. Same for Topgit
Mat:
- worked on a new RFC version of the patch-set
- when pushing on kernel.org, there are automated build checking
things → Mat fixed some warnings generated by this service
Peter:
- working on not "exposing" IPPROTO_TCP_SUBFLOWS to userspace
- found a way with ULP, not too much changes!
- will be shared soon
Christoph:
- continuing the cleaning, working on that
Ossama:
- still in the process of releasing the userspace code
Matth:
- progress on testing mptcp_trunk
- progress on creating a new release based on v4.9 kernel
Next meeting:
- We propose to have it on Thursday, the 25th of October. Usual
time: 9am PDT - 16:00 UTC (9am PDT, 6pm CEST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20181025
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

Hello,
We just had our 25th (\o/) meeting with Mat, Peter and Ossama (Intel
OTC), Christoph (Apple) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Review of Mat & Peter's patches:
- IPPROTO_MPTCP vs AF_MULTIPATH:
- We should document the advantages/disadvantages of each (*Mat*
will try to have a look at that)
- Not an issue to switch from one to another if needed later.
- get rid of SKB's priv_copy()
- we can remove it, it depends who will need it
- difficult what other might need. Maybe better to start simple
with not too much flexibility.
- we will then remove the priv_copy() but we need to keep the
destructor()
- receiving part: DSS mapping: error_queue → dedicated queue? or
only for the signalling?
- Christoph: maybe difficult to manage that in queue.
- maybe using tcp_read_sock()
- we will always need an ofo_queue
- DSS ACK not driven by the app in theory (like TCP) but we
could ignore that for the moment?
- we can manage optimisation later
- what is important is something easy to maintain and understand
for the moment, keep it simple by using the right available structures.
- we can read data from one subflow as long as it is in order
and then switch to the other subflows.
- we need to be careful with the windows: the new window is
checked at every ACK but we need to know when to increase it. First
solution could be to stall the window, close it, then increase it.
- MPTCP: windows are shared between SF, if we share the memory
equally between subflows, that's not the best when a SF contains crap.
- decision: take the error_queue out
- receiving part: bypass coalesce/collapse for MPTCP OR do
coalescing that takes DSS-mappings into account → priv_used is the
perfect infrastructure for that.
- linked to the previous point.
- smart coalesce can be useful for kTLS
- trigger the closing in the right sequence → First, we need to
close the MPTCP-layer and then the subflows.
- optimisation can be done later to close both at the same time
- it is for the last data that need to be sent if you close the
subflows first but still some data coming.
- Christoph will try to find an article to give more details
about that →
https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-12#section-3.3.3
"Essentially, a host MUST NOT close all functioning subflows
unless it is safe to do so, i.e., until all outstanding data has been
DATA_ACKed, or until the segment with the DATA_FIN flag set is the only
outstanding segment."
- prepend MPTCP_ / mptcp_ everywhere → subflow, token, crypto, etc.?
- everything visible should be prepended.
- subflow socket type:
- we could keep a TCP proto but modify the pointers where
needed. We should check how it is done with kTLS.
- we don't want to have the userspace creating a subflow
directly → by using IPPROTO_SUBFLOW
- So overriding pointers would make sense. It is a special proto
for MPTCP, kernel side only.
testing MPTCP:
- packetdrill: no more news from Neil (see the discussions we had
last week)
- netdevsim?
- Seems oriented for drivers devs:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Networking
- we need to check if it can be useful for us → Matt will do that
tools: start using TopGit?
- maybe too soon for our repo
- would be nice to already do some experiments with that:
https://github.com/mackyle/topgit
- once Mat and Peter's patches are accepted maybe
- we can do that later
tools: use Gerrit for the reviews?
- http://gerrithub.io/
- can be helpful, easier to keep track on stuff than with a ML
because there might be a lot of discussions around patches for this project.
- Matth will have a look at this
- (still possible to keep both, we can quickly experiment)
Next meeting:
- We propose to have it on Thursday, the 18th of October. Usual
time: 9am PDT - 16:00 UTC (9am PDT, 6pm CEST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20181018
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium