2011/1/3 Florian Tschorsch <[email protected]>: [...] > 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
