
Mobile TCP optimization – lessons learned in production - luu
https://www.snellman.net/blog/archive/2015-08-25-tcp-optimization-in-mobile-networks/
======
asmithmd1
They are breaking the TCP contract:

"The server sends the first part of the response which we ack"

I have seen this strange behavior on mobile networks: the server sends a
heartbeat to a mobile client every 10 seconds, I pull the battery on the
mobile client and still get an ACK for a minute or so. Now I have to bring the
ACK up to the application layer so I know whether I am actually talking to the
device, or the mobile network is lying to me.

~~~
wtallis
They're breaking the TCP contract because they're strengthening the IP
contract. When you've got a re-transmit facility sitting below TCP, it's
reasonable to make some speculative promises. It's not reasonable to keep
ACKing for a full minute or to ACK more than a handful of packets, though. But
especially in the case where you've got more knowledge of the last-mile link's
loss characteristics than the congestion control algorithm at the server
endpoint, you can make some pretty nice bandwidth/latency tradeoffs.

~~~
hinkley
True, they really should stop acking when they hit the window limit.

------
joshbaptiste
Amazing their how much data they can process by side stepping the kernel and
building their own custom TCP stack in userspace. Think the BSD folks are on
top of such technology of have a TCP stack completely in userspace.. great
presentation.

------
chetanahuja
Kudos for a fantastic presentation combined with fairly detailed notes about
the complexity of of mobile networks. I'm sure it took a huge amount of time
and effort.

One a meta note, it's rather disappointing to see such fantastic content being
relegated to 9 comments in almost an entire day.

------
corysama
Same guy being interviewed in a software-defined-networking podcast

[http://blog.ipspace.net/2015/03/tcp-optimization-with-
juho-s...](http://blog.ipspace.net/2015/03/tcp-optimization-with-juho-
snellman-on.html)

------
rkwasny
So mobile networks this days do MITM to all TCP connections, nice. Happy time
to debug problems ....

~~~
kevin_nisbet
As someone who has worked on mobile networks, and has a great deal of TCP/IP
experience on CDMA, UMTS, and LTE networks, unless you know the mobile network
inside and out, as a customer you likely won't be able to troubleshoot the
network anyways.

Now you're right on another aspect, is that additional complexity is a pain,
and can make troubleshooting more difficult, but there are many steps of
complexity in a mobile network, far beyond this. If this works in the majority
of cases (and the claims of fall through do work), then there is a massive
upside to this type of product.

So one additional hop in the complexity of the 3GPP standards and associated
equipment, than on top of that with a carrier grade NAT, a firewall, a cache,
and perhaps an IDS system or two, and you've already got many potential places
for failure. I think we just need to understand that these systems are
complex, and try and understand and build them as robustly as we can, while
offering the best customer experience possible. And ensuring that as problems
are found that they're correctly addressed.

Anyways, I think it's an interesting approach to a problem that affects many
users, assuming the requisite due diligence is done and that the equipment
operates as advertised.

Disclaimer, I work in the mobile telecom industry in Canada, and my views are
my own, and do not reflect those of my employer.

------
dedalus
Sounds like QUIC
([https://en.wikipedia.org/wiki/QUIC](https://en.wikipedia.org/wiki/QUIC))
would be awesome for these networks

