May 2018 - mptcp - Ml01.01.Org

by Mat Martineau

Hello - We had a meeting last week to discuss reshaping our netdev conference MPTCP talk proposal based on feedback from the committee. The plan is to re-focus on upstreaming concerns, challenges, and progress. I worked on outlining some topics that might fit with the talk. I don't think this is exhaustive, and I'm also not saying everything here is required to be in the talk. I'm looking forward to your comments and additional ideas. * Why is adding MPTCP to the upstream kernel complicated? * Differences in requirements and features from existing implementation * Every TCP socket affected vs. staying out of the way for normal TCP * Multipath protocol development and research vs giving TCP users/maintainers weight * Protocol challenges * Coupled receive windows across TCP subflows * Behavior change for duplicate acks * Per-packet metadata (tx path) and option writing * TCP option parsing - packets are currently dropped after options are parsed * Collapse/coalesce of skbs after receive - per-packet headers lost in TCP layer * Must do all this without adversely affecting TCP or networking structs (like sk_buff) * TCP performance not reduced * Memory requirements for TCP not increased * Maintainability not made harder * Compare to KCM, which adds metadata to each stream, didn't require TCP changes * What fits well in the networking subsystem * Some connection code (callbacks exist) * Creating a new socket type for MPTCP * New ULP capability * No rules yet for multiple users, because TLS is the only user * In-kernel sockets * do_tcp_sendpages() to send data buffered at the connection level * tcp_read_sock() to get incoming skbs * What's a challenge in the networking subsystem * Indirect calls are now more expensive * MPTCP builds on TCP in a unique way * What we have tried * Identify where other features could use TCP extension capabilities and merge before MPTCP * Options framework used by TCP-MD5 and SMC * Didn't work out - expensive indirect calls and no MPTCP frame of reference for the maintainer * Sharing code demonstrating architectural approaches that use current upstream netdev functionality * Moving components to userspace * Forking and reducing functionality of existing MPTCP code base * Large change logistics * Reshaping code in to a reviewable patch set or patch sets. Implement functionality in stages? * Fundamental challenge of "show us the code" - must decide what seems upstreamable, implement it, share, and iterate. Thanks, -- Mat Martineau Intel OTC

4 years, 1 month

3
6
0 / 0

[Weekly meetings] MoM - 8th of May 2018

by Matthieu Baerts

Hello, We just had a short and improvised meeting dedicated to the Netdev presentation we would like to do in July this year. Because we also decided that there will not be our usual meeting on Thursday this week, we can say that it was our 9th weekly meeting with Mat, Peter, Ossama (Intel OTC), Christoph (Apple) and myself (Tessares). Thanks again for having accepted to participate to this improvised but useful meeting! Here are the minutes of the meeting: Why we had this meeting: We got a reply from the program committee asking us some questions about our proposal. They are mainly concerned about not having the same talk as Octavian presented at Netdev 0.1 and if we already addressed the different comments raised during the call. But also they think it would be more interesting to discuss about the challenges/progress instead of a tutorial and use-cases. Octavian's call: There were mainly questions about the protocol but also a bit about PM and schedulers, not a lot about the upstreaming bit. We don't think we really need to list the progressions that was made but mention that the talk will be different. Questions related to the upstream bits were taken into account but we still need more feedback. kind of discussion: TCP options' framework → what we learned from that. We develop something but it was not well understood/supported/... kind of discussion: how to integrate a big kernel change, cannot be completely outside of the core system. Tutorial: we should avoid talking about the protocol to focus the discussions on the upstreaming bit we agree to switch to a "moonshot" talk and focus on challenges / progress. For the talk, not the email: mention that these conferences are the only occasions for us to talk with maintainers and main developers. Mat kindly accepted to look at writing a new description in that way. We would finish this email by saying something like: Do you think it is the right way to go? If yes, we will come back to you with a proper proposal next week. Next meeting: - proposition: the 17th of May. Usual time: 16:00 UTC (9am PDT, 6pm CEST) - open to everyone! - https://annuel2.framapad.org/p/mptcp_upstreaming_20180517 Feel free to comment these points and propose new ones for the next meeting! Talk to you in two weeks, 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 -- DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

4 years, 1 month

1
0
0 / 0

Netdev planning call: 08-May-2018 11:30AM PDT

by Mat Martineau

Hello - We will have a short call today (about 70 minutes from now) to discuss the feedback we got from the Netdev committee and refining our talk proposal. Use the normal web conference URL: https://talky.io/mptcp_upstreaming Sorry for the short notice, we are hoping to respond to the committee soon. -- Mat Martineau Intel OTC

4 years, 1 month

1
0
0 / 0

Updated net-next merge

by Mat Martineau

Hello everyone - I updated the master branch at https://github.com/multipath-tcp/mptcp_net-next There were no complicated merge conflicts this time, and just one minor fixup commit. I plan to merge with net-next about once a week. -- Mat Martineau Intel OTC

4 years, 1 month

1
0
0 / 0

[Weekly meetings] MoM - 3rd of May 2018

by Matthieu Baerts

Hello, We just had our 8th meeting with Mat, Peter, Ossama (Intel OTC), Christoph (Apple) and myself (Tessares). Thanks again for this new good meeting! Here are the minutes of the meeting: Next Thursday: - Some people will not be able to participate next week, we will see the day before if we need to have one next week. netdevconf: - tutorial proposal has been sent, waiting for an answer. - Who will be there: - Mat needs to wait for the beginning of June before getting an approval - Mat and / or Peter will try to participate, they hope having at least one of them there, maybe the 2 of them! - Christoph will be there and he will officially represent Apple - Matthieu still needs the approval, should get an answer before the next meeting - If we are accepted, we need to send slides before the end of June. Something we need to keep in mind. Ref: https://www.netdevconf.org/0x12/submit-proposal.html subflow lockless patches (from Christoph): - merged in mptcp_trunk - Christoph is looking at proposing them to mptcp_net-next but he is currently facing issues with the establishment of subflows, maybe not due to these patches, maybe due to the previous cleaning or a merge, someone needs to check that. mptcp_net-next: - Christoph is looking at doing more cleaning of features (simplifications) but only in this repo, not mptcp_trunk because it seems it is going to reduce performances. - We will certainly have to cherry-pick new bug-fixes from mptcp_trunk, will be tricky to merge these branches once we add new feature in mptcp_trunk - We could only support the v1 (MPTCP spec) in net-next. But mptcp_trunk doesn't fully support v1 yet, we hope having this support soon. Mat and Peter patches: - First step is to have it working on top of net-next - Then switch to mptcp_net-next - Note that it is not possible to establish more subflows for the moment so this part needs to be fixed first Next steps: - All: We hope to get an answer for Netdevconf before the next meeting, nothing else we can do about that - Mat & Peter: looking at the v2 of their patches - Mat: sync mptcp_net-next / look at Christoph's patches to reduce footprint in mptcp_net-next - Christoph: work on the input path in mptcp_net-next: consolidate the processing, window handling would be a bit tricky, maybe we can sacrifice some perfs to simplify the design → how much we can re-design that: to be discussed when the patches or an early design will be proposed - Peter: Will look at having additional subflows in net-next - Ossama: look at a userspace Open-Source code to use the Open-Source Netlink PM - Matthieu: propose a v2 for the PM Netlink, should not change the API, good point for Ossama. - As usual, update the wiki if there are new stuffs to put in! Next meeting: - proposition: the 17th of May except if there are stuff to discuss on the 10th of May. Usual time 9am PDT - 16:00 UTC (9am PDT, 6pm CEST) - open to everyone! - https://annuel2.framapad.org/p/mptcp_upstreaming_20180510 - https://annuel2.framapad.org/p/mptcp_upstreaming_20180517 Feel free to comment these points and propose new ones for the next meeting! Talk to you in two weeks, 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 -- DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

4 years, 1 month

1
0
0 / 0

Weekly meeting - 3 May 2018 16:00 UTC (9am PDT, 6pm CEST)

by Matthieu Baerts

Hello, Our public MPTCP upstreaming weekly web conference is scheduled for tomorrow. The list of topics is here: https://annuel2.framapad.org/p/mptcp_upstreaming_20180503 Feel free to add/modify topics! Meeting link: https://talky.io/mptcp_upstreaming Speak to you tomorrow! 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 -- DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

4 years, 1 month

1
0
0 / 0

[PATCH 00/12] Make subflow establishment lockless

by Christoph Paasch

The most recent TCP stack supports lockless listeners. For MPTCP, we however are still taking the meta-lock when creating new subflows (cfr., tcp_v4_rcv and mptcp_lookup_join). This patchset makes subflow establishment lockless by using lockless procedures in the stack, RCU-lists, atomic operations,... Christoph Paasch (12): mptcp: Cleanup mptcp: Improved debugging mptcp: Use correct tcp_queue when calling mptcp_fragment mptcp: Use mptcp_can_new_subflow where possible mptcp: Render mptcp_sub_inherit_sockopts lockless mptcp: Make mptcp_set_new_pathindex lockless mptcp: Remove cnt_subflows mptcp: Remove cnt_established mptcp: Rename tw_lock to mpcb_list_lock mptcp: Make subflow-list an RCU-list mptcp: Don't take meta-lock when receiving third ACK mptcp: Make mptcp_do_join_short and mptcp_lookup_join lockless include/net/mptcp.h | 120 ++++++++++----------------- net/ipv4/af_inet.c | 9 ++- net/ipv4/ip_sockglue.c | 7 +- net/ipv4/tcp.c | 31 ++++--- net/ipv4/tcp_ipv4.c | 41 +--------- net/ipv4/tcp_minisocks.c | 9 ++- net/ipv6/tcp_ipv6.c | 41 +--------- net/mptcp/mctcp_desync.c | 22 ++--- net/mptcp/mptcp_balia.c | 21 ++--- net/mptcp/mptcp_binder.c | 23 +++++- net/mptcp/mptcp_coupled.c | 52 +++++------- net/mptcp/mptcp_ctrl.c | 187 ++++++++++++++++++++++++++++--------------- net/mptcp/mptcp_fullmesh.c | 30 ++++--- net/mptcp/mptcp_input.c | 150 ++++++++++++---------------------- net/mptcp/mptcp_ipv4.c | 34 +++----- net/mptcp/mptcp_ipv6.c | 15 ++-- net/mptcp/mptcp_ndiffports.c | 17 +++- net/mptcp/mptcp_olia.c | 28 ++++--- net/mptcp/mptcp_output.c | 50 ++++++++---- net/mptcp/mptcp_redundant.c | 151 +++++++++++++++++++++++++++------- net/mptcp/mptcp_rr.c | 22 +++-- net/mptcp/mptcp_sched.c | 32 ++++---- net/mptcp/mptcp_wvegas.c | 5 +- 23 files changed, 586 insertions(+), 511 deletions(-) -- 2.16.2

4 years, 1 month

2
29
0 / 0

[PATCH mptcp-net-next] tcp/mptcp: Purge write-queue of the sk not meta_sk in tcp_abort()

by Christoph Paasch

tcp_abort terminates a specific subflow (e.g., when the interface goes down). However, in tcp_abort() we should not purge the write-queue of the meta-sk but of the sk that we are removing. Fixes: 16b5a42fd18e ("Merge branch 'net-next/master'") Signed-off-by: Christoph Paasch <cpaasch(a)apple.com> --- net/ipv4/tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index eaa32600fe63..eeb98619b181 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -3932,7 +3932,7 @@ int tcp_abort(struct sock *sk, int err) bh_unlock_sock(meta_sk); local_bh_enable(); - tcp_write_queue_purge(meta_sk); + tcp_write_queue_purge(sk); release_sock(meta_sk); return 0; } -- 2.16.2

4 years, 1 month

2
1
0 / 0

[PATCH mptcp-net-next 0/9] Remove some MPTCP-modules

by Christoph Paasch

I had a bit of time, so just went through the code and removed some modules. These patches are based off of the mptcp-net-next repo's master. I would like to get rid of fullmesh/ndiffports as well, but need to see if I can do it such that I can run the net-next kernel on the server-side and still have my test-scripts succeed. Also, a next series could get rid of the scheduler module-selector. 2500 lines of code gone! ;-) Christoph Paasch (9): mptcp: Remove Balia congestion control mptcp: Remove wVegas congestion control mptcp: Remove OLIA congestion control mptcp: Remove Coupled congestion control mptcp: Remove MCTCP Desync congestion control mptcp: Remove Redundant scheduler mptcp: Remove RoundRobin Scheduler mptcp: Remove Binder Path-Manager mptcp: Cleanup after removals include/net/mptcp.h | 12 +- net/ipv4/Kconfig | 45 ---- net/mptcp/Kconfig | 40 +--- net/mptcp/Makefile | 8 - net/mptcp/mctcp_desync.c | 189 ----------------- net/mptcp/mptcp_balia.c | 268 ------------------------ net/mptcp/mptcp_binder.c | 486 -------------------------------------------- net/mptcp/mptcp_coupled.c | 271 ------------------------ net/mptcp/mptcp_ctrl.c | 3 - net/mptcp/mptcp_ipv4.c | 3 - net/mptcp/mptcp_ipv6.c | 3 - net/mptcp/mptcp_olia.c | 310 ---------------------------- net/mptcp/mptcp_redundant.c | 301 --------------------------- net/mptcp/mptcp_rr.c | 301 --------------------------- net/mptcp/mptcp_sched.c | 20 +- net/mptcp/mptcp_wvegas.c | 270 ------------------------ 16 files changed, 10 insertions(+), 2520 deletions(-) delete mode 100644 net/mptcp/mctcp_desync.c delete mode 100644 net/mptcp/mptcp_balia.c delete mode 100644 net/mptcp/mptcp_binder.c delete mode 100644 net/mptcp/mptcp_coupled.c delete mode 100644 net/mptcp/mptcp_olia.c delete mode 100644 net/mptcp/mptcp_redundant.c delete mode 100644 net/mptcp/mptcp_rr.c delete mode 100644 net/mptcp/mptcp_wvegas.c -- 2.16.2

4 years, 1 month

2
10
0 / 0

Call for ideas for a presentation about MPTCP Upstream project at NetDev 0x12 in July

by Matthieu Baerts

Hello, NetDev 0x12 is coming to Montréal this summer: July 11th to 13th, 2018. We already talked about this event on this ML and at our weekly meetings but here is a summary of the discussions we had: - we would like to have a presentation there mainly to get feedback and advice from other kernel developers - a presentation would clearly indicate that this MPTCP Upstream project exists and we could get help from more developers - we would like to indicate that having MPTCP upstream is asked by different companies, some are even ready to contribute ; it is then important to have MPTCP upstream Also note that: - David Miller will not be present in Montréal [1] but other main contributors should be there (we don't have a list) - A presentation by Octavian Purdila about "MPTCP Upstreaming" has already been given in 2015 (NetDev 0.1) [2] - 3 types of presentation are available: talks, tutorials and workshops [3] - Call for Presentation Proposals closes on May 1st, 2018. The current idea we briefly discussed during our weekly meetings is to give a tutorial: - It is not useful to give almost the same presentation as the one of Octavian - It will allow us more flexibility somehow to explain what is MPTCP, the different use-cases, why it is important to have it upstream and what problems we are currently facing. - David Miller and many other kernel developers will go to LPC in November: a good place to give a talk this time. Do you have any ideas on what we could show in this tutorial? I recently discussed with my colleague Olivier Bonaventure who has a lot of experiences in giving different introductions and more about MPTCP and here is what he suggests: - A first part about a basic introduction of MPTCP - Indicate different use-cases -- if possible with a "closed demo" to be sure it is working -- asking people to setup something is not easy in 1h, max 1h30. - Then trying to have interactive discussions or explanations about how MPTCP is currently implemented or should be implemented if it goes upstream, e.g.: for MPTCP, we need to have extra TCP Options, we need to support middleboxes, we need to link subflows of the same connection together, we need a scheduler, a PM, etc. - Of course, we should focus our discussions on the upstreaming aspect, e.g. reducing the footprint of MPTCP in the current TCP stack: what are we allow to do, what not. It is linked to many previous discussions we had on this ML, e.g. why we need more indirect function calls and how to reduce the impact, etc. - If we have time, we could discuss about how users could interact with MPTCP: enable it per connection, control the path manager, maybe the scheduler, etc. What do you think about this? Feel free to comment and even propose completely different ideas! Cheers, Matthieu [1] https://lists.01.org/pipermail/mptcp/2018-March/000379.html [2] https://www.youtube.com/watch?v=wftz2cU5SZs [3] https://www.netdevconf.org/0x12/submit-proposal.html -- 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 -- DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

4 years, 2 months

3
20
0 / 0

2022

2021

2020

2019

2018

2017

mptcp May 2018