Just to clear up any misunderstanding here, for participants using Chrome, the bandwidth estimation is done at the sender side (JVB) via transport-cc, which basically involves the browser reporting back to JVB which packets it received and which were lost. JVB does the estimation based on that reported loss. When it’s not sending max/HD already, it probes upwards a little from the current sending rate and checks if loss increases, and keeps iterating upwards until either it’s sending max rate or loss increases. When loss is observed it reduces the sending rate until loss drops off, and then starts to probe upward again. (There’s a bit more detail but that’s the general outline.)
So as long as transport-cc is supported, BWE doesn’t depend on the browser reporting bandwidth information, it’s all calculated on the JVB side based on the observed loss. In general if JVB has enough resources & bandwidth, any observed loss is genuine loss and the decision to lower BWE is appropriate. Even a fibre link sold as 1Gbit/1Gbit might (will) sometimes have congestion somewhere else in the path, especially if it’s sold without guarantees as most residential products are.
Firefox is a different story because it doesn’t support transport-cc, so bandwidth estimation for Firefox uses REMB, which is estimated on the receiver (Firefox) side and is less accurate.