Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConnectionType for tethering? #59

Open
thiemonagel opened this issue May 31, 2017 · 3 comments
Open

ConnectionType for tethering? #59

thiemonagel opened this issue May 31, 2017 · 3 comments

Comments

@thiemonagel
Copy link

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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 #41 (comment) -- let's take it there, to avoid parallel threads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants