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

From: Tobias Oberstein <[email-masked]>
Date: Thu, 29 Mar 2012 09:15:41 -0700

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

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 29 Mar 2012 11:00:12 -0700

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

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 29 Mar 2012 11:15:43 -0700

> > 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.
> >
> Do you see that on LTE? the last paragraph of page 32 in Binoy's thesis has
> some promising numbers.

I saw the numbers and they are indeed quite promising! On the other hand,
the world-wide rollout of LTE might take years .. so HSPA is here to stay for
at least some time.

I don't have access to LTE network or device currently .. too bad.

FWIW: code I used is here
https://github.com/oberstet/scratchbox/blob/master/python/heartbeat/client.py

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 29 Mar 2012 18:57:33 +0000

------ Original Message ------
From: "Yuchung Cheng" <[email-masked]>
To: "Tobias Oberstein" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 30/03/2012 7:00:12 a.m.
Subject: Re: fyi: An Experimental Study of Web Transport Protocols in 
Cellular Networks
>>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.
  
>>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.
>>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.

---

From: Salam J <[email-masked]>
Date: Thu, 29 Mar 2012 23:32:05 +0430

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 <[email-masked]> wrote:

>>> the web,
> that.  Just like the HTTP WG can't do anything about the quality of your
> ADSL line.
>
>
>
>>
>>>
>>> ==
>>>
>  I think if a handset allowed this sort of behaviour it might find network
> operators reluctant to allow it on their network.
>
>
>>>
>  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.
>
>
>
>>
>>
>
>

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 19:39:26 +0000

Hi Tobias,

Tobias Oberstein [mailto:[email-masked]] wrote:
>
>The study speaks about state transitions of the HSPA radio channel, which is
>quite interesting!
>

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.

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

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

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

Could be implemented, yes. Very good idea.

Markus

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 19:47:18 +0000

Hi,

>Do you see that on LTE? the last paragraph of page 32 in Binoy's thesis has

I'm told LTE has somewhat similar behavior. It will also try to save power whenever possible, and getting back to active from power save always takes a bit of time. But it should be better than what we have today, depending on the trade-off made in setting the parameters, of course.

Actually, in terms of RTT and bitrate LTE is quite a lot like Wi-Fi (11g at least) that we have today, so the good news is that if it is available we don't have to worry about the special case of mobile so much anymore. However, in most places HSPA and even GPRS will still prevail for many years.

Markus

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 29 Mar 2012 15:01:59 -0700

Hi Markus,

thank you for your detailed explanations! Very welcome.

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

Should you ever release such "mobile nets for dummies": I hereby order one! ;)

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

Given that the "snappy button" won't arrive in shops soon, I'd be
very interested in how do to that "keep radio hot" pinging best.

Would you shed some light onto / share info which of the following
might influence the state transitions between IDLE, FACH, DCH?

* combined up/down avg rate bits/s over say interval of couple of secs

* does up vs. down factor in separetely (i.e. could I be done by only
doing _down_stream pinging - probably never ponging back? since
down is usually less scarce than up)

* given same rate bits/s, does it make a diff. whether many small
or a few big IP packets travel the line?

* only traffic on the leg between mobile device<=>base station is relevant,
or are i.e. PDP contexts also teared down on intervals of inactivity

I need your "dummies" book! Ideally, it would contain pseudo code for
an adaptive, dynamic keep-radio-hot heartbeat algorithm;)

Tobias

---

From: Ted Hardie <[email-masked]>
Date: Fri, 30 Mar 2012 09:19:38 +0200

> Done. Let the user trade off "snappy" vs "power drain".

While the battery life issue is certainly a very important one, it's
important to recognize that the other resource being managed here is
the carrier's radio resources.  If you keep the device on in an active
state to avoid the latency associated with dormant states, you are
consuming resources that have a real impact in crowded networks.    I
apologize for giving you a reference in flash slides, but you may want
to check out:

http://www.slideshare.net/zahidtg/gsma-fast-dormancy-best-practices

for a bit more background.

regards,

Ted Hardie

---

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Mar 2012 10:03:03 +0200

On 30 March 2012 09:19, Ted Hardie <[email-masked]> wrote:
> consuming resources that have a real impact in crowded networks.

Since I pay so much for this, it's almost the case that I'm somewhat
more comfortable with this idea, but...

This is a case where what an endpoint does can have a real impact on
the rest of the world.  Self-interested parties could get much greater
individual performance for things like file transfers by ignoring
things like TCP congestion control, but ultimately that leads to a
mutually destructive arms race.

Thanks for the reminder Ted.

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 30 Mar 2012 01:17:19 -0700

> > When "keep snappy" = ON, the device will just stay in state DCH _all 
> > the
> time_.

Thanks for the slides .. interesting. Carrier's network resources .. sure.

2 comments

The mere act of transitioning in and out of DCH consumes network resources too. From the slides:

"That lead time or RAB (Radio Access Bearer) activation delay time sued to transition from Idel to Cell_DCH is not only inconvenient from the user experience point of view, it also involves a long sequence of signalling messages (needed in order to activate the radio
bearer) that puts considerable load on the RNC's (Radio Network Controllers)"

Then the FACH state seems to be designed for low volume, continuous data transfer, but unfortunately, it does not seem to be exceptionally low-latency. When I get this right, FACH is happening on some kind of shared radio channel, different from DCH which uses exclusive channels. Maybe the radio channel sharing in FACH is a reason for the increased latencies?

It's a pity that there isn't a low-bandwidth, low-latency, low-power, always connected mode.

---

From: <[email-masked]>
Date: Fri, 30 Mar 2012 08:32:00 +0000

Hi,

(Sorry about hijacking HTTP-list for radio discussion, but I hope this is somehow useful background for the HTTP/2.0 work.)

Ted Hardie wrote:
>
>While the battery life issue is certainly a very important one, it's important to
>recognize that the other resource being managed here is the carrier's radio
>resources.  If you keep the device on in an active state to avoid the latency
>associated with dormant states, you are

That's true too. I suppose it depends on the technology how much is consumed by just keeping a channel up without using it much. There is more state for sure, but the impact to other users' throughput should not be that radical. (It's a bit like having a little used RSVP reservation on a router or a TCP connection on a proxy. They consume resources but don't as such congest the data/forwarding path.) If you really wanted to cause havoc, the best way would be actually to do as many active-idle transitions as possible. That does not congest the data path either, but often the bottleneck is in those nodes who process the radio level signaling. There are cases of networs where very little goes through because of this. I think the document referenced in Ted's previous mail discusses that as well.

Markus