RE: Network Information API

Hi Yoav
(cc Bryan and list)

If there is only mostly little data to be sent I don't think congestion will be a problem (the short queue will be handled quickly). Also, no, using radio state to manage when to send will indeed not be good for  user experience anyway, since it basically means that any "interactive" request response will be delayed until next radio up event (which is why it makes mostly makes sense for longer term polling, keepalive kind of activites. "radio state", if introduced in any form, is only for power efficiency (which is indeed a BIG problem in mobile devices) and not to improve UX.

Regarding bandwidth, etc. There are a lot of parameters that can be measured (in probably are already measured in the device platform), but I think the question is what useful info do they bring, and to whom? A big web property can spend a lot of time fine-tuning things and probably can use a lot of different info. For a smaller developer with less resources, doing some rough content adaption based on rough bandwidth is probably enough.

Before diving deeper into which parameters to expose I think we should outline some reasonably realistic scenarios to understand which problems we are trying to solve.

BTW, PKK had an interesting series on network information some time ago [1]

Best Regards
Niklas

[1] http://www.quirksmode.org/blog/archives/2012/10/measuring_conne.html

From: Yoav Weiss [mailto:yoav@yoav.ws]
Sent: Wednesday, December 12, 2012 10:40 AM
To: Niklas Widell
Subject: Re: Network Information API

Hi Bryan and Niklas,

A "radio is up" event might create a situation where multiple Web apps start sending or requesting data at the time, contending on the network resources with each other and with the Web app that woke up the radio (and probably should have priority). IMO, such an event may require scheduling and prioritization in order to avoid an impact on the user experience in terms of speed.

Going back to the `bandwidth` property - Wouldn't it be better to replace that (inherently inaccurate) property with a set of other properties such as: `maxRadioNetworkBandwidth`, `avgRadioNetworkBandwidth`, `AvgRadioNetworkRTT` and `receptionPercentage`?

Best regards,
Yoav

On Wed, Dec 12, 2012 at 8:48 AM, Niklas Widell <niklas.widell@ericsson.com<mailto:niklas.widell@ericsson.com>> wrote:
Hi Bryan
Yes, but there would be more benefit if the accesses are synched in some way. Maybe the idea is to have a "radio is up, time to send"  event that can synch queued up requests. Another question is if the usefulness of radio awareness outside e.g. keep-alive and data polling?

Best regards
Niklas

From: SULLIVAN, BRYAN L [mailto:bs3131@att.com<mailto:bs3131@att.com>]
Sent: Friday, December 07, 2012 8:43 PM
To: Niklas Widell; Yoav Weiss; Brian Leroux
Cc: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: RE: Network Information API


From: Niklas Widell [mailto:niklas.widell@ericsson.com]
Sent: Friday, December 07, 2012 2:12 AM
To: SULLIVAN, BRYAN L; Yoav Weiss; Brian Leroux
Cc: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: Re: Network Information API

There are measurable gains to be made given radio status info, but wouldn't this preferably be done in the browser rather than application? After all, it is the aggregation of all traffic from all web applications that must be well behaved for this scheme to work, and the browser is the aggregation point.

Note, I'm not arguing that radio adaption is a bad thing, just that it is a complex implementation detail that requires wide adoption by all web pages to be useful.


I don't assume that the browser has to be the aggregation point, since "aggregation" means that the browser would be making decisions on behalf of apps (re request timing at least), and that is a complex undertaking that I doubt browser vendors would want to be responsible for. I would rather leave this at the app layer with support from libraries, that allow developers to take advantage of rapidly evolving techniques implemented in javascript.

I also don't think that to be useful, this requires "wide adoption by all web pages". As I mention below, we have seen major improvements on an app-by-app basis through such techniques. These improvements have been very useful for users of those apps. Wider adoption will follow once developers see the advantage of context-aware network usage, and have easy ways to leverage it (e.g. freely available javascript libraries that use the new APIs to manage app-specific network request queues).

Regards
Niklas

On 2012-12-06 19:47, "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:bs3131@att.com>> wrote:

Another, unrelated property that can be of great help to Web developers is the `radioState` property. What I mean by that is exposing the state of the radio (full power, low power or standby as defined http://developer.android.com/training/efficient-downloads/efficient-network-access.html) to Web developers, giving them the opportunity to pull extra data from the servers only if the radio is already in full-power, thus saving battery life.

Exposing the radio state would be very valuable, certainly provide much more actionable information than navigator.online or connection.bandwidth. Basing network request decisions based upon radio state could go a long way toward improving resource efficiency, at least for requests that can be delayed until an optimal time. We've proven this by achieving major reductions in device power usage for some of our lead app developers, through their use of our free ARO (at&t Application Resource Optimizer<http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312>) tool.

Thanks,
Bryan Sullivan