Multipath TCP (MPTCP) Meeting : IETF96, Monday July 18, 2016, 15:40-17:00 Location : Charlottenburg I Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Mirja Kühlewind -------------------------------------------------------------------------- 1: RFC6824bis discussion Rolf: Siri data set? Christoph: connection are per-siri request Costin: Controlled number of iphones for this experiment? Christoph: Tuned off (and on) syn-cookies and collected data on the server Phil: 'loss' means third ACK is loss and you compare the amount of total data retransmitted Christoph: benefit where there is in general more loss Costin: I see the point but that obvious Christoph: making the third ACK reliable is important because it makes MPTCP fallback less where you need it Costin: depends because you can also get stuck with bad wifi because user try to stick to wifi Christoph: other case when you walk out of home and then wifi becomes lossy Costin: all per flow data? Christoph: yes Phil: Is there a transition/deployment problem when we bump the version number? Christoph: not worried about it because we know the servers and the version number to ensure that right client is connected to right server Costin: Good question. Other people that run MPTCP...? If both end under control, we know it's no problem. So are there deployments where you interoperate with other stacks? Please come and tell Rao Shoaib: How does versioning work if I don't have both under control Alan: Additional functional has to be added anyway. You can use negotiation or versioning. Specify highest number you support, e.g. client and server both support 1 it's fine. Client with version 0 and server only 1 doesn't work. Costin: I pushed to re-discuss version number bump because I'm really worried about transition because should not make things worse and should be worth the pain for the right reason. If client runs version 1 by default, server will drop it Alan: It's true but will only drop to TCP. Could even add flag that says a need a capability, server would also drop Costin: How to treat the 2% from Christoph, for long term. We need to understand the benefit Rao: Why not fallback to version 0? Costin: because that's an additional fallback Christoph: client falls seamlessly fall-back to zero Alan: not within the same connection. Trade-off between short term transition vs. long term simpler implementation that is desirable. Christoph: ???? Alan: if we only use flag, it's kind of version numbers anyway Costin: but you don't have to do happy-eye for versioning Alan: only if server also supports version zero Costin: Are implementors happy with that Phil: Olivier or Fabien? Oliver: no strong opinion; will add complexity to stack but don't have resources at ucl to do that. there are companies that could to it Rao: don't want to support two different versions but flags will also cause problems with clients. We can't have clients that cannot connect if there is no backward-compatibility Alan: there is a solution if server supports both versions. But modern servers might not do that. But if you want to get all functionality you have to do that anyway. Why not make it simple in the bis draft with the lessons we learnt Rao: not problem but costumer has version we need to work with and fallback and support it; might be problematic for implementation Christoph: integrating lesson learnt is now because there is not yet much deployment Rao: if we upgrade we should enhance on versioning Alan: field says that it's the highest version I support Rao: but server might only support one version; should we send back what is supported Alan: client support 0 and server only 1; it doesn't work. Otherwise it would. That's the only case where you wouldn't get mptcp compared to today. But defined protocol for experiments Costin: It's a large software change and we should not underestimate that effort; How can we support those feature without bumping there version number. Benefit are 2% of connection that will work, everything else can be provided without new version Christoph: saving option space Costin: don't care Olivier: should not be in situation where we are at version 5 and need to support all others as well. Need to tell which one is supported and fallback to regular TCP otherwise Alan: yes, that's an easy change and we can make this happen. Costin's point about flags: I have trouble to see how it fits in this working group; you have one flag always set to support all changes we want. let's try to be clean by making all changes Rolf: 2% is important. Open multiple connection and fallback. Phil: Hum now, two choices Alan: If don't change the version number, would need to figure out to make it happen otherwise because need larger options for additional functionality and that's not simple, or need to discuss if we still want additional functionality which I think we are Hum: - stick to decision to change version number: quite a lot hums - change decision and not bump version number: few hums Good consensus for first choice. Rolf (Jabber): number of samples in measurements? Christoph: was large -------------------------------------------------------------------------- 2: RFC6824bis updates - Alan Ford Olivier: G bit leaves option of using it at client side. Wouldn't it be better if the server makes the decision. Get rid of G bit if you just look at the length Alan: not key sends initially. simplified example if G is supported but otherwise server uses to support Olivier: TLS uses key from app. same key on client and server, if not how do you derived them Alan: each end derived both Oliver: two different key. in TLS you can very long connections and you can change key. if app changes key, you change as well? Alan: it would change because you ask key exporter every time. Olivier: when you receive mp-join you pass to app, application has to understand mptcp which more complicated than only socket option Christoph: Yes, we have to dive a bit deeper into how exactly key-renegotiation will affect MPTCP. Olivier: look at ssh as well because need solution for both Alan: both out of scope for the bis. but interesting idea to push key down Olivier: important for implementability Subodh Iyengar: webrtc does similar things; look at it Costin: ???? Christoph: it's good to mandate TLS Alan: if you want to use appl security, you have to use TLS Costin: the problem with this solution is that is only supports TLS over MPTCP for load balancing. You wouldn't be able to load balance regular HTTP traffic, for instance. Alan: Correct, but leaving flexibility for any application that is MPTCP-aware. Olivier: It's a good feature and support it. benefits load balancing Phil: Good discussion and think about what should be added. Are people in position to hum or need more time to read. Juliusz: is that a must implementation? Alan: it's optional; you list what you support in your handshake; you would not need to implement it Costin: i like the mechanism but don't know which problem it's solves; just load balancing with TLS. Given a stronger key because not send in clear. Maybe a bit better protection but does not solve real problem Alan: problem is decoupling the token from key Costin: left the key in limbo. why not given you token and given you key as well. Alan: it says i give you the token and you can get key as well. we don't have option space to signal both at once; I'd love to do that otherwise Philipp Richter from TUB: signal which kind of key material is used Alan: make the assumption that the app is mptcp aware and the app knows which key to use Wouter Cloetens: Means when accepting the connection the server has to provide it Alan: can provide it later, only need token. need to wait for new subflow until key is available Wouter: if app needs to be aware what you do with load balancers or proxies? Don't know which protocol is in there. mptcp is fully in kernel but with this you need transition to user space Alan: yes, it's a noted restriction for these scenarios. make it simple by not describing what the app should do. useful for TLS scenarios wheres it's easy because there could be new app in future Wouter: How do you consider app interface? Alan: need to look at, e.g. which direction would the key be pushed or would the application be queried? Wouter: kernel-only possible? Alan: can't see why not, but document does not constrain it, so it could be used like this Christoph: different methods how to react to this... ??? Costin: Two parts for load balancing: inappropriate for https or data packets where load balancing can be stateless. for token load balancer must remember where to first send the token. Olivier: we will not solve loadbalancing problem now, but maybe document all issues from existing stacks for next meeting. Costin: Terminate connection which is easy Phil: Olivier, you have contacts to get this info Olivier: can start doc and need input Alan: isn't this what christoph's doc was? Oliver: would be good to summarize all and then figure out how to solve the problem Christoph: update existing doc Vladimir Olteanu: load balancer can know token before? Alan: can't choose token Vladimir: load balancer can generate token and send it to server Alan: It's overhead Costin: overhead is not big but problem is when server has a collision; have evaluated it and it's a fair point Phil: probably not ready for hum because had another discussion but asking anyway Hum: - yes: this should be added to bis: very few hums - no: more hums - more time to think about it: quite a few hums, possibly more Need more discussion Phil: discussion was useful and raised new ideas and proposal to write doc is good and it's great that we have more work now -------------------------------------------------------------------------- 3: Multipath TCP Address Advertisement - Fabien Duchene Rolf: Is it likely that only part is load balanced in real life? Fabien: yes, private addresses Julius: in ipv6 there is a number of addresses per client Rolf: question was if some are load balanced and some not Julius: yes Alan: Echo bit, like that; no-join bit, like it; and backup bit for ADD_ADDR, like it. All three are good and why not add all of them. but community? Fabien: could be solved at routing level and you can choose to not advertise but maximize Alan: don't see benefit with community. If you have three addresses you could just advertise one Fabien: We always advertise all right now Alan: depends on your policy Philipp: I see one relevant usecase in making the configuration of dual-stack hosts much easier. You don't want to use MPTCP over equivalent v4 and v6. Alan: Not convinced. priority I'm also unconvinced. Fabien: implemented priority scheduler but most of time does not matter what server wants but client. server needs to know what client/smart phone wants to make smart decisions. just first fill congestion window of priority subflow and then others. Simpler scheduler implemented that only send on other interface when first priority is not available Alan: still slightly unconvinced but clearer Rolf: like priority; could be used for handover. echo option only wants to know that far end Fabien: it's in the draft, if you don't get echo you just use join. so you can decide to implement it. because otherwise you'll keep retrying when firewall blocks Phil (from mic line): other use case is overflow, do you need an all or nothing flag. Fabien: no because can have multiple interfaces and you can start with the best choice Phil: do use cases need that flexibility? Fabien: don't know if we need 3 instead of 1 bit but more flexible for future and 3 bits fit in mp-prior that is only used for the backup Rolf: how do you define full for the back-up decision? Fabien: look at the window and when the window is full you switch over. but we can further discuss scheduler. current example was simple to test it. but you can test others Rolf: but window is always full but growing Fabien: mean when no data can be send on this interface Christoph: only works if server is known. Can we do that for the general case and define what each subflow means? Fabien: left backup bt alone. just higher priority is better. push as much traffic as possible on highest and when highest becomes temporal unavailable you take the next one. the higher the more likely you'll use it Christoph: priority could mean even more, e.g. map to wireless or cellular and associate to interface that is used Fabien: yes could put more meaning in Rolf: that's implicit because if higher priority is on bad link it will move over more quickly wouter: DSL might have lower capacity and LTE might have better capacity and then you'll choose the more expensive link Rolf: LTE also has much higher delay and needs more time to grow your window Phil: draft has 4 proposals that are independent. start discussion on list of each separately. quite a bit discussion about priority here but less about the first two. Only heard a bit of support but no discussion. Author(s), please send separate emails to the list! Phil: next meeting Wednesday at tiergarten with 4 talks. if someone else wants a slot they are welcome. also talk about rechartering. ------------------------------------------------------------------------------------------------------------------------ Meeting : IETF96, Wednesday July 20, 2016, 14:00-15:30 Location : Tiergarten Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Olivier Bonaventure, Fabien Duchene ------------------------------------------------------------------------------------------------------------------------ 1: Introduction - Phil Eardley - draft-ietf-mptcp-experience submitted to AD - draft-ietf-mptcp-rfc6824bis works continue, last call as soon as possible - MPTCP enabled middleboxes : discussion later in charter - charter : will need to discuss with AD about paragraph on implementation in the charter ------------------------------------------------------------------------------------------------------------------------ 2: Network Assisted MPTCP - Bart Peirens Phil: What does the last bullet on the slide with the plain mode option means? Bart: In the SYN segment, you can put either the source or the destination as plain mode option. Explanation of use cases based on slide 9. Embed destination address to steer traffic towards HAG or embed original source address to send the address of the source so that that HAG is aware of it. Rao: Changes since last IETF. Why bounding a TCP connection to a single UDP flow. Would like to be able to carry traffic for the same system, not on a port basis. Med: Hybrid access there is no limitation of the port usage. Don't want additional demultiplexing. Your use case is different since you want to minimize the number of TCP connections. Med: Slide on comment#2 might want to inject plain mode in each packet for your use case, but not for plain mode option. Rao: wording needs to be changed. Med: use case is different, would require to send the plain mode option in each packet, but this is outside the scope of our drafts. We could discuss this in another draft. Bart: We will specify the plain mode option and it could be reused in other use cases, the same option can be used for other solutions Margaret Cullen: Slide on comment 1: You want GRE and the two modes you run MPTCP. Load share UDP traffic, TCP connection end-to-end. I'm working on a considerations draft and would like input. There is another mobile solutions that could be compared. This gives new criteria to add to the comparison document. Bart: We can work on that Alan Ford: Is there anything MPTCP specific in this proposal ? Margaret: the part specific is that you use subflows Alan Ford: transparent mode and plain mode option. plain mode indicates that the traffic is towards a target. Wim henderickx: We want to use this option to tell that if a flow originates from a client, we should not do anything from the flow. Option serves as a signal to indicate that we are in proxy mode. Bart: indicator and based on the length it can indicate the transparent or plain mode with the length of the option Wim: Indicates whether a flow originates from the host or the HCPE. Merge in one draft where the plain mode option supports different modes of deployment. We are going to merge the draft. Phil: Could have a simpler explanation of the different pieces and explain how they fit in MPTCP WG. Wim: Could explain how to use the options in different modes. Alan: I see what we are trying to get. I would caution against wrapping a lot of stuff that is generic into an MPTCP protocol specific stuff. Margaret: Trying to guess what the merged draft looks like. Within each deployment mode, will the impact on MTU be constant. Bart: Optionally up to two options in the SYN. No MTU impact. Margaret: For UDP traffic, what happens. Bart: Length of options depends on use case. Margaret: If you don't put data in SYN, there is no MTU impact. UDP is encapsulated. How will end nodes understand MTU Rolf: Concentrator is a heavy duty middlebox. Not a rela option because it is placed in the data. What happens if this information leaks if it does not work. Lars: Slide 9 : QUIC will deploy before a home gateway that does this. Is it a little too late ? Med: About UDP, this is detailed in the plain mode draft. There is no tunneling, but swapping. Plain is only in the SYN. We are in managed networks and can increase MTU. We have specified the fragmentation for the different cases. ------------------------------------------------------------------------------------------------------------------------ 3: Socket API for MPTCP - Olivier Bonaventure Rao: IETF don't do API... Olivier: There is SCTP, QUIC,... Idea to have a common API Alan: In first iteration of WG, cannot specify API. If RFC cannot provide all specs needed, maybe not sufficient, should be an update of RFC... Tommy Pauly: Lessons here should be recommendations, should have guidances. For path management, having user space managing all PM is very tricky, propose a common management Lawrence David: Protocol is multipath, with same problems as others (like QUIC). Need to make the API more generic for all, with no POSIX binding. Olivier: What's important is to get feedback from application developers. Based on this, can iterate (requirements,...) that can be extended to other protocols after. Where it goes at the end, TBD. Alan: Link with RFC Olivier: With current RFC, found some corner cases. Alan: should be an update to rfc6897. Wouter: Socket API of SCTP is similar. Why is it different from SCTP? Olivier: Implementation = Baseline for discussion Wouter: Did you looked to SCTP API? Olivier: Not tried because SCTP has also some issues, prefer to start from scratch. If looks like SCTP at the end or not, would be a lesson. ------------------------------------------------------------------------------------------------------------------------ 4: NFSv4.1 - Chuck Lever Med: Need other transports than TCP? Chuck: might need Rao: ... Chuck: ... Rao: looking at database applications needing this. Olivier: got feedback from user of dfs, using lo interface, with MPTCP to advertise address. With Socket API, can do better. Chuck: Need to populate info somehow. Rao: ... ------------------------------------------------------------------------------------------------------------------------ 5: LISA - Runa Barik Michael: Reduces the burst, ok for shared bottleneck, but not always for not shared, and results seems not so different. ------------------------------------------------------------------------------------------------------------------------ 6: Rechartering discussion Lars: NFS discussion might be interesting for MPTCP application for special needs. But not because it's multipath it's good to deploy on operators. Med: Disagree on second point. Interesting the work of proxy to provide guidelines for those people. Can continue experimental since exp. RFC. Can be used for various usecases. Interesting for the management stuff to recharter. Bart: Idea to compare drafts Olivier: Disagree, idea to have end-to-end MPTCP, but difficult because of Middleboxes. Having multiple address on a same interface is difficult today, ability to react quickly to network is a advantage of MPTCP, and should be standardized in IETF. Wim: In favor of proxy, to make sure CP and concentrators have interoperabilities. But seems to have a lot of interest with lot of authors. Lars: Why not having a BOF, because not a transport area. Margaret: Agree with Lars, MPTCP can be interesting for this, but proxy and so on is here a strange location to standardize here. Rolf: ... Margaret: Discussed at bar BOF, interesting to get everything together somewhere. Phil: idea to group multiple paths solutions somewhere Margaret: MPTCP, net approaches, lot of tradeoffs, would standardize more than one solution, where all is informed. Costin: If need to change MPTCP, do it here. Mirja: idea to document how to use multipath solution, can document here, but not here for operational guidance. Olivier: seems to have support for the API, should it be chartered? Phil: no time now, but probably on Mailing LIst.