[multipathtcp] MPTCP Interim September 10 - Meeting Notes

["Ivancic, William D. (GRC-LCA0)" <[e-mail]>]

IETF - MPTCPSlides are here at bottom of page:
https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015

Note Taker: Will Ivancic
Note, I did not try and capture names to questions.

* Agenda
* Status
     * Removing Charter item, ³Implementation advice (Informational) to
IESG²

* MPTCP use cases - Enhancement Opportunities
     * 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
* MPTCP for Channel Bonding - NASA Atmospheric research
     * 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.
* Chair - Yes it was *really* interesting to hear about the use case as it
is a *really* low bit rate.


     * MPTCP Proxy Considerations
          * 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
               * Bits to set proxy (should those be in updated MPTCP
draft, RFC6825bis?)
     * Open Issues
               * 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
               * ADD_ADDR2  Flags field format will be sent to mail list.
          * Making MPTCP robust for stateless webserveres
               * 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
                    * Should this be included in RFC6824bis?
                         * Nigel Wiolliams - 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.
          * Load Balancer and MPTCP
               * 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
                              * Paasch - Reuse keys looks promising
                              * Strong assumption on attacker model.
assumption is that attacker cannot eves drop on initial handshake.  May
not be a good assumption.
                              * Take discussion to list and reiterate.