Re: State of the Network Information API specification

Hi Mounir,

Regarding `metered` - I believe that, as you said, the attribute is
extremely useful. The main issue at hand is the definition of what is
considered metered. I believe that along-side the `metered` definition
that we can get from the device's APIs (metered, roaming, network type),
there is a place for the user's preference, whether he prefers to save on
bandwidth or not.
For example, let's assume we have an Web app that can sync its data as
often or as rarely as we like. The trade-off is bandwidth usage (and
related costs) vs. fresh information. Let's also assume that we have a
certain data plan,
where users pay 10 cents per MB.
Certain users may consider that expensive, and therefore would like rare or
on-demand syncs.
Other users with the same data plan would prefer frequent automatic syncs.
Our theoretical Web app can demand the user for their preference, but it
would probably be better if such a preference would be set once by the
user and available to all Web applications that want to take it into
consideration.

Regarding `bandwidth`, I believe that the attribute must be better defined.

If the information we want to provide developers is "radio
bandwidth", then the only possible place we might be able to get accurate
radio
information from is the OS. I'm not sure OS APIs that expose
accurate bandwidth information exist, and if not, what is the
possibility of adding such APIs to future OS versions.
IMO, inaccurate radio bandwidth information
(such as the current interim implementation) does not provide any value to
Web developers.

If the information we want to provide developers is "effective
end-to-end bandwidth" (which IMO is much more relevant to actual
developer use cases), than it is a different case altogether.

I have recently contemplated the question of in-browser bandwidth
measurements and the complexity it involves in a different context [1].
Estimating bandwidth
according to already downloaded resources over various TCP connections
in various phases is not an easy task, the information will probably be
available only after a certain phase in the page's loading and the
information
will probably not be 100% accurate. Nevertheless, I believe it is the only
option
to acquire end-to-end effective bandwidth.
I also believe that we can't have a single `bandwidth` number, but rather a
`bandwidth(host)` function, which returns the bandwidth value as well as
an indication for its accuracy.

I'd like to point out that if only the Resource Timing API
contained the byte size of each resource[2], this heuristics bandwidth
estimation could have been done outside of the browser, in JavaScript.
The "network change event" can also help indicating that previous
measurements are not necessarily relevant. Assuming
that this problem is an interesting one for the Web development
community, that would enable getting much more people involved in
trying to solve this problem.

Regarding the option of *active* periodic bandwidth measurements to a known
"reference server", I believe it is not a viable one. Such measurements
will either eat up the user's
data plan & battery, or will be rare enough to be irrelevant.
Also, as mentioned before, this option bares a cost also to the "reference
server"
operators as well as the mobile operators & poses a privacy risk.

Yoav

[1]
http://mobile.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-dont-need-em/
[2] http://lists.w3.org/Archives/Public/public-web-perf/2013Jan/0000.html

On Thu, Jan 24, 2013 at 9:57 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> Hi,
>
> There has been a lot of discussions lately regarding the Network
> Information API. I took some time today to think about what has been
> said and how it could be solved.
>
> The first part of the API is the 'bandwidth' attribute. The intent of
> the specification with this attribute is to have a clear way to check if
> a client has enough speed to do a certain type of actions.
>
> A few use cases would be: I want to provide high resolution images by
> default if the client has a bandwidth of at least X kb/s; or, I want to
> automatically fetch email attachments if the client has at least X kb/s
> (to not kill its connection); even, I will not try to sync emails if the
> client has less than X kb/s of bandwidth (think of fetching emails when
> you are on Edge).
>
> 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).
>
> The spirit of the specification is that the vendors will come up with
> more or less sophisticated implementations.
> 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.
>
> The only alternative I've been able to come up with is to change the
> bandwidth attribute to an enum. The enum might look like it would ease
> the implementation complexity but this is not really the case. In
> addition, it would make the attribute's behaviour hard to specify so
> hard to understand for the authors.
>
> Indeed, we could have something like { "slow", "fast" } or {
> "very-slow", "slow", "fast", "very-fast" } but "slow" or "fast" have a
> relative meaning. The speed of a connection depends on what you want to
> do, the type of connection you have and the country you are in, etc. It
> is very hard for a user agent to know if a website will consider a given
> connection speed as fast or slow.
>
> In addition, using an enum wouldn't really ease the implementation, it
> will just be less visible that the implementation is simplistic: it is
> very simple to see that an implementation is returning pre-defined
> values for the bandwidth as a double but it is harder to see that if the
> bandwidth is an enum.
>
> 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.
>
> Regarding the second attribute, 'metered', I think the intent of the
> specification has often been misunderstood. The attribute should return
> true if the connection is sensitive to heavy data usage. Again, that
> doesn't mean that any connection with a cap should be marked as metered.
> If the cap is at 100GB, there is no point in marking it metered as long
> as the user is far from the 100GB.
>
> The use cases for this attribute are pretty much obvious and very useful
> in a mobile word. It can be summarized as preventing [large] downloads
> while using a metered connection. Typical examples would be app updates,
> email fetching, synchronisation frequency...
>
> 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.
>
> In addition, as for bandwidth, even if the first implementations are not
> perfect, metered can always be improved. An implementation like the one
> in Firefox for Android is always better than nothing and it is possible
> to improve it with the Android API now.
> The implementation could have been/be improved also by an option in the
> user interface to mark the current connection as metered. Maybe even
> having a first run experience that asked the user if his/her mobile
> connection is metered.
>
> There were two major ideas to improve this behaviour of the metered
> attribute. The first one is to make it more granular: how bad is it
> metered? or why is it metered? As much as I agree that could be an
> interesting idea, in practice, it is likely too early to go that far. I
> think introducing another attribute later like "meteringType" if needed
> would be a better idea.
>
> 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'. Likely, they will follow the true or false path. Relying
> on the user agent to do the right thing seems better for everybody I
> believe.
>
> I would be really interested in feedback. If you are implementing or
> tried to implement this specification, I would love to hear about your
> experience.
>
> [1]
>
> https://developer.android.com/reference/android/net/ConnectivityManager.html#isActiveNetworkMetered%28%29
> [2]
> http://msdn.microsoft.com/en-us/library/windows/apps/hh465399.aspx#adapt
>
> Thank you for reading.
>
> --
> Mounir
>
>