Minutes for MPTCP at interim-2015-mptcp-1
minutes-interim-2015-mptcp-1-4

Multipath TCP (MPTCP)

Meeting    : Interim, Tuesday September 21, 2014, 15:00-16:30 GMT/UTC
Location   : webex
Chairs     : Philip Eardley
             Yoshifumi Nishida
AD         : Martin Stiemerling
URL        : http://tools.ietf.org/wg/mptcp/
Note Taker : Will Ivancic
Participant: Andreas Ripke, Christoph Paasch, Geoff ladwig, Nigel Williams,
Planivelan Appanasamy,
             William Ivancic, Joe Ishav, Matt Sargeant, Alan Ford, Kiran,
             Xinpeng Wei, Olivier Bonaventure, Joseph Ishac, Matt Sargent,
             Philip Eardley, Yoshifumi Nishida

--------------------------------------------------------------------------------------------------
1:  Chair Slide
     * Confirm to remove a charter item as discussed at Prague
          * Implementation advice (Informational) to IESG
            * No objection

--------------------------------------------------------------------------------------------------
2: MPTCP use cases - Enhancement Opportunities  - A.Palanivelan

     * Short Flows vs Long Flow - really need to have some strategy
     /demarcation. * Elastic vs Inelastic Applications * MPTCP path selections
          * high packet loss and high latency
          * multiple profiles
          * roaming
     * Controlling number of sub flow getting created
          * Can this be controlled? How?
     * Security has many open issues - TBD
     * Discussion
          * Choice of path selection is interesting area to explore
          * Some tools already exist in MPTCP - how to use them requires
          communication of deployment experience * Looking more from ISP point
          of view than end-user point of view

--------------------------------------------------------------------------------------------------
3: MPTCP for Channel Bonding - NASA Atmospheric research  - William Ivancic
     * Uses 4 Iridium Modems at 2.4 kbps each (9600 bps total)
     * Discussion
          *  Which kind of stack are you going to use?  Existing or otherwise?
               * Will Ivancic - we plan on using the existing implementations.

          * What is the schedule?
               * Will - we are currently working with PPP-MP, which has a lot
               of options that can be tweaked,
                        we will then move on to MPTCP
               * Matt Sargent - We have not installed a MPTCP stack yet,
                             but we have been seeing that PPP has issue with
                             the length of time needed to detect a loss. So it
                             will be interesting to see how MPTCP handles the
                             same problem of detection of the lost link.
               * Will - Results will be published.
               * This is an interesting use case of MPTCP
               * Will Ivancic - Yes it should be interesting to see how it
               compares as it might be tough with the environment. * Yoshi -
               Yes it was really interesting to hear about the use case as it
               is a really low bit rate.

--------------------------------------------------------------------------------------------------
4: MPTCP Proxy Considerations - Xinpeng Wei
     * support use of MPTCP when one or both peers are not capable of MPTCP.
     * Traffic aggregation
     * Firewalls may disable MPTCP
     * traffic aggregation could break security deployments
     * Next Steps
          * welcome comments
          * looking for people interested in forming design team
     * Discussion
          * Do you want to include this in the protocol bis (RFC6824bis) ?
     * proxy bit discussion
          * this also related to load balancer (see later)
          * need to think about the larger problem space

--------------------------------------------------------------------------------------------------
5: Open Issues - Chairs
     * 8 bit vs 16 bit for mptcp-exp-option
          * Original was 16 vs 32 - why so large (32)
          * 8 bits seems to small, 16 appears fine for vendor experimental
          options and/or deployments. * Do not want vendor specific deployments
          - for experimentation, OK, but not operations or no interoperability.
          * Paasch - 8 bits keeps options down and reduces chance of
          incompatible implementations * 8-bit will be sent to list as the
          consensus * if 16 bit is required later, we might be able to allocate
          new option ID for it
     * ADD_ADDR2
          * Making MP_CAPABLE reliable: Some positive supports to update the
          format. No objection. * Requires new version number for the protocol,
          as can't be negotiated * Problem of lack of option space? There's
          space to include Timestamp option; * if no future room for a future
          new option, then would have to choose
     * Consensus to increment version number
          * Now a wider context than just MP_CAPABLE - opportunity to change
          other stuff

--------------------------------------------------------------------------------------------------
6: Making MPTCP robust for stateless webserveres - Christoph Paasch
     * Used to handle SYN-flooding attacks
          * Currently loss of third ACK in MPTCP will result in a fallback to
          regular TCP * Problem for lossy path (where MPTCP would/should
          provide benefit) * Suggestions - Make MP_CAPABLE reliable * merge
          MP_CAPABLE with DSS-option * MP_CAPABLE implementation would reduce
          MP_CAPABLE by 4 bytes * Discussion
               * Should this be included in RFC6824bis?
               * Nigel Williams - should have been in original version but was
               oversight - in favor of inclusion. * What happens if client does
               not send data? * Need to look at load balance issues regarding
               this solution.

7: Load Balancer and MPTCP - Christoph Paasch
        * Intro on how load balancers operate.
        * multiple servers represented by single IP address
        * adding or removing servers requires different solution then ECMP
            so stageful layer-4 load balancer (stageful) is used
        * in reality, multiple layer-4 load balancers are used.
        * Tutorial on how MPTCP interacts with load balancers.
        * Layer-4 load balancer need to track token-to-server mapping
        * Token collision of different servers are possible
        * Problem increases of multiple load balancers are used.
        * MPTCP- session may reach different load balancers
        * Solution Space
            * Need to make token-generation locally meaningful
            * How does one signal the token?  Two current proposals
            * different token generation by splitting MPTCP-key into two 32bit
            sections. * No wire-change, but reduces entropy by 32 bits.
        * Explicitly generate token.
            * Token not related to key
            * consumes 4 more bytes
            * server needs to act stately
        * Conclusion
            * Token should be locally meaningful
            * Guarantees uniqueness
            * Enables layer-4 load balancers
            * Signaling is open question.
        * Discussion
            * there's been a good discussion on the mailing list
            * Paasch - Reuse keys looks promising
            * Strong assumption on attacker model.
            * Assumption is that attacker cannot eavesdrop on initial
            handshake. May not be a good assumption. * Olivier - make sure that
            when TLS exists then can leverage it * Phil - don't want two
            versions of MPTCP, one with TLS and one without * Take discussion
            to list and iterate.