[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Tor Network response slowing to zero



On Thu, Feb 03, 2005 at 12:30:13AM +0200, Janne Snabb wrote:
> I had initially set the "BandwidthRate" (which I doubt most people
> do) to a reasonable level compared to my available uplink bandwidth.
> But I still noticed some times massive packet loss. After investigating
> I realized that the default value for "BandwidthBurst" is so high
> that it takes ages on a low-speed link for the bandwidth throttling
> to kick in. I added a very tight value ("100 KB" instead of the
> default "48 MB"). I haven't seen any packet loss after that.

Interesting. Note that Tor's rate limiting is very primitive: we simply
stop reading from the TCP sockets when we don't want to receive any more,
and then start reading again when we do. This presumably causes TCP to
push back until the window goes to zero.

Is this going to produce different behavior (that is, less packet loss)
than simply trying to get packets and having not all of them arrive?
I really don't know. It's probably worth experimenting.

Our default BandwidthBurst is high because I figured hey, letting bytes
through is good.

Perhaps we should try a different approach where if the user doesn't
define BandwidthRate, we start it out at 20 KB with a BandwidthBurst
of twice that, and periodically we check if our measured capacity (the
highest throughput we've seen in the past 24 hours sustained over 10
seconds) exceeds BandwidthRate, and if so, we raise it. This would let
us ramp up by auto-detecting available bandwidth, without the user having
to make any decisions.

Ramping down is another issue, though. For coloc'ed machines, their
capacity typically is at least what we measured. But cablemodem machines
are weird because their available bandwidth varies so much. Currently
our capacity estimates tend to _over_estimate the capacity they have,
since we measure the most we've seen in the past day. One easy ramping
down approach would be, periodically (like once a day or once an hour),
to reset our BandwidthRate to our measured capacity. So if it goes down
dramatically we will react.

Can somebody else speculate on whether this would help?

--Roger