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

What should maxBandwidth be if the technology is unknown? #17

Closed
jkarlin opened this issue Sep 11, 2014 · 7 comments · Fixed by #19
Closed

What should maxBandwidth be if the technology is unknown? #17

jkarlin opened this issue Sep 11, 2014 · 7 comments · Fixed by #19

Comments

@jkarlin
Copy link

jkarlin commented Sep 11, 2014

There are going to be platforms where we may know the type of connection but not the specific technology (802.11a/b/g/n/ac etc.). What value do we use for maxBandwidth in those cases?

@jkarlin
Copy link
Author

jkarlin commented Sep 11, 2014

As a specific example, for Android I don't see how to deduce a/b/g/n/ac. Here is a discussion of the issue. Android's WifiManager.getConnectionInfo().getLinkSpeed() could almost be mapped to the various protocols (but there is overlap between n and ac). Or we could simply return getLinkSpeed as the max bandwidth. Thoughts?

@igrigorik
Copy link
Member

There are going to be platforms where we may know the type of connection but not the specific technology (802.11a/b/g/n/ac etc.). What value do we use for maxBandwidth in those cases?

If underlying connection type is "unknown" the current algorithm would lead to +Infinity: http://w3c.github.io/netinfo/#handling-changes-to-the-underlying-connection. Alternatively, we could pick the most conservative value for that connection type, but that would lead to "GSM" for cellular, which offers a whopping 10kbps - don't think that's a very useful value. I think +Infinity makes sense?

As a specific example, for Android I don't see how to deduce a/b/g/n/ac. Here is a discussion of the issue. Android's WifiManager.getConnectionInfo().getLinkSpeed() could almost be mapped to the various protocols (but there is overlap between n and ac). Or we could simply return getLinkSpeed as the max bandwidth. Thoughts?

Josh, do you have some examples of what values getLinkSpeed returns? Digging through the code, it looks like the value is being set directly by the driver [1]. I'm guessing it should return same values as in the spec, but it would be great to confirm this.

[1] http://androidxref.com/4.4.4_r1/xref/frameworks/base/wifi/java/android/net/wifi/WifiInfo.java#349

@jkarlin
Copy link
Author

jkarlin commented Sep 22, 2014

Android's getLinkSpeed seems to return the currently configured wifi rate. For instance on my phone it changes from 54Mbps to 24Mbps as I move around. Since this is still a true maximum value, I think we should use it. Can we update to the spec to say "either use this table or if a more fine grained maximum value is available use that"?

@igrigorik
Copy link
Member

@jkarlin interesting, so the value must be changing based on some RSSI/modulation changes in the WiFi connection. I think it's reasonable to update the spec to allow more accurate estimates based on last hop network weather... This also allows the UA to refine estimates in the future, which is a nice plus.

  • Where available set maxDownlink to the maximum download data rate of the current network interface, which may be dependent on current signal strength, modulation scheme, or other last hop network weather variables. (Note: exact algorithm is deferred to the UA).
  • If no estimate is available, use the standardized, or generally accepted, maximum download data rate captured in the table of maximum downlink speeds.

@marcoscaceres this would require a bit of wordsmithing and an update to the algorithm. WDYT? Reasonable?

P.S. As an aside, Android doesn't provide getLinkSpeed() for cellular connections, but it does provide cell signal strength, plus a few other variables, that we could (in theory) use to adjust the advertised maxDownlink.

@marcoscaceres
Copy link
Contributor

. I think it's reasonable to update the spec to allow more accurate estimates based on last hop network weather... This also allows the UA to refine estimates in the future, which is a nice plus.

Agree.

@marcoscaceres this would require a bit of wordsmithing and an update to the algorithm. WDYT? Reasonable?

Sounds like a really good addition.

igrigorik added a commit that referenced this issue Sep 26, 2014
Where available, use the interface information to provide more accurate
estimate of downlinkMax - e.g. based on signal strength and similar
variables. If such information is not available, then fallback to the
standardized maximum dowlink values.

Closes #17
@igrigorik
Copy link
Member

Took a run at updating wording + algorithm. PTAL.

@jkarlin
Copy link
Author

jkarlin commented Oct 6, 2014

Looks good to me, thanks Ilya!

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

Successfully merging a pull request may close this issue.

3 participants