* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mptcp Status Pages

Multipath TCP (Concluded WG)
Tsv Area: Martin Duke, Magnus Westerlund | 2009-Oct-15 — 2020-Mar-17 
Chairs
 
 


IETF-104 mptcp minutes

Session 2019-03-27 1120-1320: Karlin 1/2 - Audio stream - mptcp chatroom

Minutes

minutes-104-mptcp-00 minutes



          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.
          
          



Generated from PyHt script /wg/mptcp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -