[tor-bugs] #13414 [Tor]: Increase Authorities' AuthDirMaxServersPerAddr to 4 or 8 to use more processors

[Tor Bug Tracker & Wiki]

#13414: Increase Authorities' AuthDirMaxServersPerAddr to 4 or 8 to use more
processors
------------------------+---------------------------------
     Reporter:  teor    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:  Tor: unspecified
   Resolution:          |   Keywords:  tor-auth tor-router
Actual Points:          |  Parent ID:
       Points:          |
------------------------+---------------------------------

Comment (by teor):

 Sorry, isis, I should have quoted you on Sybils directly :-)

 Here are some factors for consideration, including some quick
 calculations. Most favour a parameter of 4-8.

 '''Limits based on DoS'''

 Yes, there are DoS implications for an attacker who could control 1000s of
 IPs: doubling the size of the consensus, for example.

 So, if we use "double the consensus" as a rough guide to undesirability,
 and conservatively assume 6000 routers, an attacker would need to control:
 * 16* 375 IPv4 addresses -  1.5 x /24
 *  8* 750 IPv4 addresses -  3   x /24
 *  4*1500 IPv4 addresses -  6   x /24
 *  2*3000 IPv4 addresses - 12   x /24

 Based on that quick and dirty calculation, I'd limit
 AuthDirMaxServersPerAddr to 8 router instances per IP, to make a consensus
 DoS slightly harder than a class C block. Even AFO-Admin would have needed
 at most 14 on their server to saturate their pipe. (And they could get a
 second IP for that, if needed. Or activate AES-NI and similar
 optimisations to bring the CPU load down.)

 '''Limits based on Hardware'''

 As an example, Intel's Xeon series ranges from 1-10 cores, with 2 & 4
 cores being the most common. Hyper-threading increases this to 4-8
 threads/logical processors for many of the later models.[0]

 Given that we already have limited parallelism with tor worker processes,
 I think 8 relays per IP would work well for the majority of server
 hardware.

 '''Limits based on OS resources'''

 Using 8 instances to connect to around 5000 routers each could see us
 using 40,000 connections/files. As discussed in #9708, this starts to
 stretch the ulimit / sysctl kern.* parameters on Linux & *BSD/OS X
 systems.

 By the way, we currently set MAX_CPUWORKERS and MAX_DETECTABLE_CPUS to 16
 in tor, so we should perhaps adjust that as well if we go to 16 or more
 instances per IP. (Up or down?)

 I could imagine a server with 8 tor instances and 8 logical CPUs using 8
 tor + 8*8 cpuworkers = 72 processes just for tor. Above this point, all
 that process scheduling starts to become counter-productive.

 By contrast, the 4 + 4*4 case yields 20 processes, which is a little low,
 even for a 4-processor system, particularly when cpuworkers don't do much.

 So I'd favour 8 for these reasons as well. (And 8-processor+ users can
 learn to configure NumCPUs if they have issues.)

 [0]: https://en.wikipedia.org/wiki/Xeon#Overview

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13414#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online