Decoupled from IP, TCP is at last able to support multihomed hosts | Hacker News Reader

Decoupled from IP, TCP is at last able to support multihomed hosts

queue.acm.org

191 pointsliotier44 comments

Wow, I didn't think this could be done this transparently. This has the potential to be huge, if it's adopted. Crossing my fingers.

Specifically, I can't wait till I can actually use my phone as I'm walking away from a Wi-Fi hotspot (which is very common).

Edit: As noted in another comment, Apple apparently adopted MPTCP for Siri in iOS7! http://support.apple.com/kb/HT5977 Now we just have to wait for every server on the internet to support it. :-/

Well, I'm not sure if I mis-configured something, but I was not able to trigger MPTCP traffic from iOS 7. I was using a MPTCP enabled Linux box, serving video files over HTTP. But all I saw from iOS was traditional single-path TCP. If my tests were conducted correctly, Apple might have disabled MPTCP for third-party services.

ISTR that Apple enabled it _only_ for Siri, probably (as you said) to reduce perceived ios7 crappiness (likely because users don't care that things are broken through no fault of Apples, they just see brokenness)

I had always assumed that it was because Apple controlled both the client and server infrastructure in that case? Whereas with web browsing, they obviously don't control of the servers.

As I remember Apple was only using it for Siri (and possibly iCloud/etc) to handle the WiFi/LTE transition more smoothly than "wait for the timeout".

I don't think it's enabled for apps, at least my default. You may have to pass special options when creating the connections in your app.

Our understanding is that Apple have currently only enabled MPTCP for Siri. This probably makes sense - Siri isn't mission critical, but is very delay sensitive. Using both LTE and WiFi for a Siri connection should allow them to get low delay in the case either has a problem. They're using Citrix Netscaler at the server end, which does have MPTCP support.

Disclaimer: I'm one of the authors of MPTCP.

> Our understanding is that Apple have currently only enabled MPTCP for Siri. This probably makes sense - Siri isn't mission critical, but is very delay sensitive.

I have to disagree that it makes sense to cripple APIs and give preferential treatment to certain software. If the support is there, give developers an API to use it!

Also, good job on MPTCP - it's awesome :)

EDIT: I'm being downvoted, but I'd really love to hear a justification for why it makes sense for apple to restrict features to use in apple-developed software only.

Good engineering practice: you have an untried technology operating in a complicated environment and in-house testing can only get you so far. Looking at this "in the wild" in a constrained way where you control most of the variables is an obvious next step.

Not sure why you're being downvoted, and I've no direct insight into Apple's deployment decisions.

But I'd guess they're concerned that deploying MPTCP could cause problems with middleboxes in some environments. Siri is a good way to test the water. First, they own the servers, so they can ensure there's no problem on their end. Second, Siri isn't mission-critical in the way IMAP or HTTP would be, so if there is a problem, it's less of a PR disaster for them.

Personally, I'd also prefer to see an API that developers can use to enable it, but I'm OK with them taking it slow at first. Every cellular and WiFi network on the planet got to see how their middleboxes handle MPTCP, so having them test the water like this makes life so much easier for anyone else later.

Potentially stupid question: since MPTCP is built on normal TCP connections, does that mean that you could potentially implement MPTCP entirely in an application without cooperation from the kernel? Or does the fact that you need to set special options is the TCP packets mean that kernel support is required?

You will need to be able to send raw IP packets. I don't know if iOS lets you do this, but given that possibility and the willingness to make your code run very slowly (lots of kernel<-->userspace transitions) you can do it.

I was actually working on server-client software in Go to allow multihoming IP connections.[0] The original use case was to load-balance packets across wi-fi + 3G or other connections. It's not quite user-friendly yet, but with a little work it could use new connections as they come up (maybe poll ifconfig?).

You'd of course need to install the software on your outside server that will forward packets for you, but a DO droplet would be great for that. It'd also work for the case where your router is your server and you shift between wired and wireless.

[0] https://github.com/erjiang/tuntuntun

Offtopic warning: the following has nothing to do with MPTCP.

I was wondering why SCTP [1] never took off. It sounds like a shoe-in for HTTP and other web-based protocols. All the application level protocols that must come up with a mechanism for communicating the length of the payload... Why not have that built into the transport protocol? Of course you do have streaming to deal with, but streaming can still be solved with SCTP same as what we do now in HTTP: say this is a stream, so the client keeps reading.

Then I saw it: NAT. Fucking NAT strikes again. Once IPv6 takes over [2], I hope to never speak those three letters in that sequence again.

[1] http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...

[2] https://www.google.com/intl/en/ipv6/statistics.html

UCL and others have done (and are actively doing) really cool work on MPTCP.

https://www.usenix.org/conference/nsdi11/design-implementati...

https://www.usenix.org/conference/nsdi12/technical-sessions/...

Others: http://multipath-tcp.org/pmwiki.php/Researchers/References

An interesting feature here is that in theory you could have a host with two 20M connections and a host with a 10M connection and a 30M connection and by using more than two subflows they could communicate at 40M.

I wonder if they've considered what happens with this for hosts that are very multihomed. If you have two hosts that each have 25 addresses, do you actually want 625 subflows? Or do you want to countenance the possibility that only one address on each host is fast and you didn't create a subflow between them because you didn't try every possibility?

What is this M unit you are throwing around?

Why don't people just use a stateless VPN like SigmaVPN[0]? Also, since android is linux, why not use one of the many bonding options?

[0] http://frozenriver.net/SigmaVPN

How does one set bonding for SigmaVPN? Is it as simple as creating multiple tun devices and then bonding them together with ifenslave? Or is it more involved then that?

I'm picturing more using SigmaVPN to auto-roam to the next Internet connection but still have the same IP for continuous IP connectivity. The desctiption[0] says: - Seamless handover between WiFi and GSM/3G.

Bonding wouldn't require SigmaVPN, just the regular Linux tooling and driver/kernel support.

[0] https://play.google.com/store/apps/details?id=com.frozenrive...

No SigmaVPN, because it's lacking support for a major platform out there.

Maybe tinc-vpn would be an option though.

No bonding on Android, since there's No App For That (at least I know of none?). Doing that in a terminal, on a phone, is really the last thing I'd like to play with.

Or did I misunderstand your second suggestion?

FWIW, if anyone is looking for a dead simple bonding tool, I'd suggest Connectify Switchboard: http://www.connectify.me/switchboard/

I'm using it to bond two 4G interfaces (Verizon + Clearwire) on the train at this very moment. Need to remember to bring a USB wifi adapter next time so I can add the Amtrak wifi to the mix!

edit: No linux support though. :/

What has Apple been using for their multipath connections in iOS?

> What has Apple been using for their multipath connections in iOS?

iOS7, released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP - http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013...

> The measurements revealed that protocol designers can no longer assume that the Internet is transparent when designing a TCP extension; and no TCP extension can assume that a single field of the TCP header will reach the destination without any modification.

The Net Neutrality situation is worse than I thought.

We were really surprised by what we found - especially just how prevalent middleboxes that are aware of and modify TCP packets actually are. The results are a couple of years old now, so things have probably got even worse. But that's mostly separate from the network neutrality debate. You don't need to modify packets to shape them - our methodology would not have revealed shaping.

I think the network neutrality debate is a lot wider than just "Don't shape traffic". It's about keeping the internet a dumb transport, and "smart" (what a misnomer) middleboxes very much go against that goal.

Of course, as part of my job, I manage several of these boxes. I flagged these concerns when they were bought, but was overruled. So I guess we're relying on the good graces of the vendor to update their software to support MPTCP and any future modifications, otherwise these boxes become expensive doorstops.

Could this be applied within a NATed network without cooperation of the server outside the NAT? That way you could at least move your laptop back and forth between wired and wireless connections inside the office or home without breaking all your sessions.

Yes! The design of MPTCP specifically takes that into considerations since most of hosts are behind a NAT. It basically initiates may normal TCP connections as subflows. All the middle-boxes would see normal TCP connections while the two MPTCP-aware endpoints split/aggregate traffic using multiple subflows.

[0] http://tools.ietf.org/html/rfc6824#page-51

So you need an MPTCP-aware endpoint at the other end of the connection? I was imagining something that could be implemented unilaterally by a savvy home/office user just to ease the disruptions of switching between wired and wifi connections inside a NAT.

hmm.. well I think you can always use some sort of proxy, like VPN or an application proxy.

edit: typo

Sometimes I regret all the time and effort I put into network protocols. Particularly when I look at some new advance and it just makes me sad.

Sure, you could design some new protocol. Except that it could never actually work in practice---the infrastructure will see to that. Instead, it's better to treat a TCP connection with a fixed port of 80 (or 443, if you're so inclined) as precious and slather on some more bandaids until it stops not working at all.

Multipath TCP becomes really useful when coupled with source-sensitive routing. Some on-going work on this topic (based on the Babel routing protocol for mesh networks):

http://www.pps.univ-paris-diderot.fr/~boutier/source-specifi...

For the server side, why not just use SCTP which not only has multi-homing, but also reliable datagram messaging? Are there issues using it intra-datacenter?

There are lots of protocols in current use that aren't SCTP.

TCP multihoming would work for most protocols/apps out there.

> "Multihoming is becoming the norm instead of the exception"

Well - at least Multipath TCP spared us from solving that use-case with generalized BPG usage on mobile devices. Too bad, it could have been fun - in a way...

BGP?

Border Gateway Protocol

He said BPG.

BPG is the dyslexic's BGP.

Obviously at least several people didn't know what BPG was, and I have been spamvoted down for it.

You likely don't understand "BGP" at a fundamental level. Considering you need a well known and agreed peering agreement - BGP is not designed for use on end-points in any dynamic peering fashion. It is an external "routing" protocol. Hosts leverage "routed" protocols (e.g. IP). But, say, in our fantasy world your iPhone could take a full Internet routing table (it can't). BGP is not designed to deal with very long prefixes (/32 host routes) and in fact most peering agreements will flat out block prefixes longer than a /24 based on policy.

BGP on mobile devices would never have been fun and never worked. If each mobile host that came online required BGP around the world to update it's FIB we'd be in a world of hurt (partially because you can't aggregate host routes as you don't know where they're originating transit from). The more routes you add to BGP the worse BGP becomes from a maintainability perspective.

TL;DR Don't mention BGP on mobile devices as fun to any network engineer unless you're using the reference as a bad joke.

Yes, it was sarcastic - I wouldn't let everyone carry a small nuclear device either.

Why not? Muggings and such would become virtually nonexistent!

Overcomplicated pointless workaround to cope with crappy mobile networks.

Reply on news.ycombinator.com