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

Re: [tor-relays] Relay accounting calculations



On Oct 5, 2011, at 8:00 PM, Steve Snyder wrote:

> I'm not sure I understand how the relay accounting limit is calculated.
> 
> The manual says that you might specify an AccountingMax limit of 1 GB, a ceiling that would be applied to each of the input and output traffic.  The manual also says that it is known the output traffic can be larger than the input traffic, especially if you're running an exit node.  (I imagine that the converse applies if you also have Tor clients on the same network, using the node, though the manual doesn't say so.)
> 
> Given that the AccountingMax value applies to traffic in each direction, one would have to specify a rate that is half their actual limit.  That is, given a 100GB limit one would specify "AccountingMax 50 GB" in the config file, causing the relay to sleep when 50GB is reached in either input or output traffic.
> 
> Is the algorithm really this inflexible?  If I reach 50GB on output traffic, with only 49GB of input traffic, that puts the relay into hibernation with 1GB of bandwidth left unused.
> 
> That seems counter-intuitive to me.  Is the manual inaccurate, or am I just missing the hidden genius of tracking input and output traffic as distinct pools?  It seems more sensible to specify the full bandwidth allotment, with the relay hibernating when the sum of the input and output traffic reach that limit.

Your understanding is correct, tho there is a logical explanation
for the behaviour. It might not be the most brilliant argument to
have the behaviour as it is, but here goes (I pieced this together
from talking to a few devs who wrote the code back then (I
wasn't a tor dev then), together with my own reasonings. I
hope it is reasonably correct, I hope someone else will correct
me otherwise):

When the bandwidth limiting options were written, the Tor devs
lived in a world where you would buy a pipe that allowed you to
push and receive the same amounts of bytes, and thus it made
most sense to specify the kind of pipe you had instead of
allowing a combined up- and downstream traffic value.

When the bandwidth accounting options were then introduced,
Tor already counted incoming and outcoming bandwidth
separately and adding a disparity between the bandwidth
limiting options would just add more confusion.

Now we don't just change these options because people have
gotten used to them, and changing the semantics wouldn't
be very nice.

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