
Decoupled from IP, TCP is at last able to support multihomed hosts - liotier
http://queue.acm.org/detail.cfm?id=2591369
======
nardi
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](http://support.apple.com/kb/HT5977)
Now we just have to wait for every server on the internet to support it. :-/

~~~
songgao
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.

~~~
mhandley
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.

~~~
throwaway7767
> 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.

~~~
mhandley
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.

------
erjiang
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](https://github.com/erjiang/tuntuntun)

------
IgorPartola
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...](http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)

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

------
pinhead
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/nsdi11/design-
implementation-and-evaluation-congestion-control-multipath-tcp)

[https://www.usenix.org/conference/nsdi12/technical-
sessions/...](https://www.usenix.org/conference/nsdi12/technical-
sessions/presentation/raiciu)

Others: [http://multipath-
tcp.org/pmwiki.php/Researchers/References](http://multipath-
tcp.org/pmwiki.php/Researchers/References)

------
AnthonyMouse
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?

~~~
sergiosgc
What is this M unit you are throwing around?

------
ClashTheBunny
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](http://frozenriver.net/SigmaVPN)

~~~
jhgg
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?

~~~
ClashTheBunny
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...](https://play.google.com/store/apps/details?id=com.frozenriver.sigmavpn)

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

~~~
liotier
> 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...](http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html)

------
loup-vaillant
> _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.

~~~
mhandley
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.

~~~
throwaway7767
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.

------
Scramblejams
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.

~~~
songgao
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](http://tools.ietf.org/html/rfc6824#page-51)

~~~
Scramblejams
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.

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

edit: typo

------
mcguire
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.

------
kerneis
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...](http://www.pps.univ-paris-diderot.fr/~boutier/source-specific-
routing.html)

------
vbit
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?

~~~
lucian1900
There are lots of protocols in current use that _aren 't_ SCTP.

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

------
liotier
> "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...

~~~
windexh8er
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.

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

~~~
mikeash
Why not? Muggings and such would become virtually nonexistent!

------
jbb555
Overcomplicated pointless workaround to cope with crappy mobile networks.

