Proposal: Token Bucket

[Nick Mathewson]

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

yrs,
-- 
Nick