Multipath TCP (MPTCP) Meeting : IETF, Monday November 2nd, 2015, 9:00-11:30 Location : Yokohama, Room 413 Chairs : Philip Eardley Yoshifumi Nishida AD : Martin Stiemerling URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Pasi Sarolahti, Alan Ford --------------------------------------------------------------------------- 1: Intro - Chairs Phil Eardley: Discussion on interim meeting output and other progression between meetings: E.g. increasing version number, which opens possibility to redesign signaling About completion of 6824bis. Is it realistic to last call before next IETF? Christoph Paasch: depending on how much we change the spec. It may be difficult to get done by next IETF, e.g. if we want to inetgrate TLS, but will try to do that Shaoib Rao: why decided to drop implementation advice? Phil: Implementation People thought that the protocol documentation was sufficient Shaoib Rao: why do we support both 8-byte and 4-byte fields? why do we want to support 4 bytes? Yoshi Nishida: It's already discussed and consensus-called before. Shaoib Rao: Not sure why we need to switch both modes. Christoph: good point, people would not switch to 8 bytes, but will be longer discussion to change this. Linux implementation support receiving both variants, but never sends 8 bytes Shaoib: If timestamp option is mandatory, we would not need 8 bytes Alan Ford: we would not need to use timestamp option with 8-byte option, but some people might have other uses. Linux does not need to send both if it can accept. If we only support 8 bytes, what problem would it solve? makes simpler implementation, but it is only optional to implement Christoph: decission can be triggered by application based on envrionment Shaoib: receiver should need to support both variants always. what is the motivation for 4 bytes? Alan: saving option space Shaoib: Header option placement is also problematic, alignment is important Alan: space constraints are problem Christoph: implementation choice, can place options otherwise Yoshi: making 8 bytes mandatory, 4 bytes optional, would that make people happy? Alan: that's basically what we already have. If we spell out more explictly that sending is optional and receiving mandatory, would you be happier? (some discussinons continues) Conclusion: nothing fundamentally changes, but we spell out more clearly in the draft that receving both modes are mondatory and sending is optional. Phil: Implementation updates? Shaoib: implementing MPTCP in Solaris kernel, seems to be working well. Tested with linux. --------------------------------------------------------------------------- 2: Making Multipath TCP robust for stateless webservers - Christoph Paasch Yoshi: implementation status? Christoph: no implementation yet Phil: any implementation plans in Louvain? Fabien Duchêne: no plans for implementation at Louvain yet Shaoib: we can definitely try to implement but can't estimate when. Seems very complicated but does seem necessary. Yes, seems relevant. Yoshi: would it be backward compatible? Phil: this would not be backward compatible Alan: yes this is v1, not v0. Earlier you did not need to put key in data ACK, now you do need keys in data-ack Alan: would love to get consensus on this, so that we can work forward Phil: plan to give it a week or two, then do an explicit consensus call --------------------------------------------------------------------------- 2: Reflecting on the MPTCP handshake - Christoph Paasch Shaoib: (on deployment behind L4 loadbalancers): Hasn't cetrix already solved this issue cause they are using mptcp for load balancer? Christoph: Netscaler is L7 load balancer, so it terminates all connections. It has scalability issue. Alan: Green block can be a server? Christoph: Could be a server, but can only accomodate limited number of connections Yoshi: is token used only for server farms? Christoph: use is to identify the MPTCP connection, for single server this works well Yoshi: But, do you want to change meaning only for one use case? Christoph: It means increasing information that the token carries Alan: to summarize: you want to decouple token from key. makes lot of sense, seems fine. from signaling point of view: have flag to get key form external source, to say that key comes from TLS or somewhere else. Logical extension to what we got. Earlier we completely ran out of option space when trying to do this. Maybe we should wait for TCPINC, to see if they give some additional tools Christoph: worried about TCPINC, not sure how quick they are going to proceed. Phil: we should be able to finish our work earlier Alan: this does not need to be part of base v1 spec, but additional mechanism. Christoph: can live very well with the TLS, but one concern I have is locally meaningful token. Cause this would be a big issue. It would be great if this could be handled in bis version. Phil: are the two issues (loadbalancers, security) totally separable issues? Christoph: It's not connected. Using TLS can make token more explicit. Alan: TLS is a potential solution to the problem Christoph: might we just decrease the size of the keys, they are already sent in the clear. Are there any MPTCP deployments that are not using TLS, and think seeing keys in clear is fine. Alan: our goal has never been to provide secure solution, but something equivalent to TCP. Alan: this should be specified in a separate draft, at least initially... My concern is this could be a distraction, makes a jump away from where we are. Christoph: can we try to see whether we want to solve one of those issues? Phil: comments? personally think the datacenter case is important to solve. Should be designing for the present, not the future. Christoph: do you think it is worthwhile to have draft to support discussion? Yoshi: yes Phil: wider issue: should there be more flexibility about the security solution? Alan: we already have that kind of flexibility, haven't yet specified what the negotiation means. Would need to work through the details. Daniel Giffin: Both main TCPINC have been adopted to specify the negotiation of encryption protocol, also uses session ID (TCP-ENO), you might find that is useful. Christoph: We are deferring key exchange until after the SYN, could do it already in SYN, maybe this would make it simpler in terms of signaling. Phil's conclusion: make a draft about the possible solution space --------------------------------------------------------------------------- 3: Mptcp enduser use cases and enhancement opportunities - Chetan Harsha Christoph: is it separate TCP connections when MPTCP is disabled? (about slide on upload latency graph, with number of subflows) Chetan: yes Yoshi: why the red line behaves so differently with ups and downs? (Page 11) Phil: interested in hearing about protocol tweaks you might suggest? Chetan: not sure yet what the changes could be, currently exploring some parameters Christoph: there is generally need for more signaling in MPTCP, to indicate subflow characteristics, to help scheduling traffic, but it would be a bigger change is protocol. David Allan: if you are going to depend a lot on end-user signaling, makes life difficult for proxies. Shaoib: performance also depends on scheduler, that's why MPTCP results differ. Chetan: I agree. We'll check what scheduler make better performance in upcoming tests --------------------------------------------------------------------------- 4: LISA: A Linked Slow-Start Algorithm for MPTCP - Runa Barik Yoshi: if bottleneck is not shared, we don't have to use slow-start? Runa: we are reducing latency in non-shared scenario also. Some differences are explained that paths are both 3G or WiFi. Ilpo Järvinen: not sure why number of retransmissions affects the way you say Runa: because of slow-start loss it is explained, not understanding Ilpo's point Ilpo: If bottleneck link is fully utilized, it doesn't matter which order you transmit and completion time would be the same. Christoph: could be nice to see the patch and paper traces. Runa: will do, but currently a paper in submission. Phil: hard to understand Michio Honda: your point that slowing down slow start will reduce retransmissions, does not work in large delay-bw environments. Should see graphs relating to BDP. Current parameters are unrealistic. --------------------------------------------------------------------------- 5: Management information base for MPTCP - Fabien Duchên Shaoib: thank you, this is very useful. One thing missing: what are the combinations of the flows supporting MPTCP vs. TCP. Port numbers, addresses as well. Fabien: will look at them, because wanted to keep it simple, might be getting complicated, but is interesting Phil: good to have more feedback Yoshi: question to AD: when we define MIB, do we need cross-area review? Martin Stiemerling: should get MIB doctor review, might be useful to ask them when you have stable version, but before WGLC. Phil: should it be WG document before doing it? A: yes. Phil: plan to make this WG document before the next IETF Phil: Update of Louvain Linux implementation? in terms of getting to mainline kernel Fabien: Intel was doing the effort. Nothing much to report other than that. Christoph: there are lot of users, but no contributions that come back --------------------------------------------------------------------------- 6: MPTCP for FreeBSD update - Grenville Armitage Phil: anybody here interested in FreeBSD stuff (no hands) Phil: how much does the current version implement? Grenville: the URL on slides will describe the features Yoshi: Have you ever tried inter-operability tests? Grenville: Nigel tried some time ago