Subject: 2.0 and Radio Impacts/battery efficiency

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Apr 2012 10:52:18 +0200

Hi there,

here a good read about "Optimizing Downloads for Efficient Network Access"
http://developer.android.com/training/efficient-downloads/efficient-network-access.html

the major points are

1) reducing the number of connections is a MUST as each new network 
connection is extremely expensive
from a Radio/Battery prospective

It is also worth to add that the server-initiated closing of  idle 
connection is also something to avoid.
So if the client keeps the connection open longer, then the 
specification has to mandate servers to keep
the connection open for very long.

2) the ping frequency is also very important:
/"An app that pings the server every 20 seconds, just to acknowledge 
that the app is running and visible to the user, will keep the radio 
powered on indefinitely"
/

3) also Prefetching data need some consideration from the radio 
prospective as Prefetching data (on a wireless connection)
  may cost money but for sure has a cost from a battery prospective

cheers
Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Zhong Yu <[email-masked]>
Date: Thu, 12 Apr 2012 10:23:42 -0500

I don't get it. Cerntainly a new connection requires an extra round
trip which drains extra power, but only for the duration of the round
trip. Why is it "extremely expensive"?

The article says

    "Every time you create a new network connection, the radio
transitions to the full power state."

which I don't think implies that,

    "If you reuse a network connection, the radio does NOT necessarily
transition to the full power state."

To compress all network activities(including FIN-FIN) into a shorter
time span, the article event suggests that

    "so it's also good practice to close your connections when they
aren't in use"

On Thu, Apr 12, 2012 at 3:52 AM, Salvatore Loreto
<[email-masked]> wrote:
> So if the client keeps the connection open longer, then the specification
> has to mandate servers to keep
> "An app that pings the server every 20 seconds, just to acknowledge that the
> app is running and visible to the user, will keep the radio powered on
> indefinitely"
>
>
> 3) also Prefetching data need some consideration from the radio prospective
> as Prefetching data (on a wireless connection)

---

From: Roberto Peon <[email-masked]>
Date: Fri, 13 Apr 2012 00:27:21 -0700

The most obvious reason would be that the server sends a packet which
requires the radio to awaken (e.g. because the tcp stack emits a packet
back).
-=R

On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[email-masked]> wrote:

> prospective

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Apr 2012 10:48:22 +0200

Roberto is right!

the problem with multiple TCP connections is that the server can send 
packets on several connections.

Low power to full power will always be the case no matter who send data 
on (or closes) the connection, server or client.
On top of this, when the server send data on (or closes) the connection 
the system needs to page the device,
send out a signal on the common control channel in order to make the 
device re-establish its radio channel, these are in many systems quite 
loaded.
When the TCP close is initiated from the device the device does not need 
to be paged.

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

On 4/13/12 9:27 AM, Roberto Peon wrote:
> requires the radio to awaken (e.g. because the tcp stack emits a 
> packet back).
> -=R
>
> On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi there,
>     >
>     > www.sloreto.com <http://www.sloreto.com>
>
>

---

From: <[email-masked]>
Date: Fri, 13 Apr 2012 10:45:28 +0000

Hi,

It's not clear to me that using less _TCP_ connections automatically reduces battery power on 3G. For instance, the use of battery is roughly the same if a client opens a single TCP connection and pipelines (or multiplexes in SPDY style) multiple GETs over it vs. opens simultaneously a separate connection for each GET. The radio wakes up on the first TCP SYN and stays up a few seconds after the last byte in the last response has been obtained. A single connection may or may not make this time shorter.

How the connections are closed does potentially have an impact. If the connections are closed immediately after the responses are done, there isn't any significant difference between 1 vs. many connections. The radio is already up. However, if the connections are closed after some idle period, for instance by a server timeout, that makes the radio wake-up an additional time. If the separate connections are closed after _different_ timeouts (more than a couple of seconds difference), that can make the radio wake-up multiple times, which is bad. If servers really do use random timeouts, I agree that fewer connections are better. Is that the case?

If there are connections to multiple servers and servers send data in an asynchronous and uncoordinated manner is a problem as the radio wakes up quite often.  One solution is to use some kind of gateway/proxy to buffer and bundle the data together and use just a single connection to that gateway.

Markus

From: ext Salvatore Loreto [mailto:[email-masked]]
Sent: 13 April, 2012 11:48
To: Roberto Peon
Cc: Zhong Yu; HTTP Working Group
Subject: Re: 2.0 and Radio Impacts/battery efficiency

Roberto is right!

the problem with multiple TCP connections is that the server can send packets on several connections.

Low power to full power will always be the case no matter who send data on (or closes) the connection, server or client.
On top of this, when the server send data on (or closes) the connection the system needs to page the device,
send out a signal on the common control channel in order to make the device re-establish its radio channel, these are in many systems quite loaded.
When the TCP close is initiated from the device the device does not need to be paged.

/Sal

--

Salvatore Loreto, PhD

www.sloreto.com<http://www.sloreto.com>

On 4/13/12 9:27 AM, Roberto Peon wrote:
The most obvious reason would be that the server sends a packet which requires the radio to awaken (e.g. because the tcp stack emits a packet back).
-=R
On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[email-masked]<mailto:[email-masked]>> wrote:
I don't get it. Cerntainly a new connection requires an extra round
trip which drains extra power, but only for the duration of the round
trip. Why is it "extremely expensive"?

The article says

On Thu, Apr 12, 2012 at 3:52 AM, Salvatore Loreto
<[email-masked]<mailto:[email-masked]>> wrote:
> www.sloreto.com<http://www.sloreto.com>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 13 Apr 2012 13:59:48 +0200

On 4/13/12 12:45 PM, [email-masked] wrote:
>
> Hi,
>
> It’s not clear to me that using less _/TCP/_ connections automatically 
> reduces battery power on 3G. For instance, the use of battery is 
> roughly the same if a client opens a single TCP connection and 
> pipelines (or multiplexes in SPDY style) multiple GETs over it vs. 
> opens simultaneously a separate connection for each GET. The radio 
> wakes up on the first TCP SYN and stays up a few seconds after the 
> last byte in the last response has been obtained. A single connection 
> may or may not make this time shorter.
>
> How the connections are closed does potentially have an impact. If the 
> connections are closed immediately after the responses are done, there 
> isn’t any significant difference between 1 vs. many connections. The 
> radio is already up. However, if the connections are closed after some 
> idle period, for instance by a server timeout, that makes the radio 
> wake-up an additional time. If the separate connections are closed 
> after _/different/_ timeouts (more than a couple of seconds 
> difference), that can make the radio wake-up multiple times, which is 
> bad.
>
> If servers really do use random timeouts, I agree that fewer 
> connections are better. Is that the case?
>
yes, it is!
at least that is also my reading of the advices on the android developer 
website.

> If there are connections to multiple servers and servers send data in 
> an asynchronous and uncoordinated manner is a problem as the radio 
> wakes up quite often.  One solution is to use some kind of 
> gateway/proxy to buffer and bundle the data together and use just a 
> single connection to that gateway.
>

> Markus
>
> *From:*ext Salvatore Loreto [mailto:[email-masked]]
> *Sent:* 13 April, 2012 11:48
> *To:* Roberto Peon
> *Cc:* Zhong Yu; HTTP Working Group
> *Subject:* Re: 2.0 and Radio Impacts/battery efficiency
>
> Roberto is right!
>
> Low power to full power will always be the case no matter who send 
> data on (or closes) the connection, server or client.
> On top of this, when the server send data on (or closes) the 
> connection the system needs to page the device,
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> > Hi there,
> >

---

From: Roberto Peon <[email-masked]>
Date: Fri, 13 Apr 2012 11:50:22 -0700

Any timeout, if not explicitly synchronized across connections (dang
difficult) will , since the connection becomes idle/empty at different
times, will result in some random distribution of fins/backs/whathaveyou.
On Apr 13, 2012 3:45 AM, <[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> It’s not clear to me that using less _*TCP*_ connections automatically
> reduces battery power on 3G. For instance, the use of battery is roughly
> the same if a client opens a single TCP connection and pipelines (or
> multiplexes in SPDY style) multiple GETs over it vs. opens simultaneously a
> separate connection for each GET. The radio wakes up on the first TCP SYN
> and stays up a few seconds after the last byte in the last response has
> been obtained. A single connection may or may not make this time shorter.
> ****
>
> ** **
>
> isn’t any significant difference between 1 vs. many connections. The radio
> is already up. However, if the connections are closed after some idle
> period, for instance by a server timeout, that makes the radio wake-up an
> additional time. If the separate connections are closed after _*different*_
> timeouts (more than a couple of seconds difference), that can make the
> radio wake-up multiple times, which is bad. If servers really do use random
> timeouts, I agree that fewer connections are better. Is that the case?****
>
> ** **
>
> If there are connections to multiple servers and servers send data in an
> asynchronous and uncoordinated manner is a problem as the radio wakes up
> quite often.  One solution is to use some kind of gateway/proxy to buffer
> and bundle the data together and use just a single connection to that
> gateway. ****
>
> ** **
>
> Markus****
>
> ** **
>
> ** **
>
> *From:* ext Salvatore Loreto [mailto:[email-masked]]
> *Subject:* Re: 2.0 and Radio Impacts/battery efficiency****
>
> ** **
>
> Roberto is right!
>
> Low power to full power will always be the case no matter who send data on
> (or closes) the connection, server or client.
> ****
> -- ****
> Salvatore Loreto, PhD****
>
> www.sloreto.com****
>
>
>
> On 4/13/12 9:27 AM, Roberto Peon wrote: ****
>
> back). ****
> -=R****
> On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[email-masked]> wrote:***
> *
>
> aren't in use"****
> > www.sloreto.com****
> ** **
> ** **

---

From: Roberto Peon <[email-masked]>
Date: Fri, 13 Apr 2012 11:55:23 -0700

On the solution... that is what is being proposed w.r.t multiplexing plus
explicit proxies. Of course, this doesn't solve the problem completely,
since neither side is likely to know the radio state, and that is really
the bit that is needed for optimal behavior.

Anyway, multiplexing over one connection will have less trading fins.

-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 14 Apr 2012 09:56:22 -0700

I'm speculating here, but a proxy deployed by the mobile service provider
may have a reasonable estimate of the radio state.

I think Roberto is just being succinct here, but to further drive the point
of explicit proxies rather than implicit proxies here, an explicit proxy
will let the client multiplex (SPDY / HTTP2.0) to the proxy, and not just
to origin servers. This way, even if the origin server FINs a connection,
the proxy won't have to deliver a FIN to the client, since the
client<=>proxy connection hasn't closed. And even if it has, the proxy
could choose to do implicit closes (no FIN) rather than explicit closes.
Future traffic would either get a TCP RST, or if it's a SPDY-type proxy,
SPDY PINGs will allow detecting dead connections to the proxy.

On Fri, Apr 13, 2012 at 11:55 AM, Roberto Peon <[email-masked]> wrote:

>> additional time. If the separate connections are closed after _*different
>> *_ timeouts (more than a couple of seconds difference), that can make
>> the radio wake-up multiple times, which is bad. If servers really do use
>> random timeouts, I agree that fewer connections are better. Is that the
>> case?****
>>
>> ** **
>>
>> On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[email-masked]> wrote:**
>> **
>>

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 14 Apr 2012 21:16:39 +0200

Hi William,

> SPDY PINGs will allow detecting dead connections to the proxy.

I agree. I've been pushing hard to get explicit proxies working at an
operator because it only offers benefits :
  - no wasted round-trip in DNS requests
  - persistent connections => no more SYN/FIN
  - TCP uses optimal congestion window
  - pipelining always possible from the very first request

Willy

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 14 Apr 2012 22:07:29 +0200

On Apr 13, 2012, at 12:45, <[email-masked]> wrote:

> However, if the connections are closed after some idle period, for instance by a server timeout, that makes the radio wake-up an additional time. 

I haven't measured this, but looking at the docs leads to the following conjectures:
The Apache 2.0 KeepAliveTimeout default was 15 seconds.  With the 17 seconds the AT&T parameters take to power down the radio and the 2 s to power up again, this would lead to a total of 15+2+17 = 34 seconds to power down.
The Apache 2.2 KeepAliveTimeout default is 5 seconds.  With any latency, this appears to make sure the radio has just been put to low power only to go through a 1.5 s transition to full power again (unless the FIN can be handled on the FACH -- I don't know).

Summary: With the AT&T numbers cited here, you could do your mobile users a favor by setting KeepAliveTimeout to 4 or less seconds.

(Find more about the 3G states and their timing in http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf -- this has a much smaller T2 than the 15 seconds the Android docs cite.
One interesting number in http://research.nokia.com/files/tr/NRC-TR-2008-002.pdf was that a single keep-alive exchange on their 3G network costs 9200 mJ (as opposed to 280 mJ on WiFi), about 0.7 mAh on a 3.7 V battery.  You might have some 2000 of those keep-alives in your cellphone battery before it is gone.  Ouch.)

Grüße, Carsten

---

From: Roberto Peon <[email-masked]>
Date: Sat, 14 Apr 2012 14:11:45 -0700

First: There needs to be better integration between the transport, app, and
hardware/radio on this in order to vastly improve the situation.

Second: Setting keep-alive to such low values can also adversely impact
battery, depending on the pattern of connection use, as it will increase
(significantly) latency for getting the user what they want. Additionally
many chat clients and/or ajax sites will use "hanging" gets, which return
perhaps every 30s. Even using a bidirectional stream (e.g. WebSockets),
this problem persists.

Until there is a study looking at what many websites do on devices from
various carriers, any supposition about reducing or increasing timeouts and
the impact on battery is just hypothetical supposition.

One thing is clear, however: Regardless of the usage pattern, use of a
proxy will reduce the number of extraneous radio wake-ups.
-=R

On Sat, Apr 14, 2012 at 1:07 PM, Carsten Bormann <[email-masked]> wrote:

> > However, if the connections are closed after some idle period, for
> instance by a server timeout, that makes the radio wake-up an additional
> time.
>
> The Apache 2.0 KeepAliveTimeout default was 15 seconds.  With the 17
> seconds the AT&T parameters take to power down the radio and the 2 s to
> power up again, this would lead to a total of 15+2+17 = 34 seconds to power
> down.
> The Apache 2.2 KeepAliveTimeout default is 5 seconds.  With any latency,
> this appears to make sure the radio has just been put to low power only to
> go through a 1.5 s transition to full power again (unless the FIN can be
> handled on the FACH -- I don't know).
>
> Summary: With the AT&T numbers cited here, you could do your mobile users
> a favor by setting KeepAliveTimeout to 4 or less seconds.
>
> (Find more about the 3G states and their timing in
> http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf-- this has a much smaller T2 than the 15 seconds the Android docs cite.
> One interesting number in
> http://research.nokia.com/files/tr/NRC-TR-2008-002.pdf was that a single
> keep-alive exchange on their 3G network costs 9200 mJ (as opposed to 280 mJ
> on WiFi), about 0.7 mAh on a 3.7 V battery.  You might have some 2000 of
> those keep-alives in your cellphone battery before it is gone.  Ouch.)
>
> Grüße, Carsten
>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 14 Apr 2012 16:58:39 -0700

On Sat, Apr 14, 2012 at 2:11 PM, Roberto Peon <[email-masked]> wrote:

> First: There needs to be better integration between the transport, app,
> and hardware/radio on this in order to vastly improve the situation.
>

Just to be clear, I believe Apache's KeepAliveTimeout refers to the idle
time at the server after a HTTP transaction completes before Apache closes
the socket. So hanging GETs should be fine since those HTTP transactions
are active.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Apr 2012 00:45:31 -0700

That is only true if the browser is reusing the same connection for the
next request. If, as many do when doing AJAX, the app uses multiple
overlapping GETs, it will use multiple connections and will be almost
guaranteed to go idle at different times. This is made worse if the app
makes other requests to the same domain (which must be done over separate
connections...)

Anyway, I think that there are so many things interplaying here that the
only way to figure things out is to measure and study. It is certainly not
something that has high determinism...

-=R
On Apr 14, 2012 4:58 PM, "William Chan (陈智昌)" <[email-masked]> wrote:

>>> Summary: With the AT&T numbers cited here, you could do your mobile
>>> users a favor by setting KeepAliveTimeout to 4 or less seconds.
>>>
>>> http://research.nokia.com/files/tr/NRC-TR-2008-002.pdf was that a
>>> single keep-alive exchange on their 3G network costs 9200 mJ (as opposed to
>>> 280 mJ on WiFi), about 0.7 mAh on a 3.7 V battery.  You might have some
>>> 2000 of those keep-alives in your cellphone battery before it is gone.
>>>  Ouch.)
>>>
>>> Grüße, Carsten
>>>
>>>
>>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 15 Apr 2012 05:28:58 -0700

Sorry, I may have misunderstood your previous statement. At my first read,
I thought it implied that the 30s idle time would mean connections with
hanging GETs that take longer than 30s would get closed while the GET is
hanging. Just wanted to clarify that that's not the case s'all.

On Sun, Apr 15, 2012 at 12:45 AM, Roberto Peon <[email-masked]> wrote:

>>>> The Apache 2.2 KeepAliveTimeout default is 5 seconds.  With any
>>>> latency, this appears to make sure the radio has just been put to low power
>>>> only to go through a 1.5 s transition to full power again (unless the FIN
>>>> can be handled on the FACH -- I don't know).
>>>>

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Apr 2012 11:41:27 -0700

> hanging. Just wanted to clarify that that's not the case s'all.

No, you were correct in your first interpretation: I certainly implied that
the hanging get for 30s may be interpreted as idle.
I'm just pointing out here that the fact that apache is smart enough to
know that a non-responded to request isn't idle just doesn't mean it won't
still happen.
-=R