Apple's Announcement on MPTCP Support and What it Means to Developers

Apple’s recent announcement supporting MPTCP in iOS 11 has created quite a stir with developers. Networking engineer Stuart Cheshire made the introduction at Apple’s Worldwide Developers Conference by stating “The iPhones that we all have are inherently multipath devices. They have multiple radios in them. For the most part, today we only use one radio at a time. It’s time we start having multipath protocols for multipath devices.” We at Carnegie Technologies have been saying that statement for quite a few years. It’s not news that all smart phones and many other devices today can support multiple networks out of the box, so it only makes sense that leaving one of those connections idle is wasting time and money, especially if it can be accomplished by just adding some enabling software.

Although Apple has seen the inherent benefits and results of bandwidth aggregation as it pertains to Siri, there are limitations to MPTCP that content providers and application developers need to understand and take into consideration:

TCP Only: A major deficit of MPTCP is that it only supports TCP and not UDP packets, so there is no support for VoIP and other real-time applications, such as mobile gaming. In addition, TCP with bandwidth aggregation suffers from head of the line blocking (HOL blocking). TCP requires in-order delivery, which means data sent first must be delivered first – and if that data is first sent over poor links, it can prevent good links from delivering data, even if the data has already arrived on the server. The result is a whole bunch of data that either never gets delivered or slows down just sitting there waiting. 

Only Aggregates for Max Throughput: Another limitation of MPTCP is it only supports aggregation for maximum throughput, so if that’s the only goal, it works. However, it’s important to understand that for some applications, such as streaming video, adding more bandwidth past a certain point does not improve the user experience. Furthermore, MPTCP aggregation for these applications may see data being unnecessarily transmitted over mobile, which results in higher mobile data usage and unhappy users.

Requires Kernel Changes to Server: While MPTCP supports session persistence for handover, in order for MPTCP to work at all, the application server must also be running MPTCP. With only an experimental Linux kernel module and no cloud providers supporting MPTCP natively, it could be a long time before all of the servers an application is using are upgraded. Until that time, the app falls back to regular TCP with all of its limitations.

Because of these limitations, MPTCP is not really targeted to operators, since it requires application support on the server end. It does gives content providers a mechanism to provide a better mobile application experience but only if they write a compatible type of application using only TCP, and they invest in the server side changes to support MPTCP. For some big providers, this may make sense, but others may want to wait until MPTCP is available on Android and/or Windows, which it currently is not.

Back when MPTCP first appeared, Carnegie quickly understood there was even greater potential of true Bandwidth Aggregation that took other goals and objectives into consideration, as well as cost, efficiencies and ultimately user preferences. Carnegie didn’t want developers or carriers to have to make a choice between their goals and the end experience. We accomplished this when we developed our Network Convergence Platform so service and content providers can aggregate those networks without adding infrastructure.

How does Carnegie’s Network Convergence Platform SDK stack up against MPTCP?

Multi-Device Support: Carnegie supports Apple and Android devices.

Supports Different Schedulers: For different types of applications, developers want different types of rules. MPTCP supports two types: max throughput aggregation and failover; while Carnegie supports max throughput aggregation, target throughput aggregation (great for video streaming and augmented reality), quality aggregation (important for real-time voice and video applications that stream at a constant rate and don’t benefit from just more and bigger pipes), failover, replication and more.

Policy Control: Applications can be developed to react quickly to changing network conditions and policies put in place by the developer to aggregate based on quality of service, best effort, highest quality or cost. Surprisingly, MPTCP and Apple’s support of it is silent on the matter of policy, which adds complexity to development and interoperability.