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

On Thu, Mar 29, 2012 at 9:15 AM, Tobias Oberstein
<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.
Do you see that on LTE? the last paragraph of page 32 in Binoy's thesis has some
promising numbers.


>
> 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 18:01:05 UTC