Thanks for your notes.
Besides these pretty expensive streams, we want to have a general estimation about the computation capability about Tor relays. The concern is when a botnet abuses Tor as its primary C&C channel, they would create tons of circuits through Tor. But they many not run any expensive streams, as what we saw in Aug 2013. So the general question is how many (basic) circuits can Tor relays hold before their computation saturates. Or in other words, when a botnet switches to use Tor as C&C channel, will it be a denial of service?
Thanks, Zhuotao
________________________________________ From: grarpamp [grarpamp@gmail.com] Sent: Friday, August 26, 2016 1:15 To: tor-dev@lists.torproject.org Cc: Liu, Zhuotao Subject: Re: [tor-dev] Some information about Tor relays
On Fri, Aug 26, 2016 at 01:42:38AM +0000, Liu, Zhuotao wrote:
We hope to have an estimate about computation capacity of Tor relays. For instance, how many circuits a relay can maintain when its CPU is driven to about 100%? On average, how many circuits are maintained by a busy guard and what the CPU utilization is. These kinds of information would be really helpful.
I used to report CPU exhaustion when pushing 15-25 high circuit flux application streams in parallel through a client and thus its guards. To gather and characterize current limitations in an operational context you might want to deploy a guard at your university and run some clients through it, instrumenting various things, until something saturates.
I'd be interested in seeing estimates of what the net change in network usable CPU headroom [1] is when adding relays using certain fixed ratios of their own cpu/circuits and or cpu/clients and or cpu/bandwidth capacities.
Perhaps in other words... we roughly know how a clients stream over 3 or 6 hops might consume an additional 1Gbps added to the network. But what does adding its CPU to the network get us... and effect of clients/net on that. And with each box added, are we adding the right ratio of CPU and bandwidth, do we need a knob there to ensure optimum balanced benefit to the net, or is it better to leave it float.
[1] Left over for network meta purposes like circuit construction, directory services, consensus, parametric pathing computation, etc.