search

WICG / netinfo

https://wicg.github.io/netinfo/
Other
95 stars 24 forks source link

ConnectionType for tethering? #59

Open thiemonagel opened 7 years ago

thiemonagel commented 7 years ago

Could you please clarify which ConnectionType is to be reported in case a device is tethered? For example, tethering a laptop to a phone might happen over wifi and thus technically "wifi" would be the correct ConnectionType, however the effective connection type that governs the properties of the connection (speed, latency, cost) and that matches the representation in the mind of the user most probably would be better described by "cellular".

(For example Chrome OS interprets the spec quite literally and reports "wifi" for tethering, cf. https://bugs.chromium.org/p/chromium/issues/detail?id=728065.)

igrigorik commented 7 years ago

As specced, ConnectionType reports the first hop.. which will be either WiFi or Bluetooth or ..., depending on the type of hotspot you're connecting to. ECT, on the other hand, will be determined by the end-to-end performance, so yes CT may say "wifi" while ECT can report "slow-2G".

Does that help?

thiemonagel commented 7 years ago

Thank you. Imho the spec could be a little clearer about that. There's lots of language about "first hop" for downlinkMax, but I didn't find a single mention of "first hop" for type.

To summarize, this my understanding of which hop each of the attributes relates to: type -- first hop effectiveType -- most limiting hop downlinkMax -- first hop downlink -- most limiting hop rtt -- most limiting hop

I'd like to note that for tethered connections, using the first hop for type breaks all web app use cases (4.1, 4.2, 4.3) that are mentioned in the review doc. Imho it would be really great if we could amend the spec to handle tethering gracefully.

For me it would seem easiest to let go of the notion of the first hop and replace it by most limiting hop known to the client. In the absence of tethering indicators that would be the first hop thus no changes there, however when tethering is detected (e.g. via ANDROID_METERED DHCP option) the type could be reported as "cellular". (Though without further knowledge about the cellular link, downlinkMax would have to be reported either as infinity or for the connection technology of the first hop.)

Imho that change would make the spec clearer, because now all five attributes would consistently relate to the most limiting hop. Any thoughts?

igrigorik commented 7 years ago

To summarize, this my understanding of which hop each of the attributes relates to: type -- first hop effectiveType -- most limiting hop downlinkMax -- first hop downlink -- most limiting hop rtt -- most limiting hop

Yep, and thanks is great feedback.. Agree that we should spell this our more clearly in the spec.

Re, first hop vs most limiting hop: we're veering into discussion in https://github.com/WICG/netinfo/issues/41#issuecomment-306401192 -- let's take it there, to avoid parallel threads.