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

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.

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.
After the page has loaded, clicking more links usually is quite acceptable ..
until it goes into idle again.

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".

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

==

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.

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.

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?

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".

Received on Thursday, 29 March 2012 16:16:13 UTC