Re: [multipathtcp] MPTCP Interim September 10 - Meeting Notes

["Appanasamy, Palanivelan" <[e-mail]>]

Thanks all.

We will work on detailing the use cases into a draft and have this discussed in the next meeting.
Chetan confirms that he is attending Yokahama IETF in November. 

Keep Sharing your feedback or improvements. Thanks.

Regards,
A.Palanivelan

-----Original Message-----
From: multipathtcp [mailto:[e-mail]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Thursday, September 10, 2015 11:46 PM
To: [e-mail]
Subject: [multipathtcp] MPTCP Interim September 10 - Meeting Notes

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.





_______________________________________________
multipathtcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp