<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi,</div><div dir="ltr"><br>On 3 Jun 2019, at 17:48, Roger Dingledine <<a href="mailto:arma@torproject.org">arma@torproject.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>On Sun, Jun 02, 2019 at 10:43:14PM +1000, teor wrote:</span><br><blockquote type="cite"><span>Let's deploy sbws to half the bandwidth authorities, wait 2 weeks, and</span><br></blockquote><blockquote type="cite"><span>see if exit bandwidths improve.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>We should measure the impact of this change using the tor-scaling</span><br></blockquote><blockquote type="cite"><span>measurement criteria. (And we should make sure it doesn't conflict</span><br></blockquote><blockquote type="cite"><span>with any other tor-scaling changes.)</span><br></blockquote><span></span><br><span>Rolling out more sbws measurers sounds good to me.</span><br><span></span><br><span>But, maybe I haven't been following, but isn't the first plan for sbws</span><br><span>to replace torflow but have identical behavior? And then we can work on</span><br><span>changing it to have better behavior?</span></div></blockquote><div><br></div><div>No, we fixed some obvious torflow bugs and design flaws.</div><div><br></div><div>Here are some details:</div><div><br></div><div>Let's talk engineering tradeoffs.</div><div><br></div><div>sbws had a few conflicting goals:</div><div>* create a modern bandwidth scanner implementation</div><div>* produce results that are similar to torflow</div><div>* be ready to deploy in 2019</div><div><br></div><div>Here's how we resolved those tradeoffs:</div><div><span style="background-color: rgba(255, 255, 255, 0);">* use modern designs, libraries, and protocols when building sbws</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">* compare sbws results against torflow, and identify any issues:</span></div><div> * when torflow is obviously wrong, do something better in sbws</div><div> * when sbws is obviously wrong, log a bug against sbws, and triage it</div><div> * when the results differ by a small amount, accept that difference</div><div><br></div><div>See these tickets for more details:</div><div><a href="https://trac.torproject.org/projects/tor/ticket/27339">https://trac.torproject.org/projects/tor/ticket/27339</a></div><div><a href="https://trac.torproject.org/projects/tor/ticket/27107">https://trac.torproject.org/projects/tor/ticket/27107</a></div><div><br></div><div>Here are some network health checks we are doing as we deploy sbws:</div><div><a href="https://sbws.readthedocs.io/en/latest/monitoring_bandwidth.html">https://sbws.readthedocs.io/en/latest/monitoring_bandwidth.html</a></div><div><br></div><div>Here are some FAQs about the design, and the bandwidth file spec:</div><div><a href="https://sbws.readthedocs.io/en/latest/faq.html">https://sbws.readthedocs.io/en/latest/faq.html</a></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt">https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt</a></div><div><br></div><div>It would be great to have more design documentation, but keeping that</div><div>documentation up to date is a lot of work. And we needed to deliver</div><div>working code, too.</div><br><blockquote type="cite"><div dir="ltr"><span>I ask because in that case switching to more sbws measurers should not</span><br><span>cause the exit bandwidths to improve, until we then change the measurers</span><br><span>to measure better.</span></div></blockquote><div><br></div>One of the design flaws that we fixed was torflow's "scanner partitions".<div><br></div><div>Relays can get stuck in a slow torflow scanner partition, and never improve</div><div>their measurements.</div><div><br></div><div>But in sbws, each relay is measured against a random faster relay.</div><div>sbws tries to choose relays that are at least 2x faster than the target.</div><div><br></div><div>So some stuck relay bandwidths should improve under sbws, as long as</div><div>we have enough sbws instances (about half, I think).</div><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">That said, there are still some bugs in sbws. Some of those bugs were</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">copied from </span><span style="background-color: rgba(255, 255, 255, 0);">torflow. Others are new bugs. sbws has detailed diagnostics</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);">that will help us chase down and fix these bugs.</span></div><div><br></div><div>And we can also make design changes. But let's stabilise sbws first, and</div><div>fix any high-impact bugs.</div><div><br><div>T</div></div></body></html>