Analysis of the problems many relay operators are currently facing

[Mike Perry]

Thus spake Roger Dingledine (arma at mit.edu):

> My intuition is that a huge amount of it was going to openssl buffers.
> When you have 20k TLS connections open, that's 37k*20k = 740 megs of
> ram just sitting idle in openssl.

Out of curiosity, would this issue likely be alleviated by a switch to
UDP+DTLS, or would the same amount of OpenSSL buffering be required,
despite the fact that we'd be using significantly less sockets?

> > Perhaps we need to
> > limit the amount that we up-rate any router's bandwidth, or perhaps we
> > need to find a way for a router to signal that it's running into load
> > troubles and get downrated.
> 
> Mike pushed back in the tor-relays thread about my suggestion of
> capping the amount of attention we give to any router. That approach
> will apparently really reduce the performance gain we can get.
> 
> It would be great to reduce the weightings for relays that are failing --
> but it's hard to remotely detect "about to fail", and "actually failed"
> usually comes in the form of a down relay.

I pushed back for a couple of reasons, actually. I believe that
requiring relay operators to tweak configs to advertise their capacity
is not a scalable or ideal solution. Any nob we give them is likely to
be a hack that will require black magic and/or keen intuition to use
properly. It would be much better to find a way to measure their
capacity issues in terms of memory or fds.

For example, is it possible that we can alter the relay code to stop
accepting TLS connections when the total tor memory and fd usage
approaches some limit, ideally a limit based on ulimits, available OS
memory, and/or total physical memory?

If we can get Tor to degrade by failing connections, we can measure
this failure rate using the scanners or even a distributed approach
like EigenSpeed and calculate appropriate capacity adjustments using
it. We should be measuring reliability anyways, to protect against
attacks like the one in Borisov et al's "Denial of Service or Denial
of Security" paper.



-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100504/219b480c/attachment.pgp>