Re: [multipathtcp] MPTCP WG minutes - draft

[Yoshifumi Nishida <[e-mail]>]

Hi,
I've uploaded a draft minute on the following URL.

https://datatracker.ietf.org/doc/minutes-104-mptcp/

Please let us know if you have correction or questions, etc.
Thanks!
--
Yoshi & Phil



On Tue, Apr 16, 2019 at 3:05 AM <[e-mail]> wrote:

> 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 famili
> ar. 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? (Mark
> us)
>
> 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)
>
>
>
>
>
>
>