W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: State of the Network Information API specification

From: Cheng, Diana, Vodafone Group <Diana.Cheng@vodafone.com>
Date: Sun, 27 Jan 2013 18:34:25 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <9880D73B369AF843AA5E75D663A1A983131083A9@VOEXM29W.internal.vodafone.com>
Hi Mounir,

Thanks a lot for this summary. Please see my comments inline.


On 24/01/2013 21:57, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>
>It is up to the user agent to decide how the bandwidth is computed. It
>might indeed be hard to have a precise bandwidth for each domain the
>client is accessing but this is actually not the intent of the
>specification. The user agent should provide something that has enough
>precision to be usable (not 1 Mb/s precision for example) but it doesn't
>need to be very precise (like 1 kb/s precision).

Yes, the user agent will have freedom in determining how the bandwidth is
computed, but I do believe that wrong information is worse than no
information, because it will lead to the wrong decisions for developers.

>
>The spirit of the specification is that the vendors will come up with
>more or less sophisticated implementations.

Unless the user agent is computing the bandwidth as function of all the
possible destinations (origin, server where JS and CSS are hosted, CDNs
for images, etc.) and taking into account that during some of the
bandwidth measurements it might be encountering TCP connections in their
slow start phase [1], then it will most likely return a value that it's
just not very useful but most likely misleading. When you say
"sophisticated implementations" you are right, but I think at this point
measuring bandwidth is just really really hard and cannot be done well
enough for developers to make good decisions in their applications.
Moreover, in order to implement something reliable, the number of
measurements needed is just too big (and would need to happen too often)
and will completely defeat the purpose
of saving bytes to the user.


>For example, the experimental implementation in Firefox for Android is
>simplistic and has space for improvements. We currently have hard-coded
>values that are returned depending on the connection type. There are
>different ways to improve that: we can randomize the returned value, we
>can have steps (there is no need to differentiate 22kb/s and 28kb/s for
>example). A more complex way to improve that would be to estimate the
>bandwidth while Firefox is running (on a given Mozilla server for
>example) and use it as a value for all websites. Actually, that kind of
>information could be used by a mobile browser for various reasons.
>None of those improvements would fully follow the specifications because
>the estimation wouldn't be compared to the current document but to an
>arbitrary server. However, those improvements are not complex and would
>make the implementation closer to the ideal one without having to change
>the specification nor the web pages.

Do you mean that the implementation should at first always rely on a
"reference server" and from there make improvements according to the
origin of the page and other domains it is trying to access? Who provides
these "reference servers"? (and bears the costs and scales if too many
user agents are trying to measure against them?)

>
>In my opinion, the only real alternative to the current bandwidth
>specification is to simply remove it from the specification because it
>is proven unrealistic and not implementable. Although that has often
>been said, no actual implementer came here to give its feedback.
>Therefore, I think the attribute should stay as-is until an implementer
>formally express its incapacity to implement it - taking in
>consideration what has been said above.

Actually, my concerns were shared by people working for other
implementors, so it would be helpful if they could voice what the think of
implementing this attribute. As for me, I'm starting to think the best
path would be, as Bryan and Tobie hinted, for the developer to simply
state whether a network request can be "queued for later". That way the
user agent and OS can batch requests and not wake up the radio from an
Idle state to send data immediately when it is not necessary. This is good
in order to avoid excessive signalling traffic and to save the user's
battery.

>
>As bandwidth, the metered attribute has been said to be not
>implementable. Currently, the Firefox for Android implementation simply
>mark mobile data connections as metered and others as not metered. This
>is indeed a poor implementation. However, since this specification has
>been written, Android came with an API to get that information [1], such
>as Windows 8 [2]. This make this attribute easily implementable on those
>platforms and is a proof that it is actually implementable.

That is great to see. However, I wonder if, as you say, this underlaying
native implementations take into account that a connection with a cap of
100GB should not be marked as metered. Or in general I wonder how they are
actually marking a connection as metered or notŠI'll do my homework and
look into this. 

Another problem is what happens if another mobile is sharing its
connectivity with me via Wifi hotspot. Then, I guess the implementation
will mark my connection as non-metered because it sees it's a Wifi and
will download high-res images, etc. This is not a desired outcome. I know
there is a way to manually indicate this to the Android 4.1 OS but I don't
think most users do this.

>
>The other idea was to make metered a tri-state: { true, false, unknown
>}. I think that could be interesting but I see two major culprits
>because of the fact that such a tri-state would require 'true' or
>'false' to be always exact and 'unknown' being the fallback value
>(otherwise, unknown would be useless):
>- you can't rely on implementations to have something not perfect and
>improve over time because strictly following the specification, most of
>them would have to return 'unknown' for the moment;
>- using an API like the one in Android that only returns true/false
>would be a violation from the specification because it is certain that
>Android doesn't know for sure and fallback to a value or an heuristic.
>I also think that having an 'unknown' value wouldn't help web developers
>because they will not be able to know what to do if the returned value
>is 'unknown'.

If the user agent can provide reasonably accurate values, then I think a
true/false approach is the right thing. If it cannot, as I said, wrong
information is worse than no information, so 'unknown' does make sense.

I think the iterations that this specification has gone through prove
that there is no easy way about this, and I think you've done a great job
documenting the current approach and the concerns people have atm, and
yes, having the bandwidth value and the metered attribute would be way
more useful than the connection type (as was drafted in the
previous version of the spec), but unfortunately I still find this
unimplementable right now.

Regards,
Diana.

[1] 
http://mobile.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-do
nt-need-em/ (see the bandwidth section, ignore the Media Queries parts)
Received on Sunday, 27 January 2013 18:34:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:57 UTC