{"id":151,"date":"2011-04-03T22:59:10","date_gmt":"2011-04-03T22:59:10","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=151"},"modified":"2011-04-03T23:00:00","modified_gmt":"2011-04-03T23:00:00","slug":"ietf80-mptcp","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2011\/04\/03\/ietf80-mptcp\/","title":{"rendered":"IETF 80 highlights: Multipath TCP"},"content":{"rendered":"
I have spent the last week in Prague for the 80th IETF meeting<\/a>, and will be writing a few articles on the most interesting of the sessions I attended. \u00c2\u00a0Here's the first.<\/p>\n Multipath TCP is a neat way to allow TCP sessions to make use of more than one interface on the source and\/or destination - the oft-touted example being wifi and 3G on a laptop or phone. \u00c2\u00a0In effect, multiple standard (ish) TCP connections - termed subflows - are opened between every pair of source and destination addresses, and these subflows are aggregated together into what is from the application's perspective a single MPTCP connection. \u00c2\u00a0The load is balanced between subflows such as to make use of available capacity of every subflow but to favour less-congested paths.<\/p>\n Furthermore - and this is the really cool bit - subflows can be added and removed at ay time, so as you wander in and out of wifi coverage and in and out of 3G coverage, your connections will stay up, making use of whatever is available at the time - provided, of course, you're only talking to MPTCP-capable servers (or proxies: see below).<\/p>\n Now personally, being a lower-layer person generally, I would have implemented this in IP (and it already exists in Ethernet bridges :-) ). \u00c2\u00a0Indeed, the IETF has previously standardised various IP-layer solutions to this problem, e.g. Mobile IP and Shim6. \u00c2\u00a0But nevertheless there are advantages to implementing this in TCP, most obviously that it makes a lot of sense for the flow control algorithm to also be in control of the load balancing.<\/p>\n Apart from the ubiquitous pedantic debates on minor protocol details, a few noteworthy developments were presented in Prague. \u00c2\u00a0I will elaborate on those which interested me the most, but I refer anyone interested in the gory detail to the meeting materials<\/a> and (when they appear) the\u00c2\u00a0minutes<\/a>.<\/p>\n S\u00c3\u00a9bastien Barr\u00c3\u00a9 of UCLouvain presented a very neat demo of MPTCP in use, using their Linux implementation on UCL's (London, not Louvain!) testbed. \u00c2\u00a0In particular he demonstrated the effect of the linked congestion control algorithm to (simulated, using tc) changes in link speed, loss and round trip time on the two paths (using a live graph of each subflow's throughput whilst the various parameters were tweaked). \u00c2\u00a0Summary: with zero synthetic loss, all available capacity will be used as one would hope; tweaking the RTT only causes transient effects. \u00c2\u00a0With synthetic loss on one link (and all other parameters set identically), the majority of traffic chooses the lossless link. \u00c2\u00a0With equal synthetic loss on both links, traffic is equally balanced once more. \u00c2\u00a0(In fact I think the total bandwidth with 1% loss on both links was if anything slightly higher than the total with one lossless link but this was not commented upon; it is likely that it will be some time before the full ramifications of the new congestion control algorithm are fully understood - especially bearing in mind that \"simple\" TCP still surprises people occasionally!)<\/p>\n The UCLouvain team have produced a MPTCP live CD based on Ubuntu 10.10 (i386 and amd64) which can be downloaded from the UCL IP Networking Lab MPTCP site<\/a>. \u00c2\u00a0 They also have implementations for Android and the Nokia N900 phone.<\/p>\n Unfortunately the live CD appears not to work in VMWare Workstation (at least on my laptop) so I have not yet got MPTCP running. \u00c2\u00a0I intend to try it out soon though, and will report back if there is interest.<\/p>\n Notably, though, the UCLouvain implementation does not implement any security mechanisms yet.<\/p>\n The mobility use case I mentioned above has not been a primary focus of this working group. \u00c2\u00a0Mark Handley presented his take on the benefits of considering this mode of operation; he has preliminary results (detailed in his paper<\/a>) which suggest that MPTCP can help mobile clients achieve better performance as well as reduced battery usage (since wifi generally requires less transmit power, so using it in favour of 3G when available is advantageous).<\/p>\n However, the problem is that for now we cannot depend on servers to support MPTCP. \u00c2\u00a0Mark proposes the use of a proxy - probably provided by the mobile operator - which speaks MPTCP to the handset's various interfaces and standard TCP to legacy servers on its behalf. \u00c2\u00a0(And if the server does in fact support it, MPTCP provides a handy way to short-circuit the proxy: the proxy can instruct the client to add subflows direct to the server so it can send and receive data directly.)<\/p>\n There is a protocol design sticking-point though: it is not clear how the client should tell the proxy the address for the onward connection (noting that this is not an application-layer proxy, and this functionality would be implemented by the OS in its TCP stack). \u00c2\u00a0The target address would ideally be stated in the SYN packet, for security and to avoid the possibility of having a connection open to the proxy but not the final destination. \u00c2\u00a0But there is no space in the SYN header. \u00c2\u00a0(Alan Ford commented that perhaps they should wait until Google has some results on what happens if you put data in the SYN packet - they are trying this as part of SPDY.) \u00c2\u00a0Various other alternatives were discussed, which rapidlty spiralled down towards evil hacks (scrounging bits from fields which the proxy can interpret in spec-violating ways, running connections over a UDP tunnel to the proxy, etc...).<\/p>\n Unfortunately, useful as this would be, the sense of the room was that the protocol spec should not be delayed in order to add proxy support. \u00c2\u00a0This will come later, if at all.<\/p>\n Another stumbling block: an ex-Cisco-employee in the room drew attention to intellectual property rights on this idea (as he was obliged to<\/a>); a patent now owned by Cisco may cover multipath proxying. \u00c2\u00a0They developed this functionality for SCTP but the patent was allegedly written in sufficiently general terms to cover the MPTCP equivalent.<\/p>\n Mark Handley summarised UCL's paper, presented at NSDI11 the previous day, on the linked congestion control mechanism. \u00c2\u00a0Since I couldn't be at IETF80 and NSDI11 simultaneously, I refer you to the NSDI11 liveblog<\/a> by my esteemed colleagues Chris Smowton and Malte Schwarzkopf. \u00c2\u00a0Mark noted that as an introduction to the workings of this algorithm, the paper serves rather better than the current internet draft.<\/p>\n There is another paper, not yet published, which presents the results of running MPTCP in a datacentre environment in order to make use of multiple paths between nodes; he tested this using EC2, amongst other things, which claims to provides redundant paths (except when it doesn't - it has apparently been known to provide two paths which actually share the same wire!). \u00c2\u00a0MPTCP, he shows, does very well at pushing traffic off a congested hotspot when an alternative exists - and transitively pushing traffic off other paths to make room for that traffic, and so on. \u00c2\u00a0He has a great slide (slide 17 of this PPT deck<\/a>) illustrating this graphically.<\/p>\n Furthermore, where there are multiple relatively-uncongested paths available, MPTCP gives much better throughput: just under twice TCP with two subflows, and about 3x TCP with four subflows (slide 18).<\/p>\n There is not much new to say about the MPTCP API; the only changes since the last meeting have been bug fixes and clarifications. \u00c2\u00a0One point stood out which may interest some: the authors considered using the already-defined SCTP API for MPTCP, but were not in favour of this as not all SCTP functionality can be mapped onto MPTCP (the possibility was left open though, since this is just an abstract API spec: \"API developers MAY wish to integrate SCTP and MPTCP calls to provide a consistent interface to the application\").<\/p>\nMultipath TCP in a nutshell<\/h1>\n
Recent developments<\/h1>\n
Linux implementation<\/h2>\n
MPTCP proxies<\/h2>\n
Congestion control<\/h2>\n
API<\/h2>\n