clarify that downlinkMax is next hop only

[igrigorik]

@jkarlin updated, ptal.. again :-)

[igrigorik]

@yoavweiss @jkarlin thanks for feedback, updated.. again.

Re, "network weather": I've simplified the wording a bit and made it more consistent. FWIW, I'd like to keep it there as a concept as it does a good job of explaining the larger family of variables that may affect the reported value.. and it's a useful shorthand.

Re, "primary interface": this one is tricky. Defining downlinkMax as the max of all interfaces is simple enough, but type attribute is where it starts to get complicated. What would type report in such case? Also, and fwiw, the multi-interface implementations I'm aware of do designate a 'primary interface'. More than one interface may be active (e.g. during a transition between networks), but new requests are routed via the primary interface.

[yoavweiss]

Re, "primary interface": this one is tricky. Defining downlinkMax as the max of all interfaces is simple enough

Actually, we may want to set it to be the sum of all interfaces' downlinkMax. See below.

but type attribute is where it starts to get complicated. What would type report in such case?

Maybe we should enable type aggregates (e.g. wifi+cellular)?

Also, and fwiw, the multi-interface implementations I'm aware of do designate a 'primary interface'. More than one interface may be active (e.g. during a transition between networks), but new requests are routed via the primary interface

I may be wrong about this, but AFAIU for things like MPTCP, the stack can send and receive each packet on a separate interface, which means that even if there is a "primary" interface, both interfaces are in use. It may also mean that the overall effective bandwidth is the sum of effective bandwidth from all networks.

@sleevi - sanity check?

[sleevi]

Maybe we should enable type aggregates (e.g. wifi+cellular)?

That feels even more problematic from privacy (now even more information). I have dual nics on my machine, both hooked up to different networks - would I have ethernet+ethernet?

I may be wrong about this, but AFAIU for things like MPTCP, the stack can send and receive each packet on a separate interface, which means that even if there is a "primary" interface, both interfaces are in use. It may also mean that the overall effective bandwidth is the sum of effective bandwidth from all networks.

Yeah, I'm sorry @igrigorik , but that notion of primary interface is just not well supported by the implementation, especially when you get down to actually thinking through the implications.

Consider a routing table of 0.0.0.0 / 0.0.0.0 / eth0 / pri0 0.0.0.0 / 0.0.0.0 / eth1 / pri0 192.168.0.1 / 255.255.255.0 / eth2 / pri0 192.168.0.1 / 255.255.255.0 / eth3 / pri0

Now, assume we're using MPTCP. Or QUIC, for that matter. I load a page https://www.example.com, which is hosted at 10.0.0.1 - what's the primary interface? Now https://www.example.com loads a single page, and then all subresources are loaded off https://cdn.example.com, which resolves to 192.168.0.2. What's the primary interface then?

This is just speaking in terms of routing tables and complexity; once you add protocols such as QUIC or MPTCP where the act of 'loading https://www.example.com' may have an equal number of packets delivered off both interfaces. What's the primary interface then?

I'm aware that this is perhaps a convoluted example, but the important aspect I'm trying to convey is how the underlying substrate works, and what it can enable. By assuming a 'primary' interface - even if that may be a defensible and rational assumption - and introducing such a notion within the API itself, you now prevent browsers from being able to use these technologies OR add significant complexity in finding a way to express this.

It's also based on a presupposition of certain concepts such as interfaces and routes, and I can categorically state that even though there are conceptual mappings of some aspects, the actual implementations and exposure can vastly differ. It's too low a layer to try to argue for a reasonable cross-platform abstraction when there is not one either at the OSes, the specs, or the details.

[yoavweiss]

That feels even more problematic from privacy (now even more information). I have dual nics on my machine, both hooked up to different networks - would I have ethernet+ethernet?

FWIW, I don't think that type is essential to cover most use-cases, and it has a larger potential for abuse (e.g. "you can only sync over WiFi" due to potentially false assumptions around costs), so I wouldn't be too sad to see it deprecated.

[igrigorik]

@sleevi fair enough, I'm convinced :)

Re, type: to answer my own question, I think we can simply add a new state to it - e.g. "mixed". I agree with @sleevi that we don't want to get into the combinatorial game of enumerating interfaces.

This is not an easy one to spec, but here's my first and very rough attempt: https://github.com/w3c/netinfo/commit/8e778da3e575837f00f228fee71a39b7af10fe5e -- wdyt? A few issues to address: I'm sure we can improve the wording; I'm not sure it makes sense to set downlinkMax to sum of all interfaces (we should probably defer this bit to the UA?); need to update the onchange algorithm as well.

[sleevi]

Yeah, seems to be sufficient rope for browsers to hang themselves with, without tying their hands. Or some other metaphor :)

[igrigorik]

@sleevi @yoavweiss @jkarlin removed "primary interface" and added wording to account for multi-path cases. PTAL. I think we're getting close.. If that looks good I'll squish and merge.

[yoavweiss]

LGTM

[sleevi]

LGTM 2

[jkarlin]

LGTM