Re: Not using slow circuits (was Re: Tor slow no matter what I do.)

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Fri, 1 Feb 2008 19:47:34 -0500 Roger Dingledine <arma@xxxxxxx>
wrote:
>On Thu, Jan 31, 2008 at 09:00:18PM -0800, Mike Perry wrote:
>> > I don't see how that helps much.  Circuit setup generally isn't the
>> > cause of slowdowns.  Normally, going through a server with 25KB/s is the
>> > slowest point in the 3-point chain.
>> 
>> Actually, it /is/ likely that one setting here is actually doing
>> something.. "CircuitBuildTimeout 5" may have a survival of the fittest
>> style effect. If you tweak the circuit setup down to only 5 seconds,
>> only those servers who have ~1 second latency or less are going to be
>> able be members of your circuit, so you effectively will be weeding
>> out slow and congested nodes from your paths.
>> 
>> Of course, there are anonymity implications here.. You are ultimately
>> reducing the set of routers you are using, but on the other hand, you
>> are automatically avoiding overloaded nodes, which technically is good
>> for load balancing.. 
>> 
>> I'd be interested to hear Roger, Nick and Paul weigh in on this idea.
>> Are there good reasons to keep circuits alive that have nodes in them
>> so overloaded that it can take them up to a minute to build a circuit?
>
>Right. I think it was the Foxtor folks at CMU who first suggested the
>idea of measuring latency of a circuit once it's built (or measuring
>time to build a circuit) and dropping circuits that are "too slow".
>
>There are two problems with just doing it via CircuitBuildTimeout
>though:
>
>a) If many people do this, and if a high fraction of circuits are judged
>inadequate, then we're really pumping up the amount of cpu work that
>each node needs to do -- and it's all wasted work too. Servers aren't
>quite on the edge of being overloaded anymore these days, since we raised
>the circuit rotation period to 10 minutes a few years ago. But I already
>feel that 10 minutes is too high, and if we have to raise it any higher
>because people are DoSing the servers with public key operations, that
>would be bad. Consider the extreme where all the servers get overloaded
>by this denial of service attack, and all the clients keep giving up
>and starting again after just a few seconds, causing even more load,
>causing even more clients to give up and start again, ...
>
>b) People on slow networks will never establish a circuit with a low
>default. If you're on a modem, your local network connection is otherwise
>full or slow, or your net connection is lossy, then you sometimes need
>the whole minute just to get enough cells back and forth.
>
>What about a design where the client keeps a rolling record of recent
>circuit build times it's seen, and discards circuits that take more
>than the 75th percentile? Or 90%, or first standard dev, or whatever
>is good. Perhaps Mike or Kevin/Damon have stats on the distribution of
>circuit build times? :)
>
>(It's unclear what anonymity impact this might have, but it might be
>substantial: if a lot of our potential paths through the network involve
>a slow link, and we discard all those potential paths, that would make
>a big difference. On the other hand, that's exactly the point.)

     Perhaps there is a simpler quasi-solution here.  Right now the tor
documentation suggests that one consider running tor in server mode if
one has at least 20 KB/s bandwidth to spare for its operation.  Perhaps
changing that figure in the documentation--maybe doubling it?--and
publicizing the change on this list would gradually alleviate some of the
problem.  The tor network's average performance has improved considerably
in the two to three years I've been using it, so perhaps the possible
negative consequences of raising the recommended minimum bandwidth would
prove to be minor in practice.  In the U.S., one ISP commonly used for tor
servers is Comcast, which typically has a trasmit limit of about 50-55 KB/s
with occasional bursts to perhaps 90 KB/s for a few seconds.  Changing the
minimum bandwidth recommendation to 40 KB/s would be unlikely to eliminate
this large pool of server operators.  It's worth remembering that 20 KB/s
really only supports one not-very-fast stream at a time anyway.
     Also, a few countries already have fiber optics support to residences,
but more are converting to it.  This upgrade has finally begun in some
parts of the U.S.  Although it will be a while before it is available
everywhere in the U.S., fiber optics to residences is now available from
Verizon in some places and offers speeds up to a fully symmetric link at
10 Mb/s (on the order of 1 MB/s) in each direction for about US $65/month.
As that service becomes more widespread, I'd bet that a lot of tor server
operators will upgrade to it and allocate at least a large part of it to
their server(s).


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************