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.