Re: Tor Network response slowing to zero

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Roger Dingledine (arma@xxxxxxx):

> On Wed, Feb 02, 2005 at 01:40:22PM -0600, Mike Perry wrote:
> > Thus spake clifnor@xxxxxxxxxxxx (clifnor@xxxxxxxxxxxx):
> > > Can other users confirm that network response is degrading badly during
> > > the past 2-3 weeks? I have a decent home cable link (1.8Mb down/356 up)
> > > but I am having to wait an average of 15-30 seconds to get any
> > > response--sometimes the connection just hangs. Is there any data being
> > > collected on network response? 
> 
> One of the immediate reasons for this, I think, is that the big
> exit nodes are limited at 1024 open file descriptors, and as
> Giorgos points out, they're hitting that limit. See my post
> http://archives.seul.org/or/talk/Jan-2005/msg00144.html for details.

How about a patch to warn people running in server mode if they have a
1024 ulimit? and perhaps also spew out warnings whenever socket
creation fails with ENFILE so that server admins are more quick about
making sure they up this limit? 

> Another big reason is that we're getting increasingly hammered by
> file-sharers. This has caused some of the bigger nodes to decide they
> don't want to carry this much traffic. We need to teach clients to back
> off better when things are going wrong; I'm not sure of the best way to
> do that yet.
> 
> Or we could take more drastic measures. For example, we could recommend
> an exit policy which accepts 20-22,53,79-81,110,143,389,443,636,706,873,
> 993,995,1863,5050,5190,5222,5223,6667,8080,8300,8888, and rejects the
> rest.
> 
> Heck, we could accept just 80 and 443 and tell people using the other
> protocols to go bugger off.
>
> (A related plan would be to put priorities on certain ports, such as
> 80 and 443, and when using those we ignore servers with capacity less
> than 100kB. I'm not sure how this would play out in the tragedy of
> the commons.)

I like this last plan a lot better than restricting port access, even
if it is limited to attempting to shut out P2P traffic. It seems much
healthier just to throttle it down than outright deny it.

I'm thinking you probably don't want ports to be specified in the
cell, because it would make it easier to associate connections through
the network.

Maybe the top two bits of the length field in RELAY could be borrowed
to create a "priority class" field? Length should never exceed 498
anyways, right? 

 0 - Interactive stuff: ssh, telnet, maybe rdesktop?
 1 - Application buffered: web, IRC, POP, etc
 2 - Data Xfer: ftp, ??
 3 - Bulk: bit torrent, and so on.

The port to class mappings should probably be hardcoded and verified
at the exit servers to prevent a rogue tor client from jacking its
priority to 0 at all times.

As far as queuing, my initial impulse is that priority be strict. If
any level 0's are ready, send them first. Then handle the level 1s,
and so on. Though since ssh and telnet are likely to not fill cells to
completion, this could be wasteful. Is this a concern? Are there other
problems?

Are tor clients and servers able to version handshake so that we can
implement this protocol gradually without making servers puke when
they see 16 and 32k length fields?

> But I think the problem is not that
> the Tor network is mis-allocating its bandwidth, I think it's that we
> simply don't have any left.
>
> In short: run a server. :)

Heh, unfortunately I don't really have the bandwidth to throw at it
now. I'll gladly donate some devel time towards either of the above
two mentioned features, though.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs