Closed jkarlin closed 9 years ago
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?
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
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"?
@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.
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).@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.
. 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.
Took a run at updating wording + algorithm. PTAL.
Looks good to me, thanks Ilya!
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?