<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi,</div><div><br></div><div>On 4 Mar 2018, at 02:37, Florentin Rochet <<a href="mailto:florentin.rochet@uclouvain.be">florentin.rochet@uclouvain.be</a>> wrote:<br><br></div><blockquote type="cite"><div><span>I have a few questions about convergence/divergence of weights, but</span><br><span>maybe we could take advantage of the meeting in Rome to discuss this avenue?</span><br></div></blockquote><div><br></div><div>I was wrong. The current network doesn't attempt to converge</div><div>on a stable set of weights, because the feedback loop is too</div><div>weak. So I think we can disregard this question.</div><br><blockquote type="cite"><div><span>On 28/01/18 23:40, teor wrote:</span><br><blockquote type="cite"><span><skip></span><br></blockquote><blockquote type="cite"><span>I'm going to re-ask this questions, in light of the extra middle load from</span><br></blockquote><blockquote type="cite"><span>Tor2web clients:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Does the waterfilling proposal make excessive load on middles worse, by</span><br></blockquote><blockquote type="cite"><span>allocating more middle weight to higher capacity relays?</span></blockquote><span></span><br><span>If bwauths overestimate top relays, or if we reach some soft limit, yes.</span><br><span>But the reverse would be true too: if we have excessive load of guards,</span><br><span>then this proposal will make things better.</span><br></div></blockquote><div><br></div><div>I'm not sure that this statement is true.</div><div><br></div><div>Rather:</div><div>If we have excessive load on middles, then top relays will suffer more.</div><div>If we have excessive load on guards, then lower relays will suffer more.</div><div><br></div><div>You can actually lose both ways when you unbalance network load.</div><div>It depends on the type of load.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>In particular, connections are limited by file descriptors, and file</span><br></blockquote><blockquote type="cite"><span>descriptor</span><br></blockquote><blockquote type="cite"><span>limits typically don't scale with the bandwidth of the relay. As far</span><br></blockquote><blockquote type="cite"><span>as I can tell,</span><br></blockquote><blockquote type="cite"><span>waterfilling would have directed additional Tor2web traffic to large</span><br></blockquote><blockquote type="cite"><span>guards.</span><br></blockquote><blockquote type="cite"><span>It would have brought down my guards faster, and made it much harder</span><br></blockquote><blockquote type="cite"><span>for me</span><br></blockquote><blockquote type="cite"><span>to keep them up.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If we had implemented waterfilling before this attack, would it have</span><br></blockquote><blockquote type="cite"><span>lead to</span><br></blockquote><blockquote type="cite"><span>cascading failures on our top guards? They would have been carrying</span><br></blockquote><blockquote type="cite"><span>significantly more middle load, and mine barely managed to cope.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>Probably yes, but they would also carrying less load at the guard</span><br><span>position from normal Tor users. In normal condition, that should tie. In</span><br><span>a DDoS situation, I would say we face difficulties no matter what we do.</span><br></div></blockquote><div><br></div><div>I think that unbalanced networks tend to suffer more during a DDoS.</div><br><blockquote type="cite"><font color="#00afcd">…</font><br><blockquote type="cite"><span><skip></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Bandwidth-weights and measurements (consensus weights) are two different</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>things that solve 2 different problems. So, we can work independently on</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>improving measurements (like what is currently done with bwscanner) and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>improving Tor's balancing (bandwidth-weights) with this proposal.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I don't think this is realistic.</span><br></blockquote><blockquote type="cite"><span>There is always contention for shared resources.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Integrating and testing new code, and monitoring its effects, will</span><br></blockquote><blockquote type="cite"><span>take effort from</span><br></blockquote><blockquote type="cite"><span>the teams I mentioned above. This takes away from the urgent work of</span><br></blockquote><blockquote type="cite"><span>fixing the</span><br></blockquote><blockquote type="cite"><span>bandwidth authority system. Which also takes effort from the Core Tor and</span><br></blockquote><blockquote type="cite"><span>Metrics teams.</span><br></blockquote><span></span><br><span>Right, totally agree that the first focus should be on bwauths. Could we</span><br><span>try to make plan, or at least move this proposal into the todo list?</span><br></blockquote><div><br></div>While we're talking priorities, I would also prioritise fixing the<div>guardfraction code over this proposal. When we work out how to test</div><div>guardfraction, we can use similar tests for this proposal.<div><div><br></div>At the moment, this proposal is "OPEN", because it is still under</div><div>discussion:<div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt#n148">https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt#n148</a><br><div><br></div><div>If you want to move it to "ACCEPTED":</div><div>* answer as many open questions as you can</div><div>* reply to this thread with a link to the final version of the proposal</div><div>* we will open a ticket for the proposal</div><div>* we will schedule a proposal meeting on IRC to discuss the proposal</div><div><br></div><div>Please be aware:</div><div>* It sometimes takes years for research to make it into Tor.</div><div>* Some research is good research, but it is not a good fit for the public</div><div> Tor network.</div><div><br></div><div>T<br><div><br></div></div></div></div></div></body></html>