potential source of overrate measurement

[binnacle]

I have observed BandwidthRate enforcement does not take effect immediately when utilization reaches the threshold even when BandwidthBurst is set to the same value, that actual bandwidth can exceed the threshold for several seconds before it does. In addition BandwidthBurst create additional room for bandwidth in excess of BandwidthRate.

Seems possible that relays--exit relays in particular--relying on BandwidthRate to limit traffic could measure too high and be overrated in the consensus as a consequence of the above. Adding this note in case the information is helpful.

[pastly]

sbws targets a measurement time of 6 seconds and accepts measurements that took between 5 and 10 seconds. It also makes many measurements one right after another over the same stream.

With this in mind, do you still believe this might be a problem?

[binnacle]

Not really sure. If you mean the first six seconds of measurement are deemphasized that certainly will help, though I think it takes more than that before the daemon rate limit takes effect. Back-to-back series of measurements will help too as long as the duration is not short.

Seems to me it might be worth minor investigation as part of other testing work. Your call of course.

[pastly]

If you mean the first six seconds of measurement are deemphasized that certainly will help

Nope. I mean the number of bytes to download is calculated such that it will probably take 6 seconds to download them all. Measurements between 5s and 10s are accepted. Measurements outside this range cause the calculation to be redone. Measurement is repeated over a single stream with no delay until there are 5 measurements that are acceptable.

If someone wants to test how {,Relay}Bandwidth{Rate,Burst} settings interact with measurements, I'd suggest

• starting with the simple-ipv4 or simple-ipv6 test network and making a copy of it
• modify the config generation such that relays have {,Relay}Bandwidth{Rate,Burst} set in some way that will make result verification easy
• run the network and the scanner and verify results

[binnacle]

the number of bytes to download is calculated such that it will probably take 6 seconds to download them all

Biased heavily toward measuring latency rather than residual bandwidth. Will have a strong tendency to bypass BandWidthRate/BandWidthBurst based on what I have observed, though the last time I looked was 2.6 or 2.9 and the logic could have changed since then.

I see the value in measuring latency but it's an incomplete picture of the state of relay's ability to forward traffic. Suggestion: take both the 6-second latency measurement and something like a 40 second measurement that biases to pure residual bandwidth and combine the two when arriving at consensus votes.

With respect to investigation, what I meant was examining measurements of individual relays with known characteristics in the live network during the phase where logic for final vote generate is under development and seeing how different rate-limit types interact with the scanner.

[pastly]

We are working on this in PR #191 and issue #155.

Thanks for your suggestion.