10:22 am, 19 Jul 08
heavy protocols add up
I found this discussion of Android's dropping XMPP interesting. (Disclosure: I have no insider knowledge about any of this.) In particular, this remark about compression in the context of the notoriously fat XMPP protocol:
You see a similar phenomenon with HTTP on a heavy page. Like CNN.com: Firebug says it took 135 HTTP requests to load the page. Many of them are to a CDN and only have ~400 bytes of request headers but all the ones to cnn.com (including the ads, apparently!) include cookies pushing them up to nearly a kilobyte. The net result is that the latency of the page starts getting affected by the end-user's upstream bandwidth, which is usually terrible. (But now, having typed that out, I wonder: does it really matter? Even those heavier requests fit within a packet anyway...)
Bandwidth used means radio transmissions sent, and overhead means more work done by the processor, both of which take battery power and reduce battery life. Meanwhile, compression turned out to not be very helpful. Since it's negotiated during connection startup, it doesn't help with startup overhead. It does help somewhat with steady-state bandwidth, but at the expense of additional CPU cycles. The result is that enabling compression actually reduced battery life in our tests -- it took more power for the CPU to do compression than we saved on radio power.(I wonder though: perhaps they could've used a simpler form of compression? XML ought to be "easy" to compress. Maybe the spec doesn't allow it?)
You see a similar phenomenon with HTTP on a heavy page. Like CNN.com: Firebug says it took 135 HTTP requests to load the page. Many of them are to a CDN and only have ~400 bytes of request headers but all the ones to cnn.com (including the ads, apparently!) include cookies pushing them up to nearly a kilobyte. The net result is that the latency of the page starts getting affected by the end-user's upstream bandwidth, which is usually terrible. (But now, having typed that out, I wonder: does it really matter? Even those heavier requests fit within a packet anyway...)
I had not seen firebug before! That's a seriously useful little toy.
By the numbers you gave, I would guesstimate that the browser has to send some 90KB of request headers total. While the size of request headers going to cnn.com vs those going to the CDN doesn’t matter much, your ultimate point that this huge glop of boilerplate is going to cause latency is absolutely correct.
But then, HTTP is based on the REST style, whose primary concern is to avoid any coupling between clients and servers whatsoever – at the expense of efficiency, wherever necessary. Note well though that that very property is why generic intermediaries such as caching proxies are possible – allowing HTTP to scale far beyond protocols that, at face value, are more efficient.
But if we talk about it like it's power, than that's 100 fewer round trips. All power optimisation in mobile platforms is about getting the work done as fast as possible and then dropping immediately to the lowest power state you can manage. So if your radio has a useful low power mode, and you have an impossibly low latency of about 30ms, that means getting back to low radio power a third of a second sooner.
I don't follow the power argument ... are you suggesting it has to transmit even when there's no data to transmit? That seems really silly. OTOH, I can imagine (especially with error correcting codes) that sending one longer transmission is significantly more efficient than several shorter ones.
A server could easily produce a 1.1 response and the pipelined requests on the floor; no response would be received... Just timing out and repeating the request isn't really reasonable since the size of the response isn't known and it can't be canceled without tearing down the TCP connection...
Suggestions? I suppose a reasonable first step would be to have a little bot try various popular sites and see how sane they seem.
Packets and latency
Typically the dominating factor in latency is the number of round trips required. So providing the request fits into a single packet (and the response fits into a single packet), and both actually get sent as single packets, you're not going to improve the situation much by making them smaller still. However given that HTTP uses TCP, a major factor is the TCP setup overhead (two round trips) especially if you're not using keep-alive connections or otherwise using many connections. And asFor Android and similar I'm a little surprised they didn't decide to use something like the IRC protocol which is single line based with minimal overhead, and relatively easy to parse. Granted it suffers from having been designed 15+ years ago by college students (and this shows in many of the implementations), but it did do a good job of minimising overhead of any given message.
Ewen
http://en.wikipedia.org/wiki/WBXML