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

Here is an interesting post about mobile connection behaviour and radio
link effects
http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/


On Thu, Mar 29, 2012 at 11:27 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Yuchung Cheng" <ycheng@google.com>
> To: "Tobias Oberstein" <tobias.oberstein@tavendo.de>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 30/03/2012 7:00:12 a.m.
> Subject: 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.
>>>
>>
>>   not our layer.  you need to talk to the phone network vendors about
> that.  Just like the HTTP WG can't do anything about the quality of your
> ADSL line.
>
>
>
>>
>>>
>>> ==
>>>
>>> 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?
>>>
>>
>>   probably not, since these things are done this way for a reason, e.g.
> provisioning, arbitration of resource usage etc.
>  I think if a handset allowed this sort of behaviour it might find network
> operators reluctant to allow it on their network.
>
>
>>>
>>> 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".
>>>
>>
>>   it's maybe not just an issue of power drain in the client, but network
> capacity.
>  Provisioning in phone networks comes down to statistics, erlangs etc.  If
> every phone forced the network to keep it hot, then the network capacity to
> handle lots of phones may be diminished.
>
>
>
>>
>>
>
>