RE: Exposing network stack state for optimizations

Dom,

I think that makes sense. A simple exposure of the network state could be used by Javascript libraries (or Web workers) to schedule network usage per requirements of the app (given that it has some flexibility). We are involved in work in this area.

I would also like to direct you to the end of the article, which references the "AT&T ARO (Application Resource Optimizer)" (http://www.research.att.com/projects/ARO/index.html) which is now available for downloading via the AT&T Developer Program.

The ARO tool was developed by the AT&T Developer Program to enable app developers to optimize how their apps use the network, based upon a detailed mapping of app network use and overall efficiency. We featured it at our recent 2012 Developer Summit in Las Vegas, and received much positive feedback and developer interest. The tool has been used by some of our top-tier app developers to achieve dramatic reductions of network usage, with no difference in app performance or functionality.

Thanks,
Bryan Sullivan

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Friday, March 30, 2012 4:49 AM
To: public-device-apis@w3.org
Subject: Exposing network stack state for optimizations

Hi,

I was talking with someone from France Telecom about a potential hook
that Web apps could use to optimize both battery usage and network
performances, esp. on mobile.

As you may know, mobile devices use various states in their network
stack that have different impact on the battery usage and the network
performance: typically, the low state means lower battery usage, but
much higher latency (see [1] for a lot more on this), while the high
state consumes more battery but induces much smaller latency.

Would it make sense to expose that state somehow to make it possible for
Web developers to organize their network usage depending on their
priority and the state of the network stack? Has there already been work
in that space?

HTTP/2.0 (with SPDY included) might address some of this, but most
likely not all of it (e.g. non-HTTP based network usage).

Dom

1.
http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=Jzq2QAkHxoP

Received on Friday, 30 March 2012 18:54:53 UTC