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


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

  
>

Received on Thursday, 29 March 2012 18:58:01 UTC