Conference talk ideas, round 2
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
[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
[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
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
[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
[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
[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
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