Minutes IETF97: mptcp
minutes-97-mptcp-00

Multipath TCP (MPTCP)

Meeting  : IETF97, Monday Nov 14, 2016, 13:30 - 15:30
Location : Park Ballroom 2
Chairs   : Philip Eardley
           Yoshifumi Nishida
AD       : Mirja Kühlewind
URL      : http://tools.ietf.org/wg/mptcp/
Note Taker: Rolf Winter

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

1:  WG Updates - Chairs

    MPTCP experience in RFC editor queue

    No particular implementation updates reported during the meeting

    Hackathon update: (from Fabien)
      25 students in Louvain-La-Neuve and 5 people in Seoul
      Integration API with iPerf3
      Binding the API towards a couple of languages
      Tuning a few applications for MPTCP
      LD_PRELOAD library
      Documentation

      Won the hackathon ... congrats!

      See Olivier's bog post for more information:
      http://blog.multipath-tcp.org/blog/html/2016/11/13/multipath_tcp_projects_during_the_ietf97_hackathon.html

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

2: 6842bis update - Alan Ford

    Two changes since IETF96: Add a flag into MP_CAPABLE "Do not use this
    address" and reliability of ADD_ADDR option

    Yoshi:
        This is for load-balancers? We have another solutions for
        load-balancers from Christoph.

    Alan:
        Not only for load-balancers. This is an optimization which is useful if
        you are behind a load balancer, but can be applied to other situations
        as well.

    Yoshi:
        Is this a mandatory feature for all implementations?

    Alan:
        All implementations have to support the echoing only.

    Yoshi:
        If ADDR_ADDR has been sent in ACK, the receiver might need to send ACK
        for ACK. Isn't it tricky to implement?

    Alan:
        I don't think so. Let's wait for implementation reports.

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

3: Efficient Design for Securing MPTCP against Eavesdropping during the initial
handshake - Dong-yong Kim

    Alan:
        Why is the MP_JOIN insecure with MPTLS (DoS Attack)? (page 18 on the
        slide)

    Dong-Yong:
        Because valid token can be taken.

    Yoshi:
        This does not have to be MPTCP, why do you restrict it to MPTCP?

    Dong-Yong:
        I just did.

    Yoshi:
        The key length is restricted to fit into option space. Is it secure
        enough?

    Dong-Yong:
        With current key sizes this is safe. In 10 years, I do not know.

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

4: MPTCP Address Advertisement - Fabien Duchene

    Fabien:
        The 2 proposed bits have been added to the bis document as already
        mentioned. Echo flag has been implemented No_JOIN is still under
        development (probably done by the next IETF) Backup bit in the ADD_ADDR
        for make before or after break... more feedback needed

    Alan:
        You could do this by playing with window sizes and ACKs.

    Fabien:
        Yes, but that is hacky. Explicit is better.

    Mirja:
        Single bit or priority value?

    Fabien:
        Priority would be useful?

    Mirja:
        Is this a real use case? 0/1 is more realistic.

    Brian:
        Seconds Miria. In reality really difficult unless you have something
        like CBR traffic, but TCP is not used for that kind of traffic.

    Christoph:
        Sometimes this in not a 0/1 decision. Our implementation can be read
        about in the IETF journal
        (https://www.ietfjournal.org/multipath-tcp-deployments/). Sometimes a
        little more control is nice.

    Mirja:
        You can still do this with a 0/1 signal.

    Christoph:
        This is related also to latency etc.

    Mirja:
        But, this is more than just priorities

    Christoph:
        I agree

    Fabien:
        This is why we need more feedback on the list.

    ????:
        Priorities should consider other use cases (servers pooling DSL lines
        etc.). Overflow use cases and bandwidth pooling use cases etc. 3 bits
        proposed for defining communities (addresses with shared properties -
        user configurable). Dual-stack case main motivation

    Alan:
        Seems unnecessary. Users do not know this. Limited applicability.

    Fabien:
        This is to avoid using the same path.

    Alan:
        Then just do not announce it.

    Fabien:
        Makes sense. If this is a bad idea, then Ok. We can just scrap it.

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

5: MPTCP load balancing - Fabien Duchene

    Fabien:
        A guide to help people choose a load balancing solution
        Next steps: more work on security and industry input

    Yoshi:
        Previously Costin and Christoph proposed load balancing. Is this a
        merger?

    Fabien:
        No, this is just a comparison.

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

6: A proposal for improving MPTCP initialization - Kien Nguyen

    Kien:
        Proposal: Duplication during initial handshake (parallel SYNs)

    Alan:
        Scurity is weakened by this.

    Kien:
        Yes, we need to work on this.

    Yoshi:
        We usually have only one default route even if a node has multiple
        interfaces, e.g. wifi and ethernet.

    Klen:
        We presume a node has some routing mechanisms to utilize multiple
        interfaces efficiently.

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

7: Rechartering Discussion

  Possible work items:

  * API
    Show of hands: a bunch of people support this, but nobody really against it

  * Proxy
    Before going down this path, clarifications are needed.

    Alan:
        This is already in the charter

    Phil:
        Let us add this, since people want this and deploy this.
        Let us do this through the IETF and not have people just deploy their
        own stuff.

    Mirja:
        This is not MPTCP specific. This should therefore not be here since
        this is tunneling.

    Yoshi:
        We can document operational experience and guidelines. Is this in scope?

    Mirja:
        Yes, but not sure there is a big difference between one-ended and
        two-ended

    Olivier:
        The two-ended solution is not tunnel.

    Mirja:
        Ok, but tunneling is not in scope for MPTCP

    Wim:
        This proposed bits (excluding UDP) is proxying, not tunneling

    Brian:
        Advertisement for the BANANA BoF on Thursday.

    Alan:
        Agrees to put this on the charter as an analysis thing as according to
        the charter.

    Phil:
        It is important to understand what the impact is on the protocol bits.
        Is e.g. the bis in its current form appropriate. Also exclude the UDP
        case. That should be left to BANANA.

    Wim:
        Removing it might complicate things. But it might be a good compromise
        at this point.

    Dave:
        Process-wise, what does it take to define a technical solution to
        define the UDP bit if we do not think about this now.

    Mirja:
        We will think about this when we are there.

    Alan:
        The analysis will potentially lead to extensions but we do not need to
        think about this now.

    Wim:
        BANANA is a non-WG forming BoF. A lot depends on whether BANANA will
        become a WG or not.

  * Potential other items. NFS or CC or other topics if any.
    Nobody spoke up