Let's not use HTTP over TCP for mobile apps anymore
packetzoom.com
Let's not use HTTP over TCP for mobile apps anymore
1–10 of 14 posts
Re: Let's not use HTTP over TCP for mobile apps anymore
#2Totally lazy commenting by me here, but isn't there a mobile shell that was designed to work well over high latency, iffy connections.
This? https://mosh.mit.edu
Maybe we’re talking about the same problems.
Re: Let's not use HTTP over TCP for mobile apps anymore
#3Totally lazy commenting by me here, but isn't there a mobile shell that was designed to work well over high latency, iffy connections. This? https://mosh.mit.edu Maybe we’re talking about the same problems.
Hey it's not lazy if you actually found the link ;-)
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.
Re: Let's not use HTTP over TCP for mobile apps anymore
#4IETF is working on better stuff – and it will be standard.
RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS.
RFC 6824 Multipath TCP, already deployed on iOS.
And the most important upgrade: HTTP/2.
Sorry, I'm not using commercial proxies with proprietary protocols. I believe that anything as low level as transport layer shouldn't have a "pricing" link.
P.S. QUIC is an interesting experiment, maybe it will become a standard like SPDY became HTTP/2. But UDP can't always be used... My university's WiFi just blocks all UDP completely, for example.
Re: Let's not use HTTP over TCP for mobile apps anymore
#5IETF is working on better stuff – and it will be standard . RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS. RFC 6824 Multipath TCP, already deployed on iOS. And the most important upgrade: HTTP/2. Sorry, I'm not using commercial proxies with proprietary protocols. I believe that anything as low level as transport layer shouldn't have a "pricing" link. P.S. QUIC is an interesting experiment, maybe i…
Just to get the pricing thing out of the way, the pricing is not to license a protocol but to actually distribute app content -- from our servers worldwide. And our current customers are finding that it's pretty comparable to what they maybe already paying for such a service to other providers.
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.
Re: Let's not use HTTP over TCP for mobile apps anymore
#6Totally lazy commenting by me here, but isn't there a mobile shell that was designed to work well over high latency, iffy connections. This? https://mosh.mit.edu Maybe we’re talking about the same problems.
Mosh doesn't support IPv6. Writing software these days that only works on IPv4 is shameful.
Re: Let's not use HTTP over TCP for mobile apps anymore
#7I have seen a demo and there was a huge speed increase (the app loaded content much quicker) with their technology. Is it the perfect solution? I have no idea, I am not a network person. But if you are looking to speed up your app I would check it out.
My big question is price, do I need to be a big company to afford this? It seems like it could get expensive.
Yes there are other people (as floatboth and jhugg pointed out) working to solve the same problem, but that is awesome! I want some competition, companies pushing the limits, standards organizations making it work everywhere and academics researching it. Who knows maybe one day my phone will load content so fast that I believe ATT really does have 4g in my area
Re: Let's not use HTTP over TCP for mobile apps anymore
#8I have seen a demo and there was a huge speed increase (the app loaded content much quicker) with their technology. Is it the perfect solution? I have no idea, I am not a network person. But if you are looking to speed up your app I would check it out. My big question is price, do I need to be a big company to afford this? It seems like it could get expensive. Yes there are other people (as floatboth and jhugg pointe…
"Who knows maybe one day my phone will load content so fast that I believe ATT really does have 4g in my area"
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.
Re: Let's not use HTTP over TCP for mobile apps anymore
#9Does it do anything to solve router congestion when it does happen and how can it tell the difference? Cell towers are often bandwidth limited on their uplinks; is this protocol going to out-compete TCP for bandwidth and slow everyone else down?
Re: Let's not use HTTP over TCP for mobile apps anymore
#10Does it do anything to solve router congestion when it does happen and how can it tell the difference? Cell towers are often bandwidth limited on their uplinks; is this protocol going to out-compete TCP for bandwidth and slow everyone else down?
Currently we're focusing on the download portion of the transfer so I'd refrain from commenting on the uplink protocol for the time being.
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.