Multipath TCP (MPTCP) Meeting : IETF, Tuesday July 21th, 2015, 1300-15:00 Location : Prague, Berlin/Brussels Chairs : Philip Eardley Yoshifumi Nishida (absent) AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Costin Raiciu, Alan Ford --------------------------------------------------------------------------- 1: Chair Slide Phil: - exciting activity on deployment and implementation, lots of WG - WG draft on operational experience completed the last call - bis version of protocol to complete on standards track; dependent on the operational experience draft. --------------------------------------------------------------------------- 2: Update on implementation in Solaris - Rao Shoaib Rao: - draft (RFC) is pretty clear - some clarifications on 32/64 bit seqnos, vs Network Byte Order of Host Byte Order - why have both 32/64 bit seqnos? choosing one it would make the implementation cleaner. - scheduling of data is important - if you decide on app write, scheduling doesn't work well. - some customers do not want to use any extra CC - they want to use uncoupled. - deplyment scenario: backup - as much throughput as possible Lars Eggert: coupled CC is safe, that's why IETF took this work on at the time. It's worth mentioning uncoupled option in some drafts. Alan Ford: I think it already does. That's certainly we had in mind. If it's not clear enough, need to clarify it. Shoaib: If customers think mptcp is limited, they might want to go back to whatever they are doing now. Phil: Can I ask deployment status? Shoaib: lots of customers very interested, especially in the financial industry, cannot talk about release date yet. ---------------------------------------------------------------------------------------------------------- 3: FreeBSD Update - Nigel Williams Nigel: - significant rewrite ongoing. Modular packet scheduling, protocol completeness, interop, etc all to come. ---------------------------------------------------------------------------------------------------------- 4: Hackathon update - Costin Raiciu Costin: - not much happened on the Multipath TCP side. - looked at how mptcp sending side could use info from wifi driver, which might be utilized in future ---------------------------------------------------------------------------------------------------------- 5: Other MPTCP implementation news or questions Sowmimi from Oracle: About Linux implementation. upstreaming is important for us. when it will happen? policy in the Linux implementation. do policies such as IPSEC propagate subflows, too? Has anybody thought about it? Michael Tuexen: There's RFC about IPsec and SCTP multihoming. Maybe it can be applied to MPTCP. Costin: Intel people in Rumania are working on upstreaming. Rao: big finance company pushing Redhat to have MPTCP support - will happen soon. Phil: Any opinion about Implementation advice draft? Lars: There is an option not to have this draft. we should drop the implementations draft. we might not need it. Olivier: Agrees dropping the draft. Rao: It will depend on how many people implement MPTCP. it would be important to specify scheduling policies and how do you find addresses. Olivier: scheduling policy is an implementation decision, should not be specified by IETF. There are several papers about scheduling policy. If you like them, implement it. not sure to re-write in RFCs. Rao: You should not commit data to a subflow until the subflow can send it. If scheduler still doesn't allow it, it will be dropped. Olivier: you might not have seen it in all implementation. Phil: send idea to the list, or use the WG wiki page ---------------------------------------------------------------------- 6: Update on Korea Telecom /Samsung deployment - SungHoon Seo SungHoon: - deployed productions proxy in june 2015 - samsung galaxy S6 - 850Mbps speeds achieved - LG also rolling out MPTCP - interop testing for other devices besides Samsung - Socks v5 used. Phil: How many people use the service? Sunghoon: We have started since 6/2015. 5500 active users. Lars: If the server support MPTCP, what proxy does? Is there any plan? Sunghoon: Policy engine may support mptcp-mptcp direct connection Gregory Cauche - Bouyguyes Telecom: interesting to see a deployment, happy someone did, i am trying to convince my employers I might want to keep proxy in the middle for operational optimization Phil: Any ops experiences you can add? Sunghoon: We just started this, so not yet. But, we'll. ---------------------------------------------------------------------- 7: MPTCP in Nornet Experiences - Thomas Dreibholz Phil: Is there anything missing from the operational experiences draft? Thomas: We'll think about it ???: How do you do routing? Thomas: nothing special, only static routes at this moment. ------------------------------ 8: Update on the operational experience - Olivier Bonaventure: Phil: Let's give short period of time for telecom folks to give some feedbacks. Then, push the draft to IESG. Olivier: Yes --------------------------------------------------------------------- 9: A Closer look at MPTCP traffic - Olivier Bonaventure: Olivier: - a connection that lasted a day and had 20 subflows due to mobility - most data goes over the default interface. - scheduler prefers lower rtt subflow - not many reinjections on the web servers - 4% - 10% injections on mobile trace - perhaps we should wait before re-creating the second mptcp subflow Jeff Houston: Is there any evidence that MPTCP behind NAT got confused? Olivier: MPTCP works well through the NAT. Only issues with NAT ALG, MPTCP detects this and falls back to TCP. Rao: what is the significance of the Data ACK CDF graph? Olivier: might help receive window blocking if we send the data acks on both paths to reduce the time needed from the to arrive to the destination. --------------------------------------------------------------------- 10: Possible Mods to RFC6824bis - Chairs Olivier: MPTCP experimental options - use 0xf for DSN kind - TLV encoding - negotiation done after setup Alan Ford: fine with this Costin: agree also. Phil: (Consensus call) Explicit supports for adding experimental options to 6824bis Phil: Let's confirm this on the ML, too. Phil: 4B and 8B DACK, DSEQ fields: - seems both are needed, although it is simpler to have one. - 8B needed for protecting against wrapping - 4B useful optimization. Rao: both should be 4B or both should be 8B. Not convinced there is a problem with wrap around. Alan: size under control of the sender, not clear how they can be harmonized. Benefits for short conns are significant enough to retain it. Rao: Using 4 bytes saves option space. Alan: Indeed. That's why we supported. We're thinking about disabling TS option. If we don't use TS, we can have more option space for mptcp. Phil: we will not close this issue now. Needs more discussion; until then it stays as it is. ---------------------------------------------------------------------------------------------- 11: MPTCP TFO - Olivier Bonaventure: Olivier: - A draft has been implemented - should write a separate RFC that specifies TFO for MPTCP. - Objective is to write an RFC and not to include RFC6824bis Phil: Not so many people read the draft. encourage to read it. ---------------------------------------------------------------------------------------------- 12: MPTCP SYN cookies Alan: it was an oversight in 6824, we knew we had to cover it we need to get it right for MPTCP too in 6824bis. we can redefine the bit from ADD_ADDR bit good opportunity to fix other bugs that would require changing protocol version. we should consider a new version number increase but, need to think how to handle version number. fallback, retire old version, etc. Olivier: makes sense to explore the option of increasing the version number, but should be done on the list to include people not here. Main deployment stack is from apple, it would be nice to hear from Apple too. Phil: take this discussion to the list. Interim audio, perhaps. Alan: Christoph is thinking about new version. We might need to consider it. --------------------------------------------------------------------------------- 13: Extension to MPTCP for Symmetrical Sub-Flow Management Olivier: two topics in this draft. 1: Changing the format of ADD_ADDR to replace the bit with a set of flags 2: Define a flag for a specific usage. I support 1:, but not sure about 2:. No need to advertise address if I don't accept MP_JOIN. Phil: - more discussion on the list. - suggest to split out the two things. --------------------------------------------------------------------------------- 14: MPTCP Address Advertisement - Olivier Bonaventure: Olivier: - address management draft. - steal 9 bits from key in MP_CAPABLE option Alan: I don't like the idea using key, it's expensive. Costin: I don't think we need this, it seems its too complex for no big implementation gain. Rao: you can make implementation more simple if you don't keep address per connection basis. Olivier: we want to be sure that implementers support this. Fabien Duchene: what about the DNS part? It's in the draft. Olivier: Yes. there's discussion on how to use MPTCP without advertising addresses (by using DNS). Possible to do it with DNS. Drawbacks: cross-layer Costin: does it work for CDN? Olivier: should work correctly. Phil: should protocol doc say something about reverse DNS? Olivier: no. --------------------------------------------------------------------------------- 15: Improving Multipath TCP Backup Subflows - Olivier Bonaventure: Phil: does it change 6824bis? Olivier: Not very sure yet Rao: Is it a good idea to give absolute value? Maybe relative value or multiply factor? Olivier: It's a possible idea. Alan: Perhaps there are simpler ways of doing this Olivier: KT could measure the RTO and can turn their proxies, but we need a generic mechanism. Alan: This is important, but not sure this is the right proposal. Olivier: that is why we propose for measurements. we can think we need something inside protocol, or having a socket option is sufficient. Ana Brunstow: seems like existing mechanisms in SCTP. I mean Potential Failure mechanism (SCTP-PF) ------------------------------------- 16: MPTCP Proxy - Xinpeng Wei Phil: can't do consensus call yet, not enough people have read the draft. Need discussion on having a new flag. Lars: I see two uses for mptcp. One use is trying stretch your traffic as broad as possible so that it's hard to be intercepted. This is opposite. We might need to decide which way we'll proceed. Phil: We will get time at an interim meeting.