Thus spake Roger Dingledine (arma@xxxxxxx): > 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
Attachment:
pgp7SENteU4Hf.pgp
Description: PGP signature