We are unable to reproduce the issue on the reported chrome version stable 62.0.3202.62, and on the M-61 stable 61.0.3163.100 with the below mentioned steps. The behavior is seen almost the same in M-60 and M-61. as we are getting the navigator.connection.downlink values accordingly, for M-61 its 0.125 and for M-62 its 3.7. We have tested by having the internet connection of 20 mbps. Tested website: Google news on windows 10.
1.Opened news.google.com.
2. Checked the navigator.connection.downlink value in console

@Reporter: Could you please mention whether we have missed any steps in reproducing the issue. 

Thanks!

Thanks for checking.
The values 0.125 and 3.7 are both below 10, the issue here is that 10 is the max.
Besides the point that you're on a 20 Mbps connection and are getting lower values (which may not represent your actual downlink), you should try loading more content to allow for network measurement.
Maybe try watching a youtube video and then looking at the value.

Also, it would be great if you'd have a faster connection (i.e. above 100 Mbps) so that you can easily reproduce.

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on the latest canary(64.0.3247.0) and the latest stable(62.0.3202.62) on Windows-10, Mac OS 10.12.6 and Linux Ubuntu 14.04.

Test steps followed:
====================
1. Launched chrome and opened 4 tabs

https://www.youtube.com/watch?v=H9770lB6E2M
https://news.google.com/news/headlines?hl=en-IN&ned=in
http://edition.cnn.com/2017/10/22/africa/north-korea-africa/index.html
http://www.espncricinfo.com/ 

with videos playing in random tabs and entered 'navigator.connection.downlink' in the dev tool console.

Observation: At no point value goes beyond 10. Tested with internet speed of 1 Gbps.

Regressed in M-62:

Last good build: 62.0.3187.0
First bad build: 62.0.3188.0

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/1a2e29b26b0595dd7b5f11412cc75cbf3c1d23a4..f609e92a2ac7f44160901945b55337fcbf5e17a5

tbansal@: Could you please take a look at this, please also confirm if this should be blocking M-62 stable refresh as well. If not, feel free to remove the blocker label.

Thank you!  

This is WAI in the sense that the Chromium measures throughput using passive estimation techniques. To detect high bandwidth capabilities, those techniques require browser to download a high amount of data in a short period of time. When loading  webpages, most of the browsers are unable to do that, and so even if the network has more than 10 Mbps capacity, the browser won't be able to saturate it, and thus would not be able to detect that high level of capacity.

Also, AFAIK, there are not many users of this API that have a use case for distinguishing if the device has 10 Mbps bandwidth vs. say 20 Mbps. However,  I would be happy to hear any such use cases. I am closing this bug as WAI, but if there are more inputs, please feel free to chime in at https://github.com/WICG/netinfo/issues/64 (which is the right place for discussing this).