Hi,
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")?
Thanks!
On 30 Oct 2017, at 10:21, Igor Mitrofanov igor.n.mitrofanov@gmail.com wrote:
Hi,
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")?
It is self-adjusting, and we expect at least 87.5% of relays to have it:
"Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408
But maybe we could increase the threshold.
Feel free to open the ticket at:
-- Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
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
Thanks Tim and Roger.
I filed https://trac.torproject.org/projects/tor/ticket/24046.
(Not looking for any immediate fixes, just making sure those "Fast" 1 KB/s relays that you can see on blutmagie.de and the 100 KB/s threshold are not at odds with whatever minimal user experience Tor wants to provide).
On Sun, Oct 29, 2017 at 5:47 PM, Roger Dingledine arma@mit.edu wrote:
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Igor Mitrofanov -
Roger Dingledine -
teor