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-Networ... - 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