Minutes for MPTCP at IETF-93
minutes-93-mptcp-1

Multipath TCP (MPTCP)

Meeting  : IETF, Tuesday July 21th, 2015, 1300-15:00
Location : Prague, Berlin/Brussels
Chairs   : Philip Eardley
           Yoshifumi Nishida (absent)
AD       : Martin Stiemerling
URL      : http://tools.ietf.org/wg/mptcp/
Note Taker: Costin Raiciu, Alan Ford

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

1: Chair Slide

   Phil:
    - exciting activity on deployment and implementation, lots of WG
    - WG draft on operational experience completed the last call
    - bis version of protocol to complete on standards track; dependent on the
    operational experience draft.

---------------------------------------------------------------------------
2: Update on implementation in Solaris - Rao Shoaib

   Rao:
    - draft (RFC) is pretty clear
    - some clarifications on 32/64 bit seqnos, vs Network Byte Order of Host
    Byte Order - why have both 32/64 bit seqnos? choosing one it would make the
    implementation cleaner. - scheduling of data is important - if you decide
    on app write, scheduling doesn't work well. - some customers do not want to
    use any extra CC - they want to use uncoupled. - deplyment scenario: backup
    - as much throughput as possible

   Lars Eggert:
      coupled CC is safe, that's why IETF took this work on at the time.
      It's worth mentioning uncoupled option in some drafts.

   Alan Ford:
      I think it already does. That's certainly we had in mind. If it's not
      clear enough, need to clarify it.

   Shoaib:
      If customers think mptcp is limited, they might want to go back to
      whatever they are doing now.

   Phil:
      Can I ask deployment status?

   Shoaib:
      lots of customers very interested, especially in the financial industry,
      cannot talk about release date yet.

----------------------------------------------------------------------------------------------------------
3: FreeBSD Update - Nigel Williams

   Nigel:
    - significant rewrite ongoing. Modular packet scheduling, protocol
    completeness, interop, etc all to come.

----------------------------------------------------------------------------------------------------------
4: Hackathon update - Costin Raiciu

   Costin:
    - not much happened on the Multipath TCP side.
    - looked at how mptcp sending side could use info from wifi driver, which
    might be utilized in future

----------------------------------------------------------------------------------------------------------
5: Other MPTCP implementation news or questions

   Sowmimi from Oracle:
      About Linux implementation. upstreaming is important for us. when it will
      happen? policy in the Linux implementation. do policies such as IPSEC
      propagate subflows, too? Has anybody thought about it?

   Michael Tuexen:
      There's RFC about IPsec and SCTP multihoming. Maybe it can be applied to
      MPTCP.

   Costin:
      Intel people in Rumania are working on upstreaming.

   Rao:
      big finance company pushing Redhat to have MPTCP support - will happen
      soon.

   Phil:
      Any opinion about Implementation advice draft?

   Lars:
      There is an option not to have this draft.
      we should drop the implementations draft. we might not need it.

   Olivier:
      Agrees dropping the draft.

   Rao:
      It will depend on how many people implement MPTCP.
      it would be important to specify scheduling policies and how do you find
      addresses.

   Olivier:
      scheduling policy is an implementation decision, should not be specified
      by IETF. There are several papers about scheduling policy. If you like
      them, implement it. not sure to re-write in RFCs.

   Rao:
      You should not commit data to a subflow until the subflow can send it.
      If scheduler still doesn't allow it, it will be dropped.

   Olivier:
      you might not have seen it in all implementation.

   Phil:
      send idea to the list, or use the WG wiki page

----------------------------------------------------------------------
6: Update on Korea Telecom /Samsung deployment - SungHoon Seo
   SungHoon:
     - deployed productions proxy in june 2015
     - samsung galaxy S6 - 850Mbps speeds achieved
     - LG also rolling out MPTCP
     - interop testing for other devices besides Samsung
     - Socks v5 used.

   Phil:
      How many people use the service?

   Sunghoon:
      We have started since 6/2015. 5500 active users.

   Lars:
      If the server support MPTCP, what proxy does? Is there any plan?

   Sunghoon:
      Policy engine may support mptcp-mptcp direct connection

   Gregory Cauche - Bouyguyes Telecom:
      interesting to see a deployment, happy someone did, i am trying to
      convince my employers I might want to keep proxy in the middle for
      operational optimization

   Phil:
      Any ops experiences you can add?

   Sunghoon:
      We just started this, so not yet. But, we'll.

----------------------------------------------------------------------
7: MPTCP in Nornet Experiences - Thomas Dreibholz

   Phil:
      Is there anything missing from the operational experiences draft?

   Thomas:
      We'll think about it

   ???:
      How do you do routing?

   Thomas:
      nothing special, only static routes at this moment.

------------------------------
8: Update on the operational experience - Olivier Bonaventure:

   Phil:
      Let's give short period of time for telecom folks to give some feedbacks.
      Then, push the draft to IESG.

   Olivier:
      Yes

---------------------------------------------------------------------
9: A Closer look at MPTCP traffic - Olivier Bonaventure:

   Olivier:
     - a connection that lasted a day and had 20 subflows due to mobility
     - most data goes over the default interface.
     - scheduler prefers lower rtt subflow
     - not many reinjections on the web servers - 4%
     - 10% injections on mobile trace
     - perhaps we should wait before re-creating the second mptcp subflow

   Jeff Houston:
      Is there any evidence that MPTCP behind NAT got confused?

   Olivier:
      MPTCP works well through the NAT. Only issues with NAT ALG, MPTCP detects
      this and falls back to TCP.

   Rao:
      what is the significance of the Data ACK CDF graph?

   Olivier:
      might help receive window blocking if we send the data acks on both paths
      to reduce the time needed from the to arrive to the destination.

---------------------------------------------------------------------
10: Possible Mods to RFC6824bis - Chairs

    Olivier:
      MPTCP experimental options
        - use 0xf for DSN kind
        - TLV encoding
        - negotiation done after setup

    Alan Ford:
       fine with this

    Costin:
       agree also.

    Phil:
       (Consensus call)
       Explicit supports for adding experimental options to 6824bis

    Phil:
       Let's confirm this on the ML, too.

    Phil:
       4B and 8B DACK, DSEQ fields:
         - seems both are needed, although it is simpler to have one.
         - 8B needed for protecting against wrapping
         - 4B useful optimization.

    Rao:
       both should be 4B or both should be 8B. Not convinced there is a problem
       with wrap around.

    Alan:
       size under control of the sender, not clear how they can be harmonized.
       Benefits for short conns are significant enough to retain it.

    Rao:
       Using 4 bytes saves option space.

    Alan:
       Indeed. That's why we supported.
       We're thinking about disabling TS option. If we don't use TS, we can
       have more option space for mptcp.

    Phil:
       we will not close this issue now. Needs more discussion; until then it
       stays as it is.

----------------------------------------------------------------------------------------------
11: MPTCP TFO - Olivier Bonaventure:

    Olivier:
     - A draft has been implemented
     - should write a separate RFC that specifies TFO for MPTCP.
     - Objective is to write an RFC and not to include RFC6824bis

    Phil:
       Not so many people read the draft. encourage to read it.

----------------------------------------------------------------------------------------------
12: MPTCP SYN cookies

    Alan:
       it was an oversight in 6824, we knew we had to cover it
       we need to get it right for MPTCP too in 6824bis.
       we can redefine the bit from ADD_ADDR bit
       good opportunity to fix other bugs that would require changing protocol
       version.

       we should consider a new version number increase
       but, need to think how to handle version number. fallback, retire old
       version, etc.

    Olivier:
       makes sense to explore the option of increasing the version number,
       but should be done on the list to include people not here.
       Main deployment stack is from apple, it would be nice to hear from Apple
       too.

    Phil:
       take this discussion to the list. Interim audio, perhaps.

    Alan:
       Christoph is thinking about new version. We might need to consider it.

---------------------------------------------------------------------------------
13: Extension to MPTCP for Symmetrical Sub-Flow Management

    Olivier:
       two topics in this draft.
        1: Changing the format of ADD_ADDR to replace the bit with a set of
        flags 2: Define a flag for a specific usage.

       I support 1:, but not sure about 2:. No need to advertise address if I
       don't accept MP_JOIN.

    Phil:
       - more discussion on the list.
       - suggest to split out the two things.

---------------------------------------------------------------------------------
14: MPTCP Address Advertisement - Olivier Bonaventure:

     Olivier:
        - address management draft.
        - steal 9 bits from key in MP_CAPABLE option

     Alan:
        I don't like the idea using key, it's expensive.

     Costin:
        I don't think we need this, it seems its too complex for no big
        implementation gain.

     Rao:
        you can make implementation more simple if you don't keep address per
        connection basis.

     Olivier:
        we want to be sure that implementers support this.

     Fabien Duchene:
        what about the DNS part? It's in the draft.

     Olivier:
        Yes. there's discussion on how to use MPTCP without advertising
        addresses (by using DNS). Possible to do it with DNS. Drawbacks:
        cross-layer

     Costin:
        does it work for CDN?

     Olivier:
        should work correctly.

     Phil:
        should protocol doc say something about reverse DNS?

     Olivier:
        no.

---------------------------------------------------------------------------------
15: Improving Multipath TCP Backup Subflows - Olivier Bonaventure:

     Phil:
        does it change 6824bis?

     Olivier:
        Not very sure yet

     Rao:
        Is it a good idea to give absolute value? Maybe relative value or
        multiply factor?

     Olivier:
        It's a possible idea.

     Alan:
        Perhaps there are simpler ways of doing this

     Olivier:
        KT could measure the RTO and can turn their proxies, but we need a
        generic mechanism.

     Alan:
        This is important, but not sure this is the right proposal.

     Olivier:
        that is why we propose for measurements. we can think we need something
        inside protocol, or having a socket option is sufficient.

     Ana Brunstow:
        seems like existing mechanisms in SCTP. I mean Potential Failure
        mechanism (SCTP-PF)

-------------------------------------
16: MPTCP Proxy - Xinpeng Wei

     Phil:
        can't do consensus call yet, not enough people have read the draft.
        Need discussion on having a new flag.

     Lars:
        I see two uses for mptcp.
        One use is trying stretch your traffic as broad as possible so that
        it's hard to be intercepted. This is opposite. We might need to decide
        which way we'll proceed.

     Phil:
        We will get time at an interim meeting.