<div dir="auto">I'm happy to run a sbws alongside my torflow. It will let us compare bw numbers apples to apples too. My only difficulty is being unable to spend significant time to diagnose why it doesn't work, if it doesn't work.<div dir="auto"><br></div><div dir="auto">If it's at the point I should give it a shot, point me at some instructions :)</div><div dir="auto"><br></div><div dir="auto">-tom</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 12, 2018, 7:38 PM Matt Traudt <<a href="mailto:pastly@torproject.org">pastly@torproject.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">See below for the pad notes. Next meeting is scheduled 19 April 2018 at<br>
2200 UTC in #tor-meeting. (This one was held in #tor-dev, but we should<br>
use meetbot).<br>
<br>
-------------<br>
<br>
<br>
Simple Bandwidth Scanner meeting 12 April 2018<br>
<br>
#### Updates/Status messages ####<br>
<br>
pastly:<br>
What's on my plate? <- doesn't have to be all in your plate :P<br>
- Test coverage getting closer to 100%<br>
- Immediate future: switch to standard python logging module, which<br>
is quite good<br>
- Improving documentation<br>
- Checking results against torflow<br>
- Monitor CPU of sbws client/server<br>
- +1 on considering asyncio<br>
- See how chutney generates random strings<br>
- Run testnet authority<br>
- Reach out to current auths about running sbws/torflow and adding<br>
me as an auth<br>
<br>
juga:<br>
- open/close PRs/issues about things to improve in doc, refactor<br>
code, etc..., but not changing functionality<br>
- re. doc:<br>
- thought to update sbws spec (or create other) to doc<br>
differences with Torflow, not sure it's useful<br>
- i'd document further some of the classes/functions (as<br>
measure_relay)<br>
- code doc vs spec (see below)<br>
- find box to run other sbws, bwauth also in testnet?<br>
<br>
## Topic: what is still missing for milestone 1? (aka 1st release, v1.0.0)<br>
- could we create all tickets needed to achive it?<br>
- maybe previous list is enough?<br>
Missing:<br>
- A consensus parameter stating the scaling factor<br>
- sbws config option to set fallback if no consensus param<br>
- `sbws generate` code to use the consensus param<br>
<br>
-<br>
<a href="https://stem.torproject.org/api/descriptor/networkstatus.html#stem.descriptor.networkstatus.NetworkStatusDocumentV3" rel="noreferrer noreferrer" target="_blank">https://stem.torproject.org/api/descriptor/networkstatus.html#stem.descriptor.networkstatus.NetworkStatusDocumentV3</a><br>
<br>
- Correlation coefficient on comparision graphs<br>
<br>
<br>
<br>
<br>
## Topic: comparing to torflow<br>
tah<br>
- Can we make the test sbws deployment a little bigger?<br>
- What else needs to be compared?<br>
<br>
teor: actually running it in a voting network, to check the feedback<br>
loop (if any) the scaling<br>
<br>
- Conclusions after comparing?<br>
- what we could think to change/improve after comparing?<br>
<br>
Graphs pastly can explain:<br>
- sbws vs moria, sorted by sbws:<br>
<a href="https://share.riseup.net/#-W_zqcv-08AX4SnOgTatUw" rel="noreferrer noreferrer" target="_blank">https://share.riseup.net/#-W_zqcv-08AX4SnOgTatUw</a><br>
- sorted by moria: <a href="https://share.riseup.net/#URXp6NccZHEhOPFJQcfO4w" rel="noreferrer noreferrer" target="_blank">https://share.riseup.net/#URXp6NccZHEhOPFJQcfO4w</a><br>
<br>
<br>
teor: the correlation seems good here<br>
If we're going to use these charts to compare, please compare two<br>
existing bwauths<br>
See: <a href="https://share.riseup.net/#lPGcIrgHp3ftnvTHUKqOKg" rel="noreferrer noreferrer" target="_blank">https://share.riseup.net/#lPGcIrgHp3ftnvTHUKqOKg</a> (but ignore the<br>
sbws-scaled line, it's wrong wrong wrong)<br>
<br>
<br>
## Topic: convincing people to run sbws<br>
juga: maybe something to do when 1st sbws release?<br>
pastly: yes, probalby. unless we need to convince testnet people <- ah,<br>
right i was thinking on the Tor net<br>
<br>
<br>
## Topic: status of open sourcing sbws<br>
- No real update. Time is still passing.<br>
<br>
## Topic: specifications<br>
<br>
torflow/BwAuthority:<br>
<a href="https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt" rel="noreferrer noreferrer" target="_blank">https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt</a>,<br>
<a href="https://ohmygodel.com/publications/peerflow-popets2017.pdf" rel="noreferrer noreferrer" target="_blank">https://ohmygodel.com/publications/peerflow-popets2017.pdf</a> has a section<br>
that also makes a nice summary<br>
sbws:<br>
<a href="https://github.com/pastly/simple-bw-scanner/blob/master/docs/source/specification.rst" rel="noreferrer noreferrer" target="_blank">https://github.com/pastly/simple-bw-scanner/blob/master/docs/source/specification.rst</a><br>
(ask Pastly for access)<br>
bwscanner: no spec, but reading<br>
<a href="https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/circuit.py#L45" rel="noreferrer noreferrer" target="_blank">https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/circuit.py#L45</a><br>
it looks like a Torflow clone <- almost :)<br>
<br>
We need a spec for the v3bw file that tor reads (in torspec/dir-spec.txt)<br>
We need a spec for bwauth migration, including acceptance criteria for<br>
new bwauth implementations<br>
Scanners should have their own detailed design documents<br>
<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank" rel="noreferrer">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div>