[multipathtcp] MPTCP WG minutes - draft

[<[e-mail]>]

Here are the draft minutes for our WG meeting in Prague. Please let us know any corrections.
Thank-you to the minute takers - I think Anna & Xavier, please shout if I remember wrong!
Thanks
Phil & Yoshi
--

1. WG status (chair)

2. Implementation news (Christoph)
- Now have approval to open source the handshake
- Mainline Linux kernel: growing community (RedHat, Intel, Thesaurus), making progress, will get there eventually, have support from Linux maintainers
- Apache traffic server allows to enable MPTCP

3. Deployment updates
3.1. Results from the monitoring of MPTCP-based hybrid access networks - Olivier Bonaventure
See slides for overview of talk

Q & A

Q Use of transparent proxy, do you need converter (Rahul Jadhav)
A. CPE sees all the traffic, no need there. HAG may use a converter or be transparent. With transparent proxy on the HAG, all traffic must go through the HAG. Otherwise use a converter.

Q. Can converter be extended with policy support for scheduling (Rahul Jadhav)
A. Network operators control the policy

Q. Shown employment is not consistent with 3GPP Rel 16 (Florin Baboescu?)

Q. Specific scheduler used in deployment (Marcus Amend)
A. Scheduler and path manager prioritize DSL network

Q. In results, could you get 1G with single TCP flows. (Marcus Amend)
A. Was with multiple flows

Q. CPU overhead? (Marcus Amend)
A. Really depend on the CPE

Q. Need complement to TCP? It is hard to explain to customers if the benefit is for TCP only, this is why we propose a multipath UDP to complement MPTCP (Marcus Amend)
A. BBF does also GRE approach, will see how QUIC will be supported

Q. What is the issue with using MPTCP for tunneling IP traffic (Florin Baboescu?)
A. MPTCP will give you reliability and delay for applications that do not need it.

3.2. Multi-path Transport Deployment on Smartphone Apps - Zhen Cao
See slides for overview of talk

Q & A

Q. Can set ECN CE mark on the path you do not want the server to use (to implicitly tell server which path is preferred, eg toll-free) (Lars Eggert)
Does ECN work with MPTCP? (Zhen)
Yes (Stuart Cheshire)
Using ECN will reduce the cwnd for when you need it (Anna Brunstrom)
Need this functionality for other things (Marcus Amend)
Do not need more functionality in MPTCP (Lars)
Need to better understand the problem before we decide solution
More discussion on the mailing list would be helpful, there were already a thread discussing this;

Q. Why do you need MPTCP for mice flow.
A. For better latency

Q. Low latency path should naturally be the "best" path selected, so will not need anything special for path management to handle this (Lars)
A. Ok, got your point; At least we agree on the scenario and the problem exists.
Q  How often does this happen (Ben)
A. With full mesh all the time

Q. ATSSS slide not fully correct, only cover Rel. 15. (Florin)
A. Thanks, please send them to the list as the group is not fully aware of what's happening in 3GPP.


4. Individual drafts
4.1. Initial-Path Selection for Connection Establishment in Multipath TCP - Jianjian Zhu
See slides for overview of talk

Q & A
Q. This caching is already discussed in bis draft (Alan Ford)

Q. RSSI is not enough, suggest to look at MAMS draft (Florin)
Q CQI is what we use in mobile (Chris Seal)

Q Selection of initial interface important, but is independent of MPTCP. There is the same problem in QUIC. This should not be designed for MPTCP only. (Christoph)
This is happy eyeballs in narrow scope, please look at that if not familiar. WiFi assist to prefer one interface. (Stuart Cheshire)
Yes, this should be general solution. There will be PIPC side meeting (performance implications of path characteristics). (Zhen)
Agree, it is a general issue, but think we should not limit multipath protocols to single path at start-up (Marcus)
Keying attacks is a problem for happy eyeballs in MPTCP context (Alan Ford)


4.2. Generic Path-Manager Support with eBPF - Viet-Hoang Tran (remote)
See slides for overview of talk

Q & A

4.3. 5G Session Continuity Support in MPTCP - Xavier de Foy 5.
See slides for overview of talk

Q & A

Q Multi-access PDN is introduced in 3GPP Rel. 16, not well mapped to talk, also all terminals know their address (Florin)
A. Need to support continuity of addresses known at client but not at server

Q. Key proposal is communicating session continuity type to remote peer? (Sri)
A. Not really, it is one of the possible solutions but there are other options
Q. This information is not enough, need additional information, need to analyze
A. Actually in this particular solution the initial IP address index is also communicated to the remote peer, not only the session continuity type.

Q Any data quantifying when you do nothing (Lars Eggert)
A. No
Q. Suggest we discuss this when we have data and know if there is a problem
Q. Do you plan to get data (Phil)
A. Do not have access to 5G network yet
Any data even simulation may be useful, start with data (Lars)

Q. For 3GPP we have clear items that have priority, would like to have focus on this, this is not one of them (Florin)
Let's talk later to see how to best convey this to group (Phil)


5. Potential future topics for WG
5.1. Brief summary of Monday's side meeting
5.2. TAPS multipath support - Anna Brunstrom
5.3. Open discussion

Welcome input on API. Open issue on improving granularity of info (Apple use enum and 3 modes eg interactive, aggregation) (Tommy)
Path manager and scheduler is a challenge because you often have two competing goals, reduce cost and improve performance. Ok on the client you can make this trade-off, but needs to be communicated to the server. We currently know who we talk to and configure a policy for a particular service, This is not a general solution, so some signalling from client to server would be very useful. (Christoph)
Have you tried using ECN approach suggested by Lars? (Phil)
Can perhaps support throughput, but does not work for latency (Christoph)
Can we perhaps solve some of these issues in more general context, will apply to multipath QUIC as well at some time or any multipath protocol
Think it is important to collect path scheduling algorithms in informational document (Markus)
Issue is not only on handset, also on proxy that may implement load balancing scheme (Florin)
Would be useful to tease this problem apart (Lars)
Hear a lot of interesting issues, but they seem like research issues. Also some minor extensions, that could be done in tcpm. Also hear discussion on interfaces, this links to TAPS
Not only research issues, also experiences from operational experience. Also need connection to BBF and 3GPP
Can be handled in other groups (Mirja)
Much easier if we have a group collecting MPTCP experts (Zhen)
Concerned we are missing other experts here like congestion control. (Mirja)

Do have issue if a terminal or proxy need to implement a policy, we have very clear requirements here. (Florin)
For ATSSS we have a side channel for policies, right (Christoph)
Issue is how to use the policy as I understand (Florin)

Think we should have informational document on scheduling and path management for BBF and 3GPP to know. Do you think this is research? (Markus)
This topic is relevant for other protocols as well, we will find a home for this document (Mirja)
Closing a wg is not a threat to close the work, perhaps we should have a general wg on multipath (Tommy)
Agree a generic multipath group could be good. IEEE, 3GPP want to use IETF protocols, timeframe is ~ Dec 2019. (Florin)
Do not understand why we should close a group when we have issues to solve (Zhen)
Group has finished its charter, then we normally close. The mailing list can stay open. (Mirja)