Thanks for that. It's interesting to have that data visualized.<br><br>
<div><span class="gmail_quote">On 12/16/06, <b class="gmail_sendername">Mike Perry</b> <<a href="mailto:mikepery@fscked.org">mikepery@fscked.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">While testing the latest relese of my Tor scanner, I decided to do a<br>study on circuit reliability and how long it takes to construct a
<br>circuit then fetch the html of <a href="http://tor.eff.org">http://tor.eff.org</a>, and also to<br>fetch <a href="http://tor.eff.org">http://tor.eff.org</a> via that same constructed circuit.<br><br>Using tor-0.1.2.4 (actually SVN r9067), I sorted the routers by their
<br>bandwidth capacity, divided them up into 15% segments of the network<br>from 0 to 90, and for each segment timed 250 circuits as well as used<br>the new failure tracking abilities of my scanner to track the failure<br>
rates of nodes as well as the failure reasons for circuits and<br>streams.<br><br>Times are seconds:<br><br>RANGE 0-15 250 build+fetches: avg=20.89, dev=31.23<br>RANGE 0-15 250 fetches: avg=3.66, dev=2.69<br><br>RANGE 15-30 250 build+fetches: avg=
33.44, dev=47.01<br>RANGE 15-30 250 fetches: avg=7.28, dev=12.86<br><br>RANGE 30-45 250 build+fetches: avg=81.47, dev=79.55<br>RANGE 30-45 250 fetches: avg=12.66, dev=38.63<br><br>RANGE 45-60 250 build+fetches: avg=63.56, dev=
67.56<br>RANGE 45-60 250 fetches: avg=7.51, dev=12.80<br><br>RANGE 60-75 250 build+fetches: avg=40.85, dev=42.76<br>RANGE 60-75 250 fetches: avg=10.13, dev=11.28<br><br>RANGE 75-90 250 build+fetches: avg=48.87, dev=56.11<br>
RANGE 75-90 250 fetches: avg=6.82, dev=7.48<br><br><br>As you can see, the high bandwidth nodes in 0-15% are much quicker<br>than the rest both at using existing circuits and at building new<br>ones. My guess is that the circuit build speed increase is likely due
<br>to the fact that running a fast node requires a fast machine to be<br>able to do all the crypto, and thus crypto-intensive circuit builds<br>execute faster on these nodes.<br><br>The rest of the results for circuit construction and speed seem only
<br>loosely tied to bandwidth, however. Probably other factors like<br>network connection and stability come into play there. A few bad nodes<br>can slow those averages down a lot, as is hinted at by the large std<br>deviation in some of the classes.
<br><br>So what of the failure rates and reasons then? Lets have a look at the<br>FAILTOTALS line from each class:<br><br>0-15.naive_fail_rates: FAILTOTALS 131/473 54+6/603 OK<br>15-30.naive_fail_rates: FAILTOTALS 224/750 135+40/726 OK
<br>30-45.naive_fail_rates: FAILTOTALS 559/1221 130+29/737 OK<br>45-60.naive_fail_rates: FAILTOTALS 273/845 138+22/752 OK<br>60-75.naive_fail_rates: FAILTOTALS 140/592 85+33/678 OK<br>75-90.naive_fail_rates: FAILTOTALS 187/637 76+18/656 OK
<br><br>By looking at the README for the scanner, we see the format of these<br>lines is:<br><br>250 FAILTOTALS CIRCUIT_FAILURES/TOTAL_CIRCUITS DETACHED+FAILED/TOTAL_STREAMS<br><br>So it looks that nodes in the 30-45% range seemed to have a good deal
<br>higher rate of circuit failure than the rest (if you're wondering, the<br>overall circuit failure rate is 33%).<br><br>Looking at the top of the 30-45.naive_fail_rates file shows us a<br>handful of nodes with slightly higher failure rates than normal, but
<br>several of the other classes have a few bad nodes also. So why was<br>this class so much slower?<br><br>It turns out if you look at the naive_fail_reasons file, the largest<br>portion of failures comes from CIRCUITFAILED:TIMEOUT reason:
<br><br>250 REASONTOTAL 522/1277<br><br>or 522 timeout failures out of all the total node failures. Note that<br>reason-based failure counting and reason totals are node-based, where<br>as the FAILTOTALS lines just count circuits and streams, hence the
<br>large number there.<br><br>In general, the most common failure reasons were circuit timeouts,<br>stream timeouts, and OR connection closed (TCP connections between<br>nodes mysteriously dying or failing to open).<br><br>
Here's the top failure reasons by class. When there are 3 reason terms<br>paired together, the reason was reported from an upstream node and not<br>deduced locally.<br><br>0-15:<br>1. CIRCUITFAILED:OR_CONNECTION_CLOSED (174/322 node failures)
<br>2. CIRCUITFAILED:TIMEOUT (72/322 node failures)<br>3. STREAMDETACHED:TIMEOUT (41/322 node failures)<br><br>15-30:<br>1. CIRCUITFAILED:OR_CONN_CLOSED (182/623)<br>2. CIRCUITFAILED:DESTROYED:OR_CONN_CLOSED (116/623)<br>
3. CIRCUITFAILED:TIMEOUT (124/623)<br><br>30-45:<br>1. CIRCUITFAILED:TIMEOUT (522/1277)<br>2. CIRCUITFAILED:OR_CONN_CLOSED (396/1277)<br>3. CIRCUITFAILED:DESTROYED:OR_CONN_CLOSED (192/1277)<br><br>45-60:<br>1. CIRCUITFAILED:TIMEOUT (306/706)
<br>2. CIRCUITFAILED:OR_CONN_CLOSED (164/706)<br>3. STREAMDETACHED:TIMEOUT (138/706)<br>4. CIRCUITFAILED:DESTROYED:OR_CONN_CLOSED (72/706)<br><br>60-75:<br>1. CIRCUITFAILED:TIMEOUT (112/398)<br>2. CIRCUITFAILED:OR_CONN_CLOSED (110/398)
<br>3. STREAMDETACHED:TIMEOUT (85/398)<br>4. CIRCUITFAILED:DESTROYED:OR_CONN_CLOSED (56/398)<br><br>75-90:<br>1. CIRCUITFAILED:TIMEOUT (216/468)<br>2. CIRCUITFAILED:OR_CONN_CLOSED (96/468)<br>3. STREAMDETACHED:TIMEOUT (76/468)
<br>4. CIRCUITFAILED:DESTROYED:OR_CONN_CLOSED (56/468)<br><br><br>So if you total the two OR_CONN_CLOSED (local and remote), you see<br>that for some reason node to node TCP connections are fairly<br>unreliable and prone to being closed (or are difficult to
<br>open/establish?). This is strange...<br><br>I should also note that stream failure reasons are only counted for<br>the exit node, where as circuit failure reasons are counted for 2<br>nodes - the last successful hop and the first unsuccesful one. So in
<br>effect, the STREAMDETACHED reason really is 2x more common than in<br>those lists. On the other hand, it is mostly alleviated by making<br>compute_socks_timeout() always return 15 (this was not done for this<br>study, however).
<br><br><br>Well that's about all the detail I have time to go into right now. The<br>complete results are up at<br><a href="http://fscked.org/proj/minihax/SnakesOnATor/speedrace.zip">http://fscked.org/proj/minihax/SnakesOnATor/speedrace.zip
</a><br><br>As soon as I finish polishing up my README and change log, I will put<br>up the new release of SoaT itself up. Should be by sometime today.<br><br><br>--<br>Mike Perry<br>Mad Computer Scientist<br><a href="http://fscked.org">
fscked.org</a> evil labs<br></blockquote></div><br>