
“Multipath” TCP Could Turbocharge Bandwidth - indus
http://www.technologyreview.com/news/519646/how-apple-could-boost-speeds-20-times-on-the-next-iphone/
======
windexh8er
I've had this discussion about a dozen times now. MPTCP is a hack, plain and
simple. It does not address the fundamental flaws of TCP, nor does it attempt
to use something better suited for the job of, say, streaming media like SCTP.

TCP is broken in today's age. It's still reliant on upstream single path
routes that are mainly devised via BGP and OSPF. These two routing protocols
are showing age and suck at multi path without significant configuration and
tuning.

MPTCP is a great idea if 1) you don't care about session state which is a
fundamental to security controls 2) you don't care about QoS being impacted by
differing paths 3) you know the network end to end. MPTCP wasn't designed with
end consumers in mind.

Think about this. PMTUD doesn't work today because people still don't trust
ICMP type 3 code 4. If everyone did the Internet would work much better and
buffer bloat wouldn't be as much of a problem (that you likely have no
awareness exists).

MPTCP is a hack as Apple has deployed it and it's not going to improve the
upstream problem. It will, in fact, make things worse if they open it up
beyond Siri. Do something innovative and start solving for TCP, not abusing it
even further than it is already.

Our networks are ridiculously inefficient. I for one will not applaud Apple as
tone this is just a greedy hack that won't pan out to much beyond what you see
today.

~~~
lambda
So, how long has SCTP been around? And how many consumers are actually able to
use it?

The problem is, IP and TCP and NAT and firewalls and BGP and OSPF are all
fairly fundamental facts of the network we operate on. There's no way to
unilaterally move to something else without, well, breaking the internet. IPv6
has been around for 17 years, and we're running out of IPv4 addresses at an
alarming rate, yet IPv6 still has single-digit (or less) penetration.

The advantage of MPTCP is that it operates over what look to any observer as
regular TCP connections. This means it's compatible with all of the NAT and
firewall technologies that know how to deal with TCP, while still giving you
the bandwidth and reliability advantages of utilizing multiple paths.

I'm not really sure how your example about PMTUD is supposed to support your
case. That's an example of a technology that doesn't work within the
constraints of the network as it's actually built, in which ICMP is not
something that can be relied upon. The whole point of the MPTCP hack is to
make it compatible with the existing network, and fall back gracefully to a
single path TCP connection if that doesn't work, rather than something like
SCTP which simply doesn't work at all if you're behind a NAT that doesn't know
what SCTP is.

What session state that is "fundamental to security controls" does MPTCP lose?
There's nothing that I can think of that you could do with MPTCP that you
couldn't do with just two or more single path TCP connections. I'm also not
sure why you think that QoS would be particularly impacted by multiple paths;
you can always just use a single path and leave the second path only as a
fallback, and then the QoS story should be exactly the same as you had
originally, just with higher availability. Does SCTP do something special to
make QoS work better over multiple paths? And why do you think that MPTCP
assumes that you know the network end-to-end? Everything I've seen about it's
design seems to imply that they were very careful to design with assumptions
of the most degenerate possible network conditions that are still successfully
able to transmit plain old TCP.

Multipath TCP isn't something that Apple just created unilaterally; it's been
in development at the IETF for years with several implementations on different
operating systems, and lots of experimental data to back it up. I think it's
an excellent attempt at getting a working multipath solution out there, that
doesn't require boiling the oceans like SCTP or IPv6 do.

~~~
windexh8er
I wasn't advocating SCTP - I was simply using it as an example. Anyone can use
it, just like any other protocol. Most operating systems support it today, but
again, not advocating it as the "replacement", just using it as an example.

There are no bandwidth or reliability advantages of using multiple path IF you
have constraints of network devices upstream. Why? Generally because upstream
you're going to be traversing the same endpoint path as you converge. You may
have disparate paths for a number of hops but generally your Internet
connections on, say, mobile and cable will be geographically tied to the same
region (let's say Chicago). There is no guarantee here for reliability
(especially if both hosts are NOT multi-homed) - and if there is a problem the
closer it is to the destination will exponentially increase the chance that
the path for both ends up broken. Beyond that MPTCP doesn't "look" like
regular TCP connections - they _are_ regular TCP connections. The only magic
is on the source. Where MPTCP solves problems is 1) in wireless handoff
situations where the end user doesn't want to drop a session 2) avoiding
setting things up like link aggregation in a DC environment (although this
means multiple L3 paths must exist which is also additional infrastructure in
most cases).

PMTUD was an analogy. It is something that's implemented everywhere and
doesn't work. If organizations don't want MPTCP to work - they can very easily
stop it through network controls. By default most session aware devices
(firewalls, load balancers, etc) can break MPTCP by default since if they
don't have the entire session they often will not allow the traffic.

The bases tenant of MPTCP breaks security models by splitting same session
traffic over multiple TCP sessions. If part of a conversation goes through
firewall A and the other goes through firewall B you lose context. If your
firewall is L7 aware you will likely break the application tracking component.
I am fully aware that each subflow is it's own session (in terms of
setup/teardown) - however new security technologies will need to do extensive
corroboration to fully understand flows across disparate parts of the network,
and yes there is fallback for when things break.

I don't think MPTCP assumes anything. My point there was that if all the stars
do not align you went through extra overhead to do nothing. Back to PMTUD -
it's great when it works, but 99% of the time it doesn't.

Finally I realize that Apple has not created this. I've tested MPTCP in
operational environments back in 2010 (and have been following it since 2009).
The point is, I've seen it in operation and it's very niche focused on where
it will showcase significant advantages. It is excellent work, I don't
discount that. The reality is, however, that it's not what everyone is making
it out to be. I've used it, I've implemented it, I've tested and researched
it. Just because Apple is testing it - doesn't mean anything.

Ultimately I feel that closed minded statements around BGP and OSPF are half
the misunderstanding of the fundamental problems. LISP is far more prevalent
than you likely realize and nobody is boiling the ocean on that front and
finally - IPv6 has far more than single-digit penetration. I'm pretty sure you
pulled that one out of thin air. Over 40% of my home Internet traffic is IPv6
- just FYI.

------
lambda
I'm not really sure why the article mentions both Multipath TCP and network
coding. They are very different techniques at different layers of the stack.

Multipath TCP is a way of making what looks like a single TCP connection at
the socket layer actually be transmitted over several TCP connections over the
network, allowing transparent sharing of bandwidth between links and roaming
or failover from one link to the other. It's an actual protocol, designed to
be transparent to applications and compatible with all of the hardware and
software out there that mucks with TCP connections (stateful NATs and
firewalls, proxies, etc) by making each connection act just like a regular TCP
connection.

Network coding is a technique for reducing the bandwidth used in broadcast
applications or applications over very noisy channels. The basic idea is that
rather than sending packets directly, you can send the XOR of various packets
(perhaps the XOR of new packets with packets that you already know the
recipient has because they sent them, or that the recipient has already
acknowledged), and the recipient can do some basic linear algebra to solve for
the contents of packets that they haven't yet received based on ones that they
have already received. This can allow you to reduce bandwidth usage in
broadcast applications, and reduce retransmission round trips over noisy
channels.

The problem is, it seems better suited for channels that have those
characteristics (noisy and broadcast channels), which describes link-layer
wireless protocols, but not transport layer protocols like TCP in general. And
to apply it to something like TCP would require fundamental changes in the
protocol, changing how ACKs are handled to have them reply not based on a
single packet but based on how much information they are able to solve for
based on the packets received so far. I'm not sure you could do it in a fully
backwards compatible way that would make sense for end-to-end multipath TCP.

And as far as I can tell, the network coding research mentioned is, well, just
that, mostly research, while multipath TCP is already a series of RFCs, a few
experimental implementations, and at least one deployed implementation.

It seems like this article is just trying to connect this research to the
recent story about multipath TCP in iOS 7, when there really isn't any direct
connection between the two. It sound more like a fluff piece about a
professor's research than anything actually interesting (and frustratingly, it
doesn't seem to actually link to the research that it mentions either, nor
even provide enough a citation to find it).

~~~
superails
> and frustratingly, it doesn't seem to actually link to the research that it
> mentions either, nor even provide enough a citation to find it

Citations don't sell. Sex, violence, and realistic-sounding, baseless, faulty
journalism does. Welcome to the 20xx's. :)

~~~
pm90
Disappointed that this holds for TR too.

------
AndrewGaspar
Don't both endpoints have to support Multipath TCP? So I imagine we wouldn't
see real gains for standard HTTP traffic in a good long while. Unless Apple
passes the traffic through some intermediate proxy, of course...

~~~
twoodfin
Yes, as the article suggests, Apple is using it for reliability and latency
for their built-in services.

But if they can do it, we can't be that far from NetFlix, Google and others
being able to flip the switch for their high bandwidth products.

I am curious whether iOS exposes multipath to applications.

~~~
derefr
I imagine it'd be pretty similar to the adoption curve SPDY has seen. First
Chrome implemented it to talk to Google's servers, then a few other websites,
and now nginx will do it for you "for free."

------
random2
It would have been nice if the author would have included a reference to the
actual open-source project that powers this, along with the authors
[http://multipath-tcp.org/mptcp_stats/authors.html](http://multipath-
tcp.org/mptcp_stats/authors.html)

~~~
rsynnott
Huh? That's the Linux kernel MPTCP project. The article is talking about
Apple's use, which rely on a Cisco implementation and an Apple implementation;
pretty sure neither are based on the Linux impl.

------
contingencies
Aren't well-seeded torrents essentially multipath TCP? The main thing they get
around seems to be per-flow limits instituted on network provider routers and
SPOFfy fileservers, the first being a flow deSPOF, and the second being an
endpoint deSPOF. Multipath TCP (though I'm not very familiar with it) seems to
be only a flow deSPOF, and therefore only solves half the resiliency domains
solved by torrents. Of course, they are no doubt faster to set up and don't
require half the world to be interested in something .. both significant
benefits.

------
asperous
Isn't part of the point of wifi to dodge your 4G usage limits?

For pcs and the like, very occasionally I do run into a situation where I am
connected to two completely different networks. Windows automatically balances
them, which is nice, but only at the applications level which is kinda a
bummer. It should be by request. This technology which zippers the packets
would be really cool.

~~~
toomuchtodo
If its only being used for Siri and Maps, those are both low-bandwidth
applications but with high expectations with regards to latency and
availability.

I wouldn't recommend it for Netflix or bulk data transfers, but definitely for
scenarios where you expect a response almost immediately (Siri, Navigation,
Google Now, and so forth).

------
asynchronous13
Multiparty sounds great and all. But I'd be happy if they could make a laptop
use both a hard-wired Ethernet and a wifi connection at the same time. Is it
really that difficult?

Not for bandwidth, I work with embedded systems. If the wifi is active, then
it's not possible to connect to an IP address on the Ethernet port (OS X and
Win7). Subnet doesn't matter, and re-arranging the priorities of the network
devices doesn't help either.

~~~
drakaal
You can "shotgun" connections but hardwired and wifi usually isn't a win since
the wifi will be more error prone and higher latency than the wired. So if you
have both you should probably just do the wired.

~~~
asynchronous13
Like I said, for embedded systems. The wired connection is not an active link
to the internet.

