Let's not use HTTP over TCP for mobile apps anymore

Agreed that the standards will get there at some point. And it'll be a joyous day for all. But I'll have to humbly disagree with you that TCP Fast Open or Multipath or HTTP/2 provide the answer for the mobile app use case today.

TFO will save you one round-trip for the handshake.. but that's about it.

Multipath is only available for Apple's own use the last I heard so it's not really a factor... but even if it does become available, it's still TCP.

And in both cases, TCP is still hampered by the usual problems outlined in the blogpost. No concept of a session, slow-start, exponential backoff, unrealistically long timeouts etc. etc.

I guess the meta point here is that TCP is designed for the general case and it's great for what it is meant for. But by narrowing the use-case to native mobile apps, one can constrain the problem domain and gain more freedom in what you can design.

Heh... let's start with acknowledging a pretty good burn right there.

And thanks for the vote of confidence. Much appreciated.

As for price, we're working with a whole bunch of customers right now who've been using various solutions for serving content from the cloud (aws, cloudfront, CDN's... what have you) and they find the price to be comparable to what they're already paying. In addition, they find as users find the app experience more pleasant, the engagement goes up.

Note that as an app starts using our system to do content delivery, our caching proxy means that your other backend bandwidth bills drop off. So overall, most customers find us very affordable for the value they get.

Thanks. I'll take this positive beginning at face value :-)

"Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...", or "It's (better than|different to) (HTTP/2.0|QUIC|SPDY) because..."

I'm sorry if the material on the site is not technical enough for your taste. We've just launched and consider the site and the blog a work in progress. (Follow us on twitter at @packetzoom and me personally at @IAmChetanAhuja for updates).

Having said that, our customers are not necessarily people following the network protocol worlds closely. The stuff that you find "bland" and "pretty" is actually very helpful for a large portion of our target audience.

Now of course, those who click on the "Learn" link and don't find enough in-depth info are welcome to, and do, contact us directly. Every single mail we get on info@ or support@ addresses is read by a human in our (rather small) team and yes, we respond. Just as I'm responding to more detailed technical questions here.

"You're selling a protocol layer, so you're not going to have any non-nerdy customers!"

No we're not selling "a protocol layer". We're selling a drop-dead simple way to speed up downloads. Some of our customers are more interested in details of the protocol than others. But the majority of them want their apps to be fast and couldn't care less about, or even want to know about QUIC/SPDY/HTTP2.0 or whatever. Their questions are more like -- How easy is it to integrate? (very). Do I have to rewrite my code? (No). What do I have to change on the server side? (nothing).

And those of our customers who do want to go in-depth into details of the technology, do. They just talk to us and we explain what we're doing to the extent it doesn't reveal trade secrets.

"a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer"

This seems to be the crux of your issues with what we're doing. The reasons are ultra clear to us. Apps are faster and users are happier. That the only thing that matters.

We've found that merging layers allows us to handle, say, out of order delivery or dropped packets more smartly and more naturally. For far too long, user experience has been held hostage to diktats from the ivory tower. It's about time we start thinking from the ground up to create technology suited to what the users needs and not because we want to maintain some platonic ideal of "layer separation".

But the general question about router congestion handling is a valid one. And the answer is No, we're not just flooding the network with a blast of packets. Apart from anything else, that strategy is full of fail for throughput anyway. Since a busy router will likely generously drop packets from the UDP queue before it loses stuff from the TCP queues.

So we rely on precise knowledge of network conditions at a fine grained level (the grain gets finer as we add more users to our network) to utilize the available bandwidth. We also use other techniques to predict queue congestion on the network path before it gets to the level of dropping packets. Note that (most) TCP implementations rely on packets loss to discover usable link capacity. We don't! One of the advantages of creating your own protocol is that you can use the state of the art research in congestion control strategies without being constrained by legacy concerns.

The upshot is, our protocol is actually fairer to competing traffic compared to TCP on the whole. Hope that alleviates your concerns.

Yeah I've used mosh and it comes under the general category of UDP based protocols (of which, there are many). The purpose of designing the PacketZoom protocol (and it's attendant infrastructure) is to design something particular for the mobile native apps use case. Including things like app session based sessions, moving around between networks without breaking the session, take a single round-trip to setup the session and zero round-trips thereafter to start file transfers etc.

And then, once the transfers are started, taking care of the packet drops with a more measured backoff and retransmit policies than are available with TCP. E.g., PacketZoom protocol packets don't have to arrive in order. The receiving side can send feedback back to the sender with an exact list of what packets went missing. The sender can then make decisions about backoff on not just the fact that a packet dropped, but how many and in which locations.

Lots of other details like this allow us to handily beat TCP in all varieties of networks all over the world in speed and user experience.