RE: Feedback on "The Network Information API"

Mark wrote:
> Just came across this spec; looks interesting. I'm not sure of its status, so please
> be gentle :)


As long as you are ignoring the old "published" version (TR [1] from June 7, 2011 -- unfortunately there's no provision in W3 land for documents to automatically indicate they are "stale" when newer less official documents become available) and are looking at the ED the ED [2] (September 27, 2012), you're doing a pretty good job -- but please help us by referencing the url of the document to which you're providing comments in the future :)

> * The 'bandwidth' attribute has a potential value of 'offline'. What does this
> mean, technically? I fear that different implementations will have different
> interpretations of this, reducing its value. E.g., one implementation might
> decide that offline is "the last four TCP connection attempts failed" while
> another might be "the user selected the 'offline' button." Yet another might be
> "when I don't have a route to the Internet" or "when the primary interface is
> down." Likewise, how does the browser know it's online again? How often does
> it check?

This is one of the reasons I think this API is totally useless. The only effective way to determine bandwidth is to try to acquire bandwidth to the specific destination. Anything else will give a horrible answer.

If you're in Iran, then your bandwidth could be 1TB, but your bandwidth to Google.com will be 0  [3]. The only way to determine bandwidth is to specifically try to reach Google in that case (and discover it isn't working).

> * 'bandwidth' also can indicate "an estimation of the current bandwidth in
> MB/s..." Again, how does this estimation take place? Would it be an active test
> for capacity (which can have undesirable side effects) or a passive, configured
> value from the OS / environment? I know that it's attractive to abstract this out
> and let implementations decide, but the utility of doing so is going to be very
> low.

In my opinion it's 100% useless, which is why we shouldn't have this API in the first place :).

But the API is designed for UAs to try things out, it'll probably be a cached value which is passively updated by the browser on a lazy or best effort basis.

If you care, you shouldn't be using the API and should instead figure it out for your UC, as no UA will be able to give you the answer you really need short of you actually making the real request you need and responding to actual conditions.

> * Likewise, I wonder whether 'metered' will be able to be accurate, as it
> requires a fair amount of coordination between the network provider and the
> browser. Again, the semantics are quite vague.

It won't. It will be best effort, with the hope that eventually UAs (and networks) will improve in their ability to answer this question.

The best way to improve this btw is to demand that ISPs provide a JSON (or whatever, but preferably JSON, I guess) API to indicate their billing behavior. If such an API appears, then UAs (or just web pages, whichever) could start exposing it.

> * On the other hand, the physical connection *type* is interesting; e.g.,
> ethernet / 802.11[a,b,g,n] / GPRS / EDGE / HSPA / HSPA+ / LTE / WIMAX / etc.
> This would require a registry of some sort, but it'd be very useful information.

For various reasons the network type is totally useless.
You can be on e.g. WindMobile and have one of three states:
21mbps (streaming video), over-basic-quota (VOIP), excessive network user (no VOIP). All on the same 3G network [4]:

> If we elect to slow your speeds when your data usage first exceeds the thresholds outlined above, we
> will slow your speed to a speed of 256 kilobits per second for downloads and 128 kilobits per second
> for uploads. This should not affect any applications that require less than 256 kilobits-per-second
> of download bandwidth or 128 kilobits-per-second of upload bandwidth (such as browsing, email,
> voice over IP or voice streaming applications), but could affect the performance of applications that
> normally require greater bandwidth (e.g. video streaming or peer-to-peer file sharing). In extreme
> cases, and if your data usage levels within the applicable billing cycle continue to be high and to
> exceed the usage levels specified in this policy, we reserve the right to slow your speed down to
> a maximum of 32 kilobits-per-second of download bandwidth or 16 kilobits-per-second of upload
> bandwidth. At this rate only Internet applications that do not require significant bandwidth nor realtime
> streaming performance (such as: web browsing, email, instant messaging) will continue to work
> unaffected - but at a slower speed. If we elect to slow your speeds, we will do so only until the end of
> the applicable billing cycle.

This doesn't even cover cases of congestion (AT&T in NYC).

More amusing problems happen w/ 802.11, as you don't really know anything about the actual uplink (is it another phone acting as a hotspot? Is it a classic modem? A satellite link? DSL/ADSL? Cable?)

LTE as a branding mess is so amusing that I don't think I should need to provide a citation.

> * If it could be made available to the client (which might be quite difficult for
> many deployments), latency and packet loss information would be fantastic.
> E.g., for the latter, a per-origin counters, perhaps inside a sliding window.

This is something which is probably easier and more obviously useful. However, I don't think that DAP is necessarily the best place to define this. I think the WebPerf WG [5] is probably better. The UCs you have in mind (the only ones I consider valid) are things which they want to cover. They've worked on a Navigation Timing [6] spec, and I think that asking them to add timings for XMLHttpRequest wouldn't be unreasonable at all.

> * If you wanted to throw the kitchen sink in, you could make visible things like
> "is IPSEC in use?" and "what's my local MSS"?
> 
> Hope this helps...

It helps in supporting my argument that the spec we have isn't worth having, so thanks :)

[1] http://www.w3.org/TR/netinfo-api/
[2] http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
[3] http://www.upi.com/Science_News/Technology/2012/09/25/Iran-blocks-Google-search-email/UPI-70751348613201/
[4] http://www2.windmobile.ca/wind%20docs/wind-fair-usage-data-050111.pdf
[5] http://www.w3.org/2010/webperf/
[6] http://www.w3.org/TR/navigation-timing/

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 27 September 2012 20:15:41 UTC