| |||||||||||||
Multipath TCP: an overviewMultipath TCP: an overviewPosted Mar 27, 2013 0:09 UTC (Wed) by butlerm (subscriber, #13312)In reply to: Multipath TCP: an overview by marcH Parent article: Multipath TCP: an overview
SCTP is not designed for concurrent multipath transfer, although there are folks working to adapt it for that. Message boundaries, ordered and unordered message delivery, and logically independent message streams are the big differences.
The SCTP socket API is simple enough unless you want to communicate with multiple peers on the same socket or use multiple streams. Then it gets complicated.
(Log in to post comments)
Multipath TCP: an overview Posted Mar 27, 2013 3:30 UTC (Wed) by tterribe (✭ supporter ✭, #66972) [Link]
> Message boundaries, ordered and unordered message delivery, and logically
> independent message streams are the big differences.
Those can be done on top of TCP, too. See Minion: http://arxiv.org/abs/1103.0463
Multipath TCP: an overview Posted Mar 27, 2013 8:32 UTC (Wed) by butlerm (subscriber, #13312) [Link]
Minion looks like a great idea, and I hope they are successful.
Multipath TCP: an overview Posted Apr 4, 2013 7:45 UTC (Thu) by eternaleye (guest, #67051) [Link]
I thought it might be worthwhile to point out the main page of the Tng group, who created Minion: http://dedis.cs.yale.edu/2009/tng/
They also have a 'cross-layer negotiation' design, allowing the decision of *which* minion is used to be made on a per-connection basis.
Their general concept of splitting the Transport layer up is (in my view) a very useful one. Even though the IETF passed on codifying it into the literature, it's a very useful pattern in designing protocols - layer an endpoint layer, a congestion layer, an isolation layer, and a semantic layer.
By using UDP as the endpoint layer, you can (potentially) avoid some of the problems MPTCP had to engage in heroics to deal with.
By using (say) a portless variant of DCCP on top of that as congestion control, you have something that could still be within the kernel (after all, there are various protocols implemented in the kernel that go on top of UDP or TCP) but because of the benefits of using UDP as the endpoint layer you don't have the horrific barriers to deployment DCCP proper ran aground on. Plus, this makes per-link congestion control feasible without breaking end-to-end reliability - which has been a significant problem due to the absolutely atrocious interaction of TCP, wireless LAN, and multiple layers of retransmission latency.
Layering the isolation layer here (rather than on top of the semantics) is genius. Aside from that it means you only need a design for datagrams, and not streams (so you can use DTLS regardless of the application-level semantics), it also means that the (intelligent in braindead ways) middleboxes only know information that they might have a valid reason to touch. Beyond that, they basically get told to push off.
Finally, you can build just about any semantics you like on top, by using the resulting building block of secure, point-to-point, CC-friendly unreliable datagram channels.
|
|||||||||||||