[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Proposal: Token Bucket
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: Proposal: Token Bucket
- From: Nick Mathewson <nickm@xxxxxxxxxxxxx>
- Date: Wed, 19 Jan 2011 14:24:17 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Wed, 19 Jan 2011 14:24:22 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JsLKI51u52L0aSzk4GoKg2Ya+J8q+ortrGgjn+lKUVc=; b=ZbwE3QQwOuqxb7gI+65VpMtbwtdkhTqIm2PehEfallb5QAys9SSdTBXOHECslgErY5 7jH9bLs5yezpcUs6DDOD+iDdp/v+aRJ8gKmaR419tifnucJeNnIH5OFSP8rFhAnRJn1d zLjQfAnzDx3spIGl2ymFuMjwuB0YKLNli2suo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=YdjbD/sPSFEF8gveHlm8xu7aF+PGZu9mfdvVHUozPonKFBGp7T6Lm40n5nQqq2w23m QxeVCZavindSERo08qnX92XP0wW9U6+CiGKN4qgVsWvq3cLZlXsgX6EX6sBY0vTSO3RQ LU99DjHUJa4URsNLvrC8VW8sPGpYgFTNGWWfg=
- In-reply-to: <1A6A4CA8-4677-4D8C-8A99-AD2CACFFC1FE@xxxxxxxxxxxxxxxxxxxxx>
- References: <1A6A4CA8-4677-4D8C-8A99-AD2CACFFC1FE@xxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
2011/1/3 Florian Tschorsch <tschorsch@xxxxxxxxxxxxxxxxxxxxx>:
[...]
> 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