Tor client performance (was Re: URGENT: patch needed ASAP for authority bug)

[Hans Schnehl]

On Wed, Apr 21, 2010 at 02:11:06AM -0700, Mike Perry wrote:
> Thus spake Olaf Selke (olaf.selke at blutmagie.de):
> 
> > Roger Dingledine wrote:
> > > 
> > > Well, the problem central to this thread is "Lately, certain relays are
> > > receiving way more *connections* than they can handle, and it's not
> > > only the relays at the very top of the bandwidth charts." So I think
> > > it's very relevant.
> > 
> > yep! Sorry to bother you again with this number-of-connection issue. Tor
> > on my network status machine is a non exit relay with a rather
> > restrictive bandwidth policy of "BandwidthRate 50 KB" and
> > "BandwidthBurst 100 KB". Even this tiny middleman relay holds 10000+ tcp
> > connections. Probably this number of connections will kill most routers
> > used in residential environment.
> 
> Are you certain this middleman relay did not get assigned the guard
> flag? Please see the blue "Consensus" column in:
> http://metrics.torproject.org/consensus-health.html

Sorry for jumping on to this thread again, but better now than never.
This matter obvioully tends to get worse day by day.
My node's nick is 'vallenator', running since a few years with a bandwidth
I described in a post a little earlier in this thread.

> 
> If you do not have the guard flag, then we have a serious issue on our
> hands. Either Andrew is right about there being a super-abundance of
> out-of-spec clients, or the network as a whole is experiencing a tcp
> connect flood attack.

During all the 'testing', vallenator lost it's guard and stable flag.
For a try, I left it completely idle for a few days, restarted it
*with another IP*, only to find the node with 20.000 states/connections
within some 2 hours. Again, this is the upper limit of connections this
box will accept.
Tor basically stalls with tons of (there's a linebreak, sorry) 
[info] onion_pending_add(): Circuit create request is too old; canceling
due to overload
After this Tor turns into a state of unresponsiveness with k's (see above)
connections and relaying 'something' at a rate of 1 to 3 mbit/s, so
basically nothing.
You may see this behaviour for quite a few more nodes by going through
your historic consensuses or, a little more comfortable, wacthing the
graphs on one of the TNS sites.    
I guess 95% of all connections simply hang around doing nothing.
Interesting enough, after forcing down rigorously the number of
connections, Tor still stalls with the same [info] and does not recover
back.

> Providing us with the name/idhex of the relay would be even better,
> because we could then look back in the descriptor history to see if
> you ever had the Guard flag.

he guard flag was there for a long time.          
r vallenator f7RxcXR9IemCfCKDxZ7BaQsFi8Y E2RwsYsqCen6Wgqet5jVOkGZOY0
2010-04-21 08:30:10 91.121.162.67 443 80
s Fast Named Running V2Dir Valid
v Tor 0.2.2.12-alpha
w Bandwidth=3080
p reject 1-6553
> 

BTW, only in very rare cases the bandwidth n the consensus for this node
was anywhere close to what was actually annoounced or it was willing to
provide.  Looks to me as if the authorities method of determining nodes
bandwidth is somewhat insufficient and therefore may not necessarily be a
base for anything.

There are indeed concentrations, AFAIK of originating IP's and /16 /24
nets.

> This data point would help us a lot to determine the source of this
> issue.
> 
Go ahead.

Need more ? just ask. 

HTH


Hans

Un burro le enseña al otro burro