I've made some good progress on a bare bones, doesn't-do-more-than-it- has-to bandwidth scanner. It can generate output just like torflow[0].
We need to decide on how to scale results that come from different measurement systems. The simple, don't-make-it-harder-than-it-has-to-be idea is (quote [1], see [2]):
Express each weight as a proportion of the total, and multiply by
some agreed total (e.g. for the current network it would have to be the total of the consensus weight, but within some limited range to avoid unbounded growth).
So we need to:
1. Decide on a large total.
I suggest 50 million to start the conversation (bike shedding) based on that being close to the current total consensus weight so relay operators won't see a large (though inconsequential) change.
2. Have all the torflow operators switch to this new method.
Ouch. I wouldn't mind being told I'm wrong about this step being necessary.
3. Find all the places that hint at consensus weight being directly comparable to bandwidth (such as [3]) and change the wording.
Matt
[0]: https://paste.debian.net/1015409/ [1]: https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rom e/Notes/BandwidthAuthorityRequirements#Scaling [2]: https://trac.torproject.org/projects/tor/ticket/25459 [3]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2290
After #1 is decided, we can convert past bwauth data, can't we? If it's helpful I can (at some point) compare your data against historical (converted) data as I've been doing: https://tomrittervg.github.io/bwauth-tools/
-tom
On 18 March 2018 at 20:22, Matt Traudt pastly@torproject.org wrote:
I've made some good progress on a bare bones, doesn't-do-more-than-it- has-to bandwidth scanner. It can generate output just like torflow[0].
We need to decide on how to scale results that come from different measurement systems. The simple, don't-make-it-harder-than-it-has-to-be idea is (quote [1], see [2]):
Express each weight as a proportion of the total, and multiply by
some agreed total (e.g. for the current network it would have to be the total of the consensus weight, but within some limited range to avoid unbounded growth).
So we need to:
- Decide on a large total.
I suggest 50 million to start the conversation (bike shedding) based on that being close to the current total consensus weight so relay operators won't see a large (though inconsequential) change.
- Have all the torflow operators switch to this new method.
Ouch. I wouldn't mind being told I'm wrong about this step being necessary.
- Find all the places that hint at consensus weight being directly
comparable to bandwidth (such as [3]) and change the wording.
Matt
e/Notes/BandwidthAuthorityRequirements#Scaling [2]: https://trac.torproject.org/projects/tor/ticket/25459 [3]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2290 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
Matt, Juga, Nick and I discussed an alternative scaling scheme on #tor-dev during the patch party.
On 19 Mar 2018, at 12:22, Matt Traudt pastly@torproject.org wrote:
- Decide on a large total.
I suggest 50 million to start the conversation (bike shedding) based on that being close to the current total consensus weight so relay operators won't see a large (though inconsequential) change.
Calculate the average consensus weight per relay. And make it a consensus parameter. Currently, it's about 7500.
bwauths scale results so that the total measured bandwidth is approximately 7500 * (the number of relays they have measured).
This scales their results so they are similar to the current torflow bwauths. (The current bwauths have total measured bandwidths between 35 million and 70 million. Using this scaling scheme, a bwauth that measured 7000 relays would have a total bandwidth of 52.5 million.)
This scheme also allows a bwauth to scale and report partial results: if it has measured half the network, it scales to 25 million.
- Have all the torflow operators switch to this new method.
Ouch. I wouldn't mind being told I'm wrong about this step being necessary.
Under this alternative scheme, if the unscaled bwauths average relay weight changes, we change the consensus parameter.
So we don't need to change torflow.
See this pad for our notes and calculations: https://pad.riseup.net/p/n3mEulClf6ZV
T
-
Matt Traudt -
teor -
Tom Ritter