Re: [tor-dev] Scaling bandwidth scanner results

[Tom Ritter]

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  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:
>
> 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
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Scaling bandwidth scanner results

[Matt Traudt]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev