<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">imentinOn Wed, Feb 17, 2016 at 8:29 AM, George Kadianakis <span dir="ltr"><<a href="mailto:desnacked@riseup.net" target="_blank">desnacked@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello there,<br>
<br>
I'm not sure what kind of statistics we get out of the current guard simulator.<br></blockquote><div><br></div><div>The simulation creates a network with 1000 relays (all guards) with 96% of reliability, and using simulated time:</div><div><br></div><div>- every 20 seconds: creates a new circuit each 20 seconds</div><div>- every 2 minutes: updates node connectivity based on its reliability</div><div>- every 20 minutes: removes and add new relays to the network</div><div><br></div><div>By default, we recreate the client (OP) every 2 minutes (which makes it bootstrap, and so on). We can configure to simulate a long lived client, and in this case it fetches a new consensus every hour.<br></div><div><br></div><div>We're also able to run this simulation in multiple network scenarios: fascist firewall, flaky network, evil network, sniper network, down network, and a scenario that switches between these networks). See --help and [1] for explanation of the terms.<br></div><div><br></div><div>Each simulation runs for 30 hours (in simulated time), for a total of 5400 circuits. The time is discrete with increments of 20 seconds. Everything in the simulation happens with no cost to simulated time. We are experimenting to add some time cost to connections (2 seconds for successful, and 4 to failures) just to have some feeling of how it would impact on the algorithms.<br></div><div><br></div><div>We currently have the following metrics:</div><div><br></div><div>- success rate</div><div>- avg bandwidth capacity</div><div>- exposure to guards (how many different guards we connected to) over time (after hour 1, 15, and 30).</div><div>- number of guards we tried until the first successful circuit</div><div>- time until the first successful circuit is built</div><div><br></div><div>A successful circuit is one which we succeeded to find a guard using the algorithm AND we succeeded to connect to it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In general, we are interested in security and performance. For security we are<br>
trying to minimize our exposure to network. For performance, we want to<br>
minimize our downtime when our current guard becomes unreachable or after our<br>
network comes back up.<br>
<br>
Here are some concrete statistics that we could gather in the simulator:<br>
<br>
Security statistics:<br>
- Number of unique guards we connected to during the course of the simulation.<br></blockquote><div><br></div><div>We have this as "exposure after 30 hours".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Time spent connected to lower priority guards while a primary guard was online.<br>
- Time spent connected to lower priority guards while a higher priority guard was online and the network was up.<br></blockquote><div><br></div><div>We don't have these. And also I'm not sure about how we should detect network conditions: we can try to guess from the algorithm or look at which network scenario we are using at the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Performance statistics:<br>
- Time spent cycling through guards.<br>
- Time spent cycling through guards while network is up.<br></blockquote><div><br></div><div>Since time is stopped while we're choosing guards we have to come with a different metric for this. And it also requires detecting the network time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Time spent on dystopic mode.<br>
- Time spent on dystopic mode while the network was utopic.<br></blockquote><div><br></div><div>These should be easy as long as we have defined how to detect the network type.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is it possible to collect those statistics? I'm curious to learn how the<br>
current guard algorithm compares to the new prop259 on those aspects.<br></blockquote><div><br></div><div>We have tooling to generate graphs with success rate and exposure taken from a round of ~500 simulations. I can send them to you when they finish running ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What other stats are important here you think?<br>
</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">We have discussed about counting how many network connections we make over time. For now, we have been comparing success and exposure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I guess we can add these stats, we just need to come up with an approach to determine the network condition.</div><div class="gmail_extra"><br></div><div class="gmail_extra">All the code is in <a href="https://github.com/twstrike/tor_guardsim">https://github.com/twstrike/tor_guardsim</a> (branch develop).</div><div class="gmail_extra"><br></div>1 - doc/stuff-to-test.txt</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><b style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Reinaldo de Souza Jr</b><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"> | Software Developer</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span style="font-family:arial,sans-serif;font-size:13px;color:rgb(102,102,102);background-color:rgb(255,255,255)"><b>Thought</b>Works | </span><a href="http://www.thoughtworks.com/" style="color:rgb(102,102,102);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank">www.thoughtworks.com</a><br><br><div><span style="font-size:12.8px">GPG: <font face="monospace, monospace">EF84 6530 67A5 1559 5554 D8B2 954A 6BEF AF74 ACD7</font></span><br></div></div></div></div></div>
</div></div>