On 1 February 2010 16:48, Scott Brim <scott.b...@gmail.com> wrote: > ... for certain definitions of "endpoint" :-). That is, MPTCP does not > need to know an identity for a whole node, anymore than current TCP > does. Other functions might, but MPTCP doesn't care what box or VM it's > talking to, it only cares about the other higher-layer endpoint. What > it needs for identification is something at the level of a "connection" > or "session".
That's exactly right. Also, much of the time MP-TCP will be working with one (and perhaps both) ends NATed. So MP-TCP really doesn't want to make any assumptions that any identifier that works for one connection will work for another. All MP-TCP connections are independent from the point of view of the TCP part of the stack, even if they happen to share IP addresses. What we've tried to do, at least for now, is to uncouple MP-TCP from other possible enhancements to the stack. Deployed, it would work right now on smart phones and so forth without any other changes to how anything is addressed. Indeed we were testing our implementation last week over WiFi and 3G simultaneously from a mobile host to an upgraded but single-homed server, and it worked very nicely and coped well when either the WiFi or the 3G lost signal. In the long run though, it would be great to have a way for an end-host to have some visibility into network attachment points and/or paths, even if they were several IP hops away. For outgoing traffic, that's the one part in the MP-TCP deployment story that could do with help from the network. - Mark _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
