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.
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@lists.torproject.org