RE: 2.0 and Radio Impacts/battery efficiency

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
On Apr 13, 2012 3:45 AM, <Markus.Isomaki@nokia.com> 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?****
>
> ** **
>
> 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****
>
>
>
> 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> 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> 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****
>
> ** **
>
> ** **
>