[tor-talk] Guard flag vs relay bandwidth

[Roger Dingledine]

On Wed, Nov 14, 2012 at 02:08:16PM +0600, Roman Mamedov wrote:
> From what I can tell the Guard flag affects routed bandwidth very negatively.
> After getting the flag the bandwidth drops off sharply and a Guard node will
> typically push an order of magnitude (TEN times) less traffic than a non-guard
> one. This is confirmed by some blog and mailing list posts I found, mentioning
> that a node will have its traffic drop after receiving the guard flag.

Right. I've got a half-drafted "the lifecycle of a new Tor relay" blog
post sitting around here somewhere. What you describe happens because
clients avoid using relays with the Guard flag for hops other than the
first hop, since they assume they've got lots of load from clients who
are using them for the first hop -- but when you first get your Guard
flag, nobody uses you as a guard yet, so you don't have much traffic.

That said, the drop shouldn't last all that long. Clients replace their
guards every 45 days on average. So you should see a roughly linear
growth in load from getting the Guard flag for 4-8 weeks, and then it
should level off.

> I wonder if can anything can be done about this. Can a torrc option be added to
> set that a relay never wants to become a Guard;

"Don't worry be happy" is my best suggestion here. If you want to read
a lot more about guard flag allocation, see
"Changing of the Guards: A Framework for Understanding and Improving
Entry Guard Selection in Tor"
published at this year's WPES:
http://freehaven.net/anonbib/#wpes12-cogs

> can the algorithms be tuned
> so that Guards also keep receiving more 'casual' traffic (sorry if my
> understanding is not consistent with how this actually works);

The more network capacity that has the Guard flag, the less clients
avoid using Guards for non-first hops. So, convince all your friends to
run fast stable relays. :)

Thanks for running a relay!

Oh, and I'll leave you with one final thought: ensuring "maximum possible
bandwidth consumption" might not actually be the best goal here. Every
time your relay's bandwidthrate token bucket runs dry, that's a pile of
Tor users who have to wait another second before their bytes will move
forward. The best Tor network is one where no relays are bottlenecked.

--Roger