Mobile TCP optimization – lessons learned in production

Performance enhancing proxies have existed (and have been deployed) for a long time. You will for example not find many, if any, satellite data providers without a PEP somewhere in the mix. Nor will you find many mobile operators who don't have a transparent HTTP proxy, even if not a generic TCP one.

The implications of PEPs are discussed at length in RFC3135, and not really discouraged unless they interfere with the end to end principle on the application layer.

For your specific example, using the ACK stream as a liveness signal isn't in general very useful. For example the kernel on the phone will happily continue ACKing for a long time even if the application that's consuming the data becomes wedged somehow and can't process it.

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.

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.

Many carriers already MITM port 80/tcp (blindly sending SYN ACKs). Symptom: try connecting to a random domain without a webserver (like http://cse.ucdavis.edu/ ) and it will seem to have a website but just hang.