Minutes IETF101: mptcp
minutes-101-mptcp-01

Multipath TCP (MPTCP)
Meeting  : IETF101, Thursday March 22, 2018, 13:30 - 15:30 (Afternoon session I)
Location : Viscount
Chairs   : Philip Eardley
           Yoshifumi Nishida
AD       : Mirja Kühlewind
URL      : http://tools.ietf.org/wg/mptcp/
Note Taker: Christoph Paasch

--------------------------------------------------------------------------

1: WG Updates - Chairs

   Phil:
      Discussion of RFC6824bis status
      Proxy work item: tcpm working group has added a working group item on TCP
      converter. Encourage participants of MPTCP working group to get involved
      in tcpm and participate to that work

      Enhanced API document: no working group document for this item at this
      stage, we'll need to discuss at one point

--------------------------------------------------------------------------

2: Implementation Updates - Christoph Paasch

   Christoph:
      New stable release on Linux 4.14 LTS. No major feature, mainly
      upstreaming, 72 changes from 6 developers at 5 different companies.
      Bigger effort of upstreaming with Tessares, Intel, Oracle and some others
      and new MPTCP upstream discussion list

      We will probably have to remove some features from the 0.94
      implementation to go upstream. It seems acceptable trade-off as they
      could be pushed back later on once MPTCP has been accepted in the
      mainline Linux kernel.

      Hackathon in Louvain-la-Neuve with open-source iOS applications. See
      slides for additional information:
        - Radio app
        - Web browser: search suggestion
        - Multipathtester
           - Issues: when apps use lower/higher level net lib

   Yoshi:
      is there a gap between 0.94 and RFC6824bis?

   Christoph:
      0.94 is still RFC6824, the code for the bis implementation has not yet
      been released. I'll check how to release the 6824bis implementation.

--------------------------------------------------------------------------

3: 6842bis update - Alan Ford

   Alan:
      Updates to MP_FASTCLOSE with RST. Tussle between being able to correctly
      close a Multipath TCP connection and allow a server to get rid
      immediately of a Multipath TCP connection. Adds an option to RST to solve
      this problem

      TCP Fast Open: based on earlier draft from Gregory Detal and Sebastien
      Barre. How to interact with MPTCP option space and when is it appropriate
      to use it ? TFO is used on first subflow only. Enough space in SYN, a bit
      more difficult in SYN+ACK. Exclude TFO data from DSS to cope with
      middlebox interference that could modify data in SYN. DSS starts after
      the data in the SYN.

   Mirja:
      TFO only works for the first subflow, not for the additional ones?

   Alan:
      Correct. No options space on later subflows and no clear delay benefits.

   Mirja:
      What happens if you loose the data and have to retransmit?

   Alan:
      Not worse than regular TCP

   Christoph:
      If the TFO data does not get acknowledge, it will be sent as regular
      MPTCP data after the handshake has finished

   Mirja:
      Not exactly like TCP.

   Christoph:
      TCP sequence number will be the same, but we add DSS to the retransmission

   Mirja:
      If you add information to the packet and it was already too long, it does
      not work anymore. I have to look at the details. Are you convinced that
      there is no problem?

   Christoph: Yes

   Alan:
      We might need to rework a bit the text to make it clearer.

   Yoshi:
      Fast Open is optional, not mandatory to implement?

   Alan:
      Agreed. This is to say if you implement TFO+MPTCP, these things you
      should consider.

   Yoshi:
      We push this draft as a proposed standard. When I read the draft, it was
      not clear that this part was optional. Make sure that we are explicit for
      the parts that are not mandatory to implement

   Uma Chunduri (?) from Huawei:
      in section 2.7, which threats of RFC6181 have been addressed?

   Alan:
      Pretty much all of RFC6181 have been addressed with the HMAC, objective
      is to be no worse than TCP. If you're on path, even normal TCP can be
      attacked but adding subflows should not make things worse.

   Uma:
      Might expand the section

   Phil:
      Moving to a slot for discussing whether this could be WGLC now. We made
      some changes to RFC6824, version number has been bumped and this will
      obsolete RFC6824.

   Olivier:
      One comment about RFC6824bis about the experimental MPTCP options.
      Quentin Deconinck tried to implement it and there are still some issues.
      Suggestion: Remove it from the core text and rather write an RFC outside
      of the main document that specifies the experimental MPTCP options.

   Alan:
      Yes, we could do this. And just say in the bis that there may be other
      options sent under this version-number.

   Phil:
      After the update of the document we'll be able to issue a last call.

--------------------------------------------------------------------------

4: A socket API to control Multipath TCP - Fabien Duchene

   Fabien:
      Quick update on the socket API.
      Added support for IPv6 Segment Routing. Can add SRv6 option to a subflow
      to steer traffic. - Using disjoint paths - Traffic engineered path

   Uma from Huawei:
      How do you get the network path to the host?

   Fabien:
      we have a paper that describes a possible approach

   Uma: how does the endhost now the path ?

   Fabien: could be an SDH controller

   Uma: If you expose the network paths, there could attacks.

   Sri:
      Trying to understand the motivation for this.
      If I bind to a Wifi address, that's a path, in which situations would you
      use that ?

   Fabien:
      There are use cases where you want to have disjoint paths, this could be
      a way to obtain those paths that are really disjoint. Gives more insight
      to transport layer.

   Sri:
      Endpoints doing that, not completely believe the picture.
      What are your thoughts on the interaction with the MPTCP converter?

   Fabien: Still need to think about the interactions.

   Olivier:
      Just one comment: There was a presentation by Daniel Bernier at PANRG.
      He wanted to use IPv6 SR in his core-networking and expose the paths to
      the end-hosts. I will send that paper to the list.

--------------------------------------------------------------------------

5: Extended Socket APIs to control subflow priority in Multipath TCP - Samar
Shailendra

   Samar:
      Based on experiments with drones with RobotOS. Wanted to have control at
      the application layer through the socket Expanded on
      draft-hesmans-socket-api Control subflow priority

   Phil:
      What is the status of your system ?

   Samar:
      still a prototype, commercial drones do not expose their kernel

   Yoshi (from floor):
      If we reconnect, can we get the same subflow?

   Samar: we use a list with addresses and all subflows with the same address
   get the same priority.

   Yoshi:
      What about port number?

   Samar:
      We only check addresses.

--------------------------------------------------------------------------

6: Considerations for MPTCP operation in 5G - Xavier de Foy

   Xavier:
      This is for release 15, deployment in 2020.

   Yoshi:
      Are you doing experiments?

   Xavier:
      Not so far.

   Alan:
      Are you planning to do that?

   Xavier: This is possible.

   Sri:
      Trying to understand the proposal. 5G has different types of addresses,
      you want this to be exposed to MPTCP?

   Xavier:
      5G stack will behave in ways that are different than 4G. The assumptions
      in MPTCP will be wrong. 5G handles mobility in a different way. 5G is
      more distributed and could be leveraged to have better performance

      Idea is to provide information about the type of address. These modes
      will have one-to-one mapping to IETF specs, this should address some of
      your concerns. How do we expose that to the socket layer? IETF has a spec
      in last call in dmm working group, maybe it covers some of your concerns

   Xavier: Will check DMM drafts

   Uma:
      3GPP sent a liaison statement to DMM working group. Maybe something need
      to be done in MPTCP for that

   Phil (from floor): In DMM, would you be able to use MPTCP? Is there a change
   needed in DMM?

   Sri:
      If you already expose the modes to the socket layer, the application
      already has visibility on the properties. Are you willing to define
      additional logic in MPTCP?

   Xavier:
      Based on the DMM work, MPTCP could get in which mode a given address is
      attached done. Maybe there is some mapping to be done between the
      applications and the interfaces

   Sir: Will think about it

   Phil:
      Need to make sure that MPTCP can use the DMM information
      Are the changes needed for MPTCP? Did you find any?

   Xavier:
      I think that what we have found mainly impacts scheduler and path
      management and probably not the protocol itself

   Phil: During WGLC, make comments if anything needed.

--------------------------------------------------------------------------

7: First Experimentations with iOS Multipath TCP - Quentin De Coninck

   Quentin:
      MultipathTester performs bandwidth measurements and mobility measurements
      to measure the performance of handovers Compare Multipath TCP with QUIC
      and Multipath QUIC to see which protocol performs better 200 tests
      already collected from 50 different devices Application is available from
      https://www.multipath-quic.org and available on Apple's store as
      MultipathTester

   Yoshi (from the floor):
      very interesting. What is the difference between MPTCP scheduler and
      MultipathQUIC's

   Quentin:
      At server side, we use low latency scheduler, on scheduler same but we
      prefer WiFi over cellular on MPTC

   Yoshi:
      Lowest rtt is not always the best? Is it what you are trying to say?

   Quentin:
      Linux has potentially failed paths, there might be something similar in
      iOS. This is a work to improve the scheduling and path management

   Zhen Cao:
      Why iOS MPTCP is different from Multipath QUIC

   Quentin:
      Sometimes my QUIC implementation sends over cellular when it should not
      and there were some issues with Multipath QUIC that are being fixed

   Zhen:
      If MPQUIC sends the request but does not go through the network, you
      should not consider this delay as infinite. If you have a threshold for
      handover, you should send request and maximum delay should be the same.
      We'll see when we have more data

--------------------------------------------------------------------------

8: One Way Latency Considerations for MPTCP - H Anthony Chan
   A Path-aware Scheduling Scheme for Multipath Transport Protocols, Jing Zuo

   Jing:
      Scheduling taking into account one-way latency and using redundant
      transmissions from time to time to obtain data from all the paths,  e.g.
      during one second packets are scheduled according to the one-way latency

      Proposed Multipath one way latency option

   Phil: Have you built this?

   Jin: Part has been done

   Yoshi (from floor):
      If path is completely disjoint, redundant makes sense, but if the paths
      merge, then you overload this shared part of the path affecting one way
      delay measurements?

   Jin: redundant is only run for a period of time.

   Mirja: When not only TCP timestamp option?

   Jin:
      It carries two timestamps, we do not want to change the meaning of these
      options. If you think it can be used, we can use that

   Mirja: What would you need to change?

   Jin: delayed ack might be an issue

   Mirja:
      Don't think one-way delay is a specific function for MPTCP.
      If you want a different option, it should be a TCP option

   Mark:
      What do you do in the redundant phase? Is congestion control applied in
      the two transmissions? if a path has low cwnd and the other large, how do
      you cope?

   Jin: don't consider CC at this stage.

   Mark: unclear how your proposal would work.

   Jin: uncoupled congestion control

   Mark: If you send in this redundant mode, the other path may become very
   slow, do you stop then?

   Jin: We could set a threshold for that

--------------------------------------------------------------------------

9: SOCKS Protocol Version 6 - Vladimir Olteanu

   Vlad:
      Uses TLS and includes new socket options. Clients can place them in SOCKS
      requests and servers in replies, includes bypass feature like
      draft-ietf-tcpm-converters

   Yoshi:
      about the bypass. When the client identifies the support of MPTCP on the
      server. Application has the responsibility to use this information?

   Vlad:
      in implementation, application is probably a proxyfier that can take care
      of that