iOS uses Multipath TCP – Does It Matter?

When Apple launched the new release of iOS last autumn, networking gurus realized the new iOS uses MP-TCP, a recent development that allows a single TCP socket (as presented to the higher layers of the application stack) to use multiple parallel TCP sessions. Does that mean we’re getting closer to fixing the TCP/IP stack?

TL&DR summary: Unfortunately not.

Why Is MP-TCP Interesting?

Use case #1 – mobile networks: Mobile devices are often connected to WiFi and mobile (3G/4G) networks concurrently, but cannot use both connections simultaneously for the same data transfer – a TCP session is limited to a single set of IP endpoints, and since you cannot share an IP address between 3G and WiFi interface, a single TCP session cannot use both links (at least not in the inbound direction).

Use case #2 – data centers: Modern data center fabrics are commonly using highly parallel Clos fabric architecture. There might be tens of alternate paths between any two servers … and yet the servers cannot use more than one of them for a single TCP session due to 5-tuple load balancing restrictions (Brocade fares a bit better).

How Does MP-TCP Solve These Problems?

MP-TCP introduces a shim layer between the TCP’s application-facing API (socket API in most cases) and the traditional TCP stack. The shim layer establishes multiple traditional TCP sessions between the client’s and server’s IP endpoints, and multiplexes data of a single application session across them.

Multiple TCP sessions below the MP-TCP shim layer allow a mobile device to use all its interfaces to transfer data of a single application session (this is why Apple implemented it). Servers can use multiple TCP sessions to get more bandwidth or access to less loaded alternate paths – new TCP sessions using different source and destination TCP port numbers might be placed on a different set of ECMP paths.

Will MP-TCP Fix the TCP Stack?

No. A typical application still has to use getaddrinfo calls to get a list of IP addresses for a given host name, and try to connect to one of them (sequentially or somewhat more intelligently). A server (or service) must thus still be exposed as a single IP address; MP-TCP will not remove the need for Application Delivery Controllers (known as load balancers outside of marketing departments) or traditional multi-homing.

Latest blog posts in Site and Host Multihoming series

6 comments:

  1. But can this technology not be used in conjunction with something else (proprietary?) to improve transfers between iOS devices?
    Replies
    1. I don't think you need something proprietary, you can rely on any existing peer discovery mechanism (Bonjour?)
    2. As of today, Apple seems to only use Multipath TCP for the Siri application. Contact Apple if you'd like to use it in your own application by filling a bug report on http://bugreport.apple.com, see http://tools.ietf.org/wg/mptcp/minutes?item=minutes-88-mptcp.txt
  2. Why would I use MP-TCP in DCs ?, instead would use packet spraying at each hop and take care of re-ordering at the destination?
    Replies
    1. In DCs, Multipath TCP allows you to better use the multiple paths that are available due to ECMP between any pair of servers. See http://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp for a detailed discussion. Figure 20 shows the performance benefit in Amazon EC2
  3. See http://queue.acm.org/detail.cfm?id=2591369 for a recent tutorial article on Multipath TCP. The implementation in the Linux kernel is available from http://www.multipath-tcp.org
Add comment
Sidebar