Proposal: Token Bucket
nickm at freehaven.net
Wed Jan 19 19:24:17 UTC 2011
2011/1/3 Florian Tschorsch <tschorsch at cs.uni-duesseldorf.de>:
> First, we observe that the token bucket for the relayed traffic on the
> outgoing connections is unnecessary: since no new such traffic is generated
> in an onion router, the rate of this traffic is already limited by the read
> bucket on the incoming side (cp. RelayedTokenBucket).
This is not strictly true, I think. Outbound cells with no
corresponding incoming can be generated by local directory requests,
by local bandwidth testing, and probably a couple of other things too.
Also, when traffic arrives slowly on an edge connection, packaging it
into cells adds significant overhead (since every outgoing cell is 512
bytes+TLS overhead but not every outgoing cell is full).
> We therefore propose
> to remove the rate limiting mechanism on the outgoing side. This will
> eliminate the "double door effect" discussed above, since all cells are
> allowed to flow freely out of the router once they passed the incoming rate
> Second, the refill interval of the buckets should be shortened. The
> remaining token buckets should be refilled more often, with a
> correspondingly smaller amount of tokens. For instance, the buckets might
> be refilled every 10 milliseconds with one-hundredth of the amount of data
> admissible per second.
Smaller bucket refill intervals are already implemented in Tor master
if you build with Libevent 2.0 and use the buffervents backend by
passing --enable-bufferevents to configure. The refill interval is
currently set to 1/3 of a second, but that value was chosen more or
less at random; it would be neat to see other values benchmarked as
More information about the tor-dev