[tor-relays] consensus "Bandwidth=" values

[Roger Dingledine]

On Wed, Nov 30, 2011 at 05:51:13PM -0600, Scott Bennett wrote:
>      Something new appears to be happening in the authorities' assignments
> of "Bandwidth=" values in the consensus documents over the past few days.
> Here are some statistics from the recent consensus with the following valid
> times:
[snip]
> The top ten in the above list account for 814 relays or 32.73% of all relays
> in the consensus, yet they will get little or no traffic because of the
> assigned "Bandwidth=" values.  My relay's traffic went from around 55% - 60%
> of what I had hoped to contribute down to almost nothing in the course of
> about three days, and the "Bandwidth=" value assigned to it in the consensus
> is 1.  For a long time, it had typically been in the high 20s to high 30s
> with occasional excursions from slightly lower to somewhere in the 50s.
>      So is this sudden, massive reassignment of loads due to a bug in the
> newest tor version(s)?  Or is it an intended change by the developers?

Mike Perry is trying out more network rebalancing ideas. See

https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt#l354
https://trac.torproject.org/projects/tor/ticket/1976
https://trac.torproject.org/projects/tor/ticket/4425

The "bandwidth authority" scripts do active bandwidth measurements,
and adjust the bandwidth weights they vote about based on how a relay
performs compared to its peers. Last week "peers" were characterized
based on the self-advertised bandwidth, that is, the bandwidth in the
relay descriptor. With the new PID design, "peers" are now a function
of the weight in the consensus.

In theory this feedback loop should drive even more traffic toward relays
that can handle it, and even less traffic toward relays that can't,
until we reach an equilibrium.

In practice, it drives super-fast relays to a weight of infinity, and
all the rest to a weight of zero.

Mike thought he'd gotten things (more) right this time, but it would
appear that has hasn't:
https://metrics.torproject.org/performance.html#torperf

Sorry for the disturbance. I think we should probably turn the experiment
off soon. But the little dip you see in the torperf graph before the
spike makes me think there *is* a point here that is better, even if we
haven't found it yet. :)

Thanks,
--Roger