Multipath TCP (MPTCP) Meeting : IETF104, Wednesday March 27, 2019, 11:20 - 13:20 (Morning session II) Location : Karlin 1/2 Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Anna Brunstrom, Xavier de Foy -------------------------------------------------------------------------- 1: WG Updates - Chairs Phil: RFC6824bis draft has now been sent to IESG. Thanks for the efforts -------------------------------------------------------------------------- 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 now supports MPTCP -------------------------------------------------------------------------- 3: Results from the monitoring of MPTCP-based hybrid access networks - Olivier Bonaventure Rahul Jadhav: Use of transparent proxy, do you need converter Olivier: 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. Rahul: Can converter be extended with policy support for scheduling Olivier: Network operators control the policy Florin Baboescu: Shown employment is not consistent with 3GPP Rel 16 Marcus Amend: Specific scheduler used in deployment Olivier: Scheduler and path manager prioritize DSL network Marcus: In results, could you get 1G with single TCP flows. Olivier: Was with multiple flows Marcus: CPU overhead? Olivier: Really depend on the CPE Marcus: 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 Olivier: BBF does also GRE aproach, will see how QUIC will be supported Florin Baboescu?: What is the issue with using MPTCP for tunneling IP traffic Olivier: MPTCP will give you reliability and delay for applications that do not need it. -------------------------------------------------------------------------- 4: Multi-path Transport Deployment on Smartphone Apps - Zhen Cao Lars Eggert: 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) Zhen: Does ECN work with MPTCP? Stuart Chesire: Yes Anna Brunstrom: Using ECN will reduce the cwnd for when you need it Marcus Amend Need this functionality for other things Lars: Do not need more functionality in MPTCP 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 Why do you need MPTCP for mice flow. Zhen: For better latency Lars: Low latency path should naturally be the "best" path selected, so will not need anytrhing special for path management to handle this Zhen: Ok, got your point; At least we agree on the scenario and the problem exists. Ben: How often does this happen Zhen: With full mesh all the time Florin: ATSSS slide not fully correct, only cover Rel. 15. Zhen: Thanks, please send them to the list as the group is not fully aware of what's happening in 3GPP. -------------------------------------------------------------------------- 5: Initial-Path Selection for Connection Establishment in Multipath TCP - Jianjian Zhu Alan Ford: This caching is already discussed in bis draft Florin: RSSI is not enough, suggest to look at MAMS draft Chris Seal: CQI is what we use in mobile Christoph: 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. Stuart Cheshire: This is happy eyeballs in narrow scope, please look at that if not familar. WiFi assist to prefer one interface Zhen: Yes, this should be general solution. There will be PIPC side meeting. (performance implications of path characteristics). Marcus: Agree, it is a general issue, but think we should not limit multipath protocols to single path at start-up Keying attacks is a problem for happy eyeballs in MPTCP context (Alan Ford) -------------------------------------------------------------------------- 6: Generic Path-Manager Support with eBPF - Viet-Hoang Tran -------------------------------------------------------------------------- 7: 5G Session Continuity Support in MPTCP - Xavier de Foy Florin: Multi-access PDN is introduced in 3GPP Rel. 16, not well mapped to talk, also all terminals know their adress? Xavier: Need to support continuity of addresses known at client but not at server Sri: Key proposal is communicating session continuity type to remote peer? Xavier: Not really, it is one of the possible solutions but there are other options Sri: This information is not enough, need additional information, need to analyze Xavier: Actually in this particular solution the initial IP address index is also communicated to the remote peer, not only the session continuity type. Lars: Any data quantifying when you do nothing? Xavier: No Lars: Suggest we discuss this when we have data and know if there is a problem Phil: Do you plan to get data Xavier: Do not have access to 5G network yet Lars: Any data even simulation may be useful, start with data Florin: For 3GPP we have clear items that have priority, would like to have focus on this, this is not one of them Phil: Let's talk later to see how to best convey this to group -------------------------------------------------------------------------- 8: Potential future topics for WG 1: Brief summary of Monday’s side meeting 2: TAPS multipath support – Anna Brunstrom 3: Open discussion Tommy: Welcome input on API. Open issue on improving granularity of info (Apple use enum and 3 modes eg interactive, aggregation Christoph: 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 sever. 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. Phil: Have you tried using ECN approach suggested by Lars? Christoph: Can perhaps support throughput, but does not work for latency Marcus: 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 Florin: Issue is not only on hnadset, also on proxy that may implement load balancing scheme Lars: Would be useful to tease this problem apart Mirja: 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 also has an Not only research issues, also experiences from operational experience. Also need connection to BBF and 3GPP Can be handled in other groups Zhen: Much easier if we have a groups collecting MPTCP experts Mirja: Concerned we are missing other experts here like congestion control. Florin: Do have issue if a terminal or proxy need to implement a policy, we have very clear requirements here. Christoph: For ATSSS we have a side channel for policies, right Florin: Issue is how to use the policy as I understand Marcus: Think we should have informational document on scheduling and path management for BBF and 3GPP to know. Do you think this is research? Mirja: This topic is relevant for other protocols as well, we will find a home for this document Tommy: Closing a wg is not a threat to close the work, perhaps we should have a general wg on multipath Florin: Agree a generic multipath group could be good Zhen: Do not understand why we should close a group when we have issues to solve Mirja: Group has finished its charter, then we normally close. The mailing list can stay opened.