On Sun, Jun 02, 2019 at 01:30:18PM +1000, teor wrote:
Which bandwidth authorities are limiting the consensus weight of these relays? Where are they located?
The one in question is in Sweden: https://metrics.torproject.org/rs.html#details/D5F2C65F4131A1468D5B67A8838A9...
It has votes of: w Bandwidth=10000 Measured=65200 w Bandwidth=10000 Measured=70000 w Bandwidth=10000 Measured=74200 w Bandwidth=10000 Measured=77000 w Bandwidth=10000 Measured=99400 w Bandwidth=10000 Measured=102000
and it currently reports a self-measured peak at 56MBytes/s.
So one could interpret the current bwauths as saying that it is a bit above average compared to other 56MByte/s relays. Maybe that's because the other 56MByte/s relays got better lately, or maybe that's because there's less overall traffic on the network, but my guess is it's because it's stuck in that rut because the bwauths are not good at realizing it could go a lot faster.
Are the relays' observed bandwidths limiting their consensus weight?
bandwidth 89600000 102400000 55999620
So it looks like no.
If the relays are being measured by longclaw's sbws instance, we should also look at their detailed measurement diagnostics.
Looks like yes, it is measured:
w Bandwidth=10000 Measured=78000
I look forward to hearing about these detailed measurement diagnostics. :)
Do we have funding to continue to improve the bandwidth measurement infrastructure? Or to maintain it?
If we don't have any grants in the pipeline, now would be a good time to start some.
Agreed.
sbws was always intended (as far as I recall) to be a bandaid to make the torflow approach more maintainable, while we continue to await research on better-but-still-workable approaches. I hear the NRL folks have another design they've been working on that sounds promising.
I will propose this change to the dir-auth list in a bit, but here is your chance to point out surprising impacts that I haven't thought of.
Splitting bandwidth between multiple relays has privacy implications, because traffic is easier to track between instances.
Right. It also causes more TCP connections to be used overall than would be needed if we could make individual relays work better.
It also increases the size of the consensus.
So we should choose a value for AuthDirMaxServersPerAddr that is a compromise between these competing goals.
Why is 4 better than 3 or 5?
I figured doubling 2 would make security intuitions simpler.
(4 is also the value we used to use for AuthDirMaxServersPerAuthAddr.)
--Roger