[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] "Fast" flag definition



On Sun, Oct 29, 2017 at 04:21:10PM -0700, Igor Mitrofanov wrote:
> It looks like 94.7% of all Running relays have the "Fast" flag now. If
> that percentage becomes 100%, the flag will become meaningless.
> What were the reasons behind the current definition of "Fast", and are
> those still valid? If not, should "Fast" become self-adjusting
> ("faster than 2 Mbps or 70% of all Guard relays, whichever is
> greater")?

The goal of the Fast flag is to have some minimum threshold for whether
a relay is useful at all.

It actually is self-adjusting, in that it gets assigned to the top 7/8ths
of the relays. But *also* it gets assigned to any relay that meets some
minimum bandwidth threshold:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408

The "give it to them anyway if they're above the threshold" is a security
defense, else some jerk could sign up a whole lot of crummy relays,
driving other legitimate relays out of the network, thus making Sybil
attacks more effective.

And the threshold is currently quite low -- 100KBytes/s.

(It's actually more complicated than that, because some directory
authorities assign it based on their own measurements ("I must be voting
a consensus weight of at least 100 for this relay"), and others assign
it based on the relay's self-reported number ("The relay must be claiming
at least 100KBytes/s of capacity").)

So think of Fast more as "worth using at all", where if you don't have
the flag, you don't have a chance of being chosen, and if you do, then
the consensus weights kick in to shift traffic towards bigger relays.

--Roger

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays