RE: fyi: An Experimental Study of Web Transport Protocols in Cellular Networks

Hi Tobias,

Tobias Oberstein [mailto:tobias.oberstein@tavendo.de] wrote:
>
>The study speaks about state transitions of the HSPA radio channel, which is
>quite interesting!
>
>A daily annoyance for me is the _initial_ delay it takes when surfing the web,
>because the radio channel has been apparently put into some idle state.
>
>It takes anything from 1-5s to get into an active state again.
>

This is a major factor especially in HSPA, which is otherwise quite fast. The reason for the radio to go to idle state is to save power. By default the radio layer has no knowledge of the app layer let alone what the user is doing next, so usually it falls to idle after some fixed timeout of no packets. Nowadays you may find a bit smarter implementations, but traditioanally the timers have been totally based on radio network config. Short timers are preferred to save power across keep-alive type of traffic patterns.

>When I am surfing i.e., have found a page, read for some 10-120s, the radio
>will most often already be on idle. Clicking any link then means 1-5s delay.

Yes, the typical timeouts are usually between 5 and 30 seconds. The wake-up time (reserving a radio channel) typically takes 1-2 seconds. In newer endpoints and networks it can be <1 second, but if the network is congested or there is retransmission, it can take longer. 

>
>As I currently understand this, HTTP2, whether that's SPDY, SPDY-over-WS,
>whatever .. won't help me at all. Those might improve latencies when radio is
>already fully active (HSPA DCH state), but won't do anything about "first click
>latency".
>

I'm afraind so. A clever cross-layer implementation might help, though. 

>However, if HTTP2 is about user experience, optimizing the mobile
>experience, and here "first click latency" is IMHO quite important.
>

In this particular case yes, but it is hard for HTTP/2.0 to take into account the peculiarities of each link layer. Perhaps we could do some kind of BCP or "mobile networks for dummies" kind of guidance to implementers, though.

>==
>
>I now did a simple experiment: wrote a little WebSocket client that issues WS
>Ping requests every 200ms with a payload of 50 octets.
>
>Doing that, which effectively means approx. 4kb/s combined rate, gives me
>snappy behavior at any time! This is great. It improves my user experience ..
>
>Doing much less traffic will not work. I.e. 4 octets Ping every 1s will NOT work.
>The radio will go to some degraded mode, RTTs will increase from snappy 50-
>80ms to around 400-600ms, or even 1500-2000ms. I can see the radio state
>switching when watching the sequence of Ping RTTs.
>

Yes, I believe in this case the radio falls not into idle but to a "midway" state where power consumption is smaller but bitrate is also much smaller.

>Hence, the state transitions seem to be not simply based on "traffic == 0 or !=
>0", but on an average rate b/s. If traffic rate falls below, it'll transition into
>FACH or IDLE.
>

Indeed, it can fall into FACH if there are only small packets.

>Of course, this "rapid heatbeat" to achive low "first click latency" is somewhat
>ridiculous: it is wasting resources (I don't care about data volume .. 4kb/s is
>insignificant given the volume pack I am on).
>
>But the study seems to suggest that the radio state transition timeouts are
>defined by the carrier network, right? So there is no chance of having the
>mobile device, let alone an app, control state transitions?
>

Traditionally so. Fortunately, by now, there is also a mechanism called "fast dormancy", under which the mobile device can have some say in this. Unfortunately for you, this is only used to shorten the timeout, not prolong it. If for instance, say a websocket connection, sends keep-alives every few minutes but there's no other traffic, the best strategy for the mobile device is to tear down the radio channel as quickly as possible to reduce power consumption. On the other hand if the user had browser on, the default timers would be used.

>The optimal user experience would IMHO be: a "keep snappy" button in
>status bar drop down on mobile .. can turn on/off.
>
>When "keep snappy" = ON, the device will just stay in state DCH _all the
>time_.
>Done. Let the user trade off "snappy" vs "power drain".

Could be implemented, yes. Very good idea.

Markus

Received on Thursday, 29 March 2012 19:40:01 UTC