Re: Network Information API

I agree that you cannot conclude bandwidth from network type (I'm not sure
I'd call that lying though) without considering reception, packet loss and
RTT, and even then your result will probably be inaccurate.
The question is, do we want to create such an abstraction (and have each
browser implement it differently) or expose the underlying properties to
the Web developer.
IMO, if we do want to create such an abstraction, naming it `bandwidth` is
confusing.

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.

Yoav



On Thu, Dec 6, 2012 at 5:12 PM, Brian Leroux <brianl@adobe.com> wrote:

> Network type can lie. Very often here in San Francisco my phone reports 3G
> when indeed my bandwidth is closer to Edge. The abstraction you seek could
> be built on top of bandwidth property however.
>
> From: Yoav Weiss <yoav@yoav.ws>
> Date: Thu, 6 Dec 2012 00:42:38 -0800
> To: "public-device-apis@w3.org" <public-device-apis@w3.org>
> Subject: Network Information API
>
> Hi,
>
> I have a few comments on the current draft of Network Information API.
> The current draft exposes a couple of properties: `bandwidth` and
> `metered`, both of which are  described in the specification as hard to
> implement.
>
> I have looked into the current implementation of `bandwidth` in Firefox
> for Android, and summed up the parts I found relevant at:
> https://gist.github.com/4206150
> Basically, the application gets the network type from the OS, and
> translates it to an arbitrary bandwidth value which is the maximum such a
> network can achieve.
>
> I believe that the name `bandwidth` for such a property is misleading, and
> will lead to confusion among Web developers. Maybe a name along the lines
> of `maxRadioNetworkBandwidth` would make more sense.
>
> As far as I understand it, the actual bandwidth between the browser and
> the Web server is not known to the OS layer. It is something that if we
> want to (unreliably) measure, it should be done in the browser's socket
> layer (while taking slow-start and multiple TCP connections into
> consideration), and will probably be highly variable depending on the radio
> network *and* the destination host. So by definition, a `bandwidth`
> property in unreliable and therefore, of little value.
>
> As a Web developer, I'd much rather know the `networkType` and draw my
> conclusions from there. To my understanding, the `networkType` property was
> removed from the specification because of privacy concerns. Could someone
> elaborate on these concerns?
>
> Since `networkType` is forbidden, wouldn't it be wise to replace it with a
> few properties such as: `maxRadioNetworkBandwidth` (which we have under the
> name `bandwidth`), `avgRadioNetworkBandwidth`, `AvgRadioNetworkRTT` and
> possibly `receptionPrecentage`  and `radioState` (I'm not sure that is
> information that the OS exposes)
>
> These properties will give developers more information regarding the
> actual radio conditions they are facing, rather than an inherently
> inaccurate `bandwidth` property.
>
> Thanks for reading so far,
> Yoav Weiss
>
>
>
>
>