Question for DEVs -- Write/Read Limiting

[Roger Dingledine]

On Mon, Jan 15, 2007 at 01:51:58PM -0800, Joseph B. Kowalski wrote:
> >From the release notes for version "0.1.2.5-alpha":
> 
> ....It enables write limiting by default...
> 
> And
> 
> ....Enable write limiting as well as read limiting...
> 
> What I'm trying to figure out is what, specifically, is now enabled 
> by default that was not before?

Before, we did rate limiting on incoming bytes. We let outgoing
bytes go out at whatever rate the network could support.

This was useful, because if we did rate limiting in both directions and
servers sent out more than they read (e.g. because they were answering
directory requests too), then they'd end up queueing a big pile of
outgoing bytes, and Tor data would experience higher and higher latency
because data could come in easily but it would sit on buffers for a long
time on the way out.

On the other hand, it was bad because people would configure rate limiting
and be surprised that the rate limiting "didn't work".

Nick convinced me that being predictable for server operators was more
important than some more latency. So now we rate limit in both directions.

I'm now working on trying to make Tor servers intelligent about when to
turn down directory requests (send a "503 busy" instead of answering), so
Tor clients will get answers to their directory questions in a reasonable
time period, but we won't end up in the above bad situation very often.

> I mean, the Tor FAQ talks about two 
> things relating to traffic limiting: The 
> BandwithRate/BandwidthBurst options, and the 
> AccountingStart/AccountingMax options. Is it some setting related 
> to these that is now set by default?

Now we do the BandwidthRate/BandwidthBurst thing twice -- once for
incoming and once for outgoing.

The AccountingStart/AccountingMax behavior is unchanged.

> Or is it something entirely 
> different? If it is different, can we get a short explanation of 
> the changes? Also, if it is different, is there a config file 
> setting that would make a server behave the way it did before these 
> changes were implemented?

Nope. I had a plan to let people configure their BandwidthRateRead
and BandwidthRateWrite separately, but Nick convinced me it would be a
headache to handle even more combinations and permutations.

If you wanted to think hard about that and send us a patch, I bet we'd
accept it.

> My apologies if this is explained somewhere already and I've missed 
> it.

Hope that helps,
--Roger