Re: 2.0 and Radio Impacts/battery efficiency

Salvatore Loreto <salvatore.loreto@ericsson.com> Fri, 13 April 2012 08:50 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70921F871E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Apr 2012 01:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.751
X-Spam-Level:
X-Spam-Status: No, score=-8.751 tagged_above=-999 required=5 tests=[AWL=1.847, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYh3vueiQDx6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Apr 2012 01:50:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 738C921F86F1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Apr 2012 01:50:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SIcBn-0003Y8-Nn for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Apr 2012 08:49:07 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <salvatore.loreto@ericsson.com>) id 1SIcBd-0003XF-8L for ietf-http-wg@listhub.w3.org; Fri, 13 Apr 2012 08:48:57 +0000
Received: from mailgw1.ericsson.se ([193.180.251.45]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <salvatore.loreto@ericsson.com>) id 1SIcBS-0001we-VQ for ietf-http-wg@w3.org; Fri, 13 Apr 2012 08:48:55 +0000
X-AuditID: c1b4fb2d-b7b76ae0000063d8-e5-4f87e8582647
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.67.25560.858E78F4; Fri, 13 Apr 2012 10:48:25 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012 10:48:23 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 06959230B; Fri, 13 Apr 2012 11:48:23 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0D09C5104C; Fri, 13 Apr 2012 11:48:24 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3C3F74FBE6; Fri, 13 Apr 2012 11:48:23 +0300 (EEST)
Message-ID: <4F87E856.1000604@ericsson.com>
Date: Fri, 13 Apr 2012 10:48:22 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Roberto Peon <grmocg@gmail.com>
CC: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <4F8697C2.5000702@ericsson.com> <CACuKZqGA9Tyv_zhO2HhyLNvqvzNCrTyZYy+b_Tt616F7eLbT1w@mail.gmail.com> <CAP+FsNcGfj_G1U9nWA5qj+tW8rWwMn0+HVhYA40XXQg_hWfTuA@mail.gmail.com>
In-Reply-To: <CAP+FsNcGfj_G1U9nWA5qj+tW8rWwMn0+HVhYA40XXQg_hWfTuA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040100020209070500010706"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Received-SPF: pass client-ip=193.180.251.45; envelope-from=salvatore.loreto@ericsson.com; helo=mailgw1.ericsson.se
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SIcBS-0001we-VQ 172b607a594587ad0c4e7662779aec2c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 2.0 and Radio Impacts/battery efficiency
Archived-At: <http://www.w3.org/mid/4F87E856.1000604@ericsson.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13436
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SIcBn-0003Y8-Nn@frink.w3.org>
Resent-Date: Fri, 13 Apr 2012 08:49:07 +0000

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