[tor-dev] Some information about Tor relays

[Liu, Zhuotao]

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 at gmail.com]
Sent: Friday, August 26, 2016 1:15
To: tor-dev at 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.