Re: 2.0 and Radio Impacts/battery efficiency

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 <grmocg@gmail.com> wrote:

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