W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

RE: 2.0 and Radio Impacts/battery efficiency

From: <Markus.Isomaki@nokia.com>
Date: Fri, 13 Apr 2012 10:45:28 +0000
To: <salvatore.loreto@ericsson.com>, <grmocg@gmail.com>
CC: <zhong.j.yu@gmail.com>, <ietf-http-wg@w3.org>
Message-ID: <E44893DD4E290745BB608EB23FDDB7621CEF37@008-AM1MPN1-041.mgdnok.nokia.com>
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:salvatore.loreto@ericsson.com]
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 <zhong.j.yu@gmail.com<mailto:zhong.j.yu@gmail.com>> 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

   "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
<salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
> 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<http://www.sloreto.com>
Received on Friday, 13 April 2012 10:46:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:52:00 GMT