[tor-talk] Guard flag vs relay bandwidth

Roman Mamedov rm at romanrm.ru
Wed Nov 14 10:18:34 UTC 2012


On Wed, 14 Nov 2012 04:47:38 -0500
Roger Dingledine <arma at mit.edu> wrote:

> Right. I've got a half-drafted "the lifecycle of a new Tor relay" blog
> post sitting around here somewhere.

That would be great. :)

> 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

Yes I have read descriptions of the Guard flag, but to be honest I am not
convinced at all by the arguments presented in its favour.

To me it just seems to be an elaborate trade off that results in "if you
are f***ed, ensure you are f***ed as completely as possible and with the most
dire consequences possible".

"An adversary has a chance to see some of my entry traffic for some time"

...seems rather harmless to me compared to the Guards system's of:

"an adversary has a chance to see ALL of my entry traffic for a long period"

> 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.

The nodes are far from being at network bottleneck, I mean b/w consumption in
terms of terabytes per month, since in most cases what I have is a bandwidth
arrangement where on a 100 Mbit or 1 Gbit port usage of X TB/month is possible
and this costs Y USD. Unused bandwidth from one month does not carry over to
the next, so it's suboptimal when a node only uses like 30-50% of what it could
have used that month.

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20121114/793e8592/attachment.pgp>


More information about the tor-talk mailing list