Minutes IETF104: mptcp
minutes-104-mptcp-00

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.