Hi All - Generally speaking releasing more information about what's behind the firewall is an anti-goal. I have the same reaction others in this thread have - this api is much more information than what is really needed, and the information it provides is of questionable usefulness anyhow.
The design choice on the server often seems to want to know "is this data metered or not" - which clearly has utility. There are many algorithms in necko I want to apply the same criteria to. I'm still kind of queasy about leaking this but if dan, or richard, or ekr who are all sufficiently cynical about such things thought it was ok I would feel better about that much. But the performance variance of what 3g vs 4g vs wifi vs wired actually means in any instance is so broad and has so much overlap that its simply not a useful performance input. And as long as you're using constant numbers from a table, there really is little you can do with certainty about that other than maybe segregating 2g/bt from everything else.. even that conclusion might be bogus. Further, end to end bandwidth prediction simply does not exist with any specificity - if it did the work of congestion controllers would be un-necessary. Folks in this thread have talked about bridges, vpns, etc, and that's just part of the story. The spec side steps that by assuming the last mile is the bottleneck link, that the last mile is otherwise unused, and assuming weirdly that multipath is a normal thing. That's handy for the spec, but doesn't bear much on reality while it leaks local information. Indeed it ignores the fundamental organization of IP networks as packet switched connections of networks of varying types. (give me a POTS line I hear you crying - but even that is likely faked circuit switching on voip now). >From an implementation pov, the browser could over time give a reasonable metric about latency and bandwidth 'to the internet' just through passive observation.. maybe as a 3x3 l/m/h matrix. but this would be for the client in general and not really for the path between the client and the origin - the latter is really what the origin wants. Without adding per-origin overhead of a new speed test I would think the ResourceTiming already available to it would be as good of a guide as anything else. So even though it would be a cool engineering task to look at this whole-browser, its of questionable utility imo.. and doing so leaks performance observations cross-origin. I guess the other thing I would want to consider here is the competitive aspect of this API, but I wouldn't feel obligated to ship it for checklist reasons. tl;dr; is the metered-data bit enough and if so, can we just implement this by always returning 1 of 2 configs (cell vs wifi e.g.) with const bw? -P _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
