Implementing MPTCP in a Shared Networking API

I'm looking at enabling MultiPath TCP in a common framework used by a few of my applications. The applications use a common API for network requests via a small wrapper around NSURLSession, so there usually aren't multiple instances of NSURLSession floating around. This leads me to an interesting problem as I want to create a generic NSURLSessionConfiguration that satisfies the majority of requests going through the configured session. Looking at the MPTCP options, there is NSURLSessionMultipathServiceTypeHandover and NSURLSessionMultipathServiceTypeInteractive. The docs state that Handover is for "long-lived or persistent connections" and Interactive is for "latency-sensitive, low-volume connections that might use cellular data". With that being said, I think the most appropriate option is Handover. Is this assessment correct?

Accepted Reply

Depends on the regional deployment of the backend.

Nothing is ever simple, eh? MPTCP matters more for HTTP/2 because that has longer-lived connections. For HTTP/1.1, which tends to cycle through connections quickly, MPTCP is less of a benefit because a lot of the time you’re just going to start a new connection anyway.

Anyway, back to your actual question. My general take on this is that you should default to

.handover
and only use
.interactive
if your session is dealing with requests that are known to be latency sensitive. The
.handover
mode gives the reliability benefits of MPTCP without any real costs: It only uses WWAN if WWAN is required. In contrast, the
.interactive
mode uses small amount of WWAN all the time. If latency is critical than that cost may be acceptable, but it’s not something you’d want to enable without a clear benefit.

If you’re interested in the background to this I highly recommend watching the relevant section of WWDC 2017 Session 707 Advances in Networking, Part 1.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

First up, are you using

NSURLSession
for running HTTP[S] requests? Or using the much-less-common
NSURLSessionStreamTask
for running a TCP connection?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

100% of all of the requests are to HTTPS endpoints for RESTful API calls, so they are all data tasks.

100% of all of the requests are to HTTPS endpoints for RESTful API calls …

OK.

Is your server HTTP 1.1 or HTTP/2?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Depends on the regional deployment of the backend. Most are HTTP/1.1 and a few are HTTP/2, but we are slowly transitioning to more HTTP/2 deployments.

Depends on the regional deployment of the backend.

Nothing is ever simple, eh? MPTCP matters more for HTTP/2 because that has longer-lived connections. For HTTP/1.1, which tends to cycle through connections quickly, MPTCP is less of a benefit because a lot of the time you’re just going to start a new connection anyway.

Anyway, back to your actual question. My general take on this is that you should default to

.handover
and only use
.interactive
if your session is dealing with requests that are known to be latency sensitive. The
.handover
mode gives the reliability benefits of MPTCP without any real costs: It only uses WWAN if WWAN is required. In contrast, the
.interactive
mode uses small amount of WWAN all the time. If latency is critical than that cost may be acceptable, but it’s not something you’d want to enable without a clear benefit.

If you’re interested in the background to this I highly recommend watching the relevant section of WWDC 2017 Session 707 Advances in Networking, Part 1.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Quinn.