Multipath TCP (MPTCP) Meeting : IETF76, Monday November 9, 2009, 17.40-19.40 Location : Hiroshima, Orchid West Chairs : Philip Eardley , Yoshifumi Nishida AD : Magnus Westerlund URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Scott Brim , Andrew McGregor ------------------------------------------------------------------------------------ 1: Introduction by Philip Eardley http://www.ietf.org/proceedings/09nov/slides/tsvwg-0.ppt NOTE WELL Charter summary Six work items to make progress on. Schedule ------------------------------------------------------------------------------------ 2: An Architecture Perspective on Multipath Transport by Janardhan Iyengar http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt * Goals of a Multipath Transport Architecture Document iljitsch: what does "compatible with middleboxes" mean? work through any and all of them? different paths though different middleboxes, or all paths through the same? Jana: Yes they can go through different middleboxes. * Protocol design considerations. Pete Resnik: What about failover? Can understand failover in mobility sense but what about here. What if all paths fail momentarily and a new path shows up quickly thereafter, like handoff. In that kind of failure case, are you going to be able to recover back? That would be a wonderful goal. Jana: we should decide that, but it is a worthwhile question. Costin: current thinking is similar to TCP. When get a timeout on a subflow, just move to a subflow where you can transmit. If TCP backs up enough, then have no interface over which to send data, the interface is dead. Tim Shephard: if SSH connection to somewhere and no data to send, it's idle. All my interfaces go away, and later get a new interface with new address, can session continue? Costin: yes it can. Jana: I think it's a great goal to have as well. Marcelo Bagnulo: With the behavior described by Costin, we can support mobility but behaving the way TCP does today. Don't get fully into the mobility area but have behaviors that can easily be extended to support mobility, that's good. Mark Handley: in response to Tim: yes, like to be able to resume, no technical reason why can't do it, modulo reasonable security story. If get that, no issue with protocol supporting it. Marcelo: security story is the same? Mark: in principle very similar. * MPS/PM implementation architecture. Hui Deng: Today most multipath hosts use a kind of connection manager. How does that relate to path management? Alan: the split like this is a way we could get a connection manager interfacing with little effort. Lars: Connection manager is a phone OS component that will pick an interface. you are associated with a WiFi interface, do you want to use it, and pick that one as _the_ interface. If you want to do MPTCP on that phone might want to use more than one so need to change CM. Costin: there's an implication that the CM gives you the user-defined policy, which path etc. Hui: CM is related to this kind of scenario: could provide default policy path manager could get policy from connection manager, could interwork with it. Jana: a flow manager manages a flow. If you use a couple of instances of connection manager, that's fine Mark: There's nothing in the protocol that reflects policy but we do need a way to tell a sender we don't want to use a particular path at a particular moment. We have given thought to it but not sufficient. Murari: we should be a bit careful about policy. The routing layer might well be policy driven itself, and if so, we should use its policy. Hui: need to coordinate before get too deep. Jana: I would certainly like to hear from those who have read the draft, all comments welcome. List is not exhaustive. ------------------------------------------------------------------------------------ 3: Multi-addressed Multipath TCP by Alan Ford http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt * General Operation Pete Resnick: can retransmit failures. If using a new path MUST also retransmit on original for continuity. Alan: must retransmit on it if you intend to continue to use it. Magnus Westerland: If I understand the current design, as I see it if you can be on-path for any path, you can hijack the whole connection bundle. Alan: You would have to add some flows and remove all the others. * Open Issues. Jana: option for data sequence numbers: do you need an option for this or can it be part of the TCP "payload"? Alan: would be like TLS, and that's not what they want to do. Jana: why not? Costin: why is it a good thing? Jana: you're using less option space that way. Mark: if you put it in the data you are vulnerable to a middlebox that may change the segmentation. Tim Shephard: that's only true if you put it in the data in particular ways, it's possible to avoid that vulnerability. Alan: if options cause trouble, we could move to payload Stuart Cheshire: add address option: this is to identify the endpoints after packet has gone through NAT? Alan: it's to say "I have another address". May not work if go through NAT. Stuart: if every host in the world thinks it's 10.0.0.2, does it work? Alan: No. Stuart: you have a problem. Costin: The answer to that is in Host Routing presentation, later. Scott: but your packets might get to the wrong host. Stuart: and it looks like it's the right host because the address matches. Alan: we need security. Juan-Carlos: Are we still planning to consider one-ended solutions? Philip: only two-ended are in scope for the charter Magnus: The focus is double-ended, but single ended shouldn't be prevented if it won't be extremely complicated Matt: Concerned about the need for seq no to be reliably delivered, and option collision with SACK, and if there happens to be loss happening at the same time. this sounds like it will create trouble. Martin Stiemerling: have you tested that the TCP option survives NATs/firewalls? Alan: There are firewall traversal tests under way Lars: Mark Allman published a paper on your chances of getting through with strange TCP options, gave about 0.2% failures. (http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps) Murari: We should not give up on one-ended that early, incremental deployment is better, and it is probably too early. Dan Wing: please show up at BEHAVE and GROW ------------------------------------------------------------------------------------ 4: Linked Congestion Control by Costin Raiciu http://www.ietf.org/id/draft-raiciu-mptcp-congestion-00.txt Ted Hardie: if go back to goals, this indicates need some time scale in which you're going to meet these goals. A flappy algorithm would meet the goals in some time scales. Sometimes an app will be happy with a poor algorithm. Iljitsch: we can't use the current value of the congestion window as an estimation of the loss rate, because it changes all the time. you need to use the slow start threshold for this. Tim: small comment on resource pooling experiment slide compared to "perfect". Why is "perfect" on there? Costin: We are aware that the current dynamics are not ideal but if we want to work in the current Internet we have to be fair. To adjust fairness, change alpha. Tim: need to adjust use of paths according to policy. Costin: Yes. Michael Luby: with combination of two flows, do they get same throughput as if had single path? Costin: Yes. Matt: algorithm in BSD code fails if window size in packets is bigger than MTU. Costin: multipath is more susceptible, so they fixed it. Round up by 1. Also look at modulo left by division and randomly increase by 1. A little bit of fixed point. Matt: So it's low-res fixed point, not precisely integer ------------------------------------------------------------------------------------ 5: MPTCP Threat Analysis by Marcelo Bagnulo Lars: flooding attack not possible with proposed scheme? Mercelo: Yes. Lars: How is this prevented in spec today? Mercelo: They do a three-way handshake. That's standard. But it wasn't there to avoid attack, it was there to traverse NAT. ------------------------------------------------------------------------------------ 6: MPTCP Application Considerations by Michael Scharf http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt Martin Stiemerling: will this be a completely different socket from tcp? Completely backward compatible so standard socket. Michael: This is a standard socket Martin: Should we not say you can enable MPTCP rather than disabling? Michael: It may be enabled by default. Joe Touch: implications on existing interfaces. Idea of returning "first" address pair. there is no order. "going down with the ship" scenario. Costin: biggest app that would break was BGP (if don't "go down with the ship") and Mark's presentation shows you how to make BGP work. Joe: every app that uses any sort of identification between endpoints, if IP address goes away and connection keeps going, it doesn't make sense. Costin: another host won't get your connection, that's impossible. Marcelo: build a security mechanism to keep that from happening. Magnus: Joe is concerned about cases that bind connections to certain hosts at certain time. Murari: the connection needs to die if the initial address goes away, if we want to keep tcp semantics Hui: cannot modify socket in hosting vendors. They have several layers above and below socket. ------------------------------------------------------------------------------------ 7: Routing of outgoing packets for mptcp by Mark Handley http://www.ietf.org/id/draft-handley-mptcp-routing-00.txt Lorenzo Vicisano: which first? May have different policies on different ISPs. If do source first, can have separate routing tables. Mark: if mobile host then longest prefix might not work for you if ingress filtering applies, but if you're a server and you have some controls, longest match can work best for you. Yuri Ismailov: Use case: send HTTP GET on one path. If decide to split download over multiple connections, does that mean 4 more sockets? Mark: No. one socket, multiple subflows. Costin: the ACCEPT on the additional subflows is done implicitly, don't need listen on socket to accept them. Julien Laganier: if using IPv6 don't know which interface ... Mark: for IPv6 need to be able to bind route to subnet address Matt: has this already been solved in a different space? Thinks using multi-path TCP is not that important. Most cases just need one flow. Do liveness tests on all paths and for the next connection just pick a good one. Policy may overwhelm multipathing.