[metrics-team] Measuring bwscanner changes

[teor]

(Re-sending, because I wasn't subscribed to the list.)

On 6 June 2017 at 18:02, micah anderson <micah at riseup.net> wrote:
> 
> Hi all,
> 
> We have been working on making some changes in bwscanning, and we
> *think* that the changes are going to improve measurements on the
> network as a whole, but this is only a guess and we would like to find
> out if there are any ways to determine with some actual metrics what
> kind of affects the changes do actually have.


Taking a step back:

What is the goal of Tor bandwidth measurement?
What are we trying to optimise?

I think we want clients to have a good experience of using Tor.

This means:
* low latency for interactive sessions (IRC, SSH, web pages), and
* high throughput for bulk transfers (software downloads, documents).

I think the best measurement for this is the bandwidth-delay product
of the average Tor circuit and exit TCP connection. Which is good,
because that's what the bandwidth authorities are measuring.

(Also, since 0.2.9.8, Tor relays try to prioritise interactive
sessions over bulk transfers. And KIST should make that even better.)

But we also want to optimise the the overall shape of the network,
which is a much harder problem. It affects usability, security, and
utilisation. (And it makes relay operators sad when we get it wrong.)

I added a section about Tor's bandwidth measurement goals to:

https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements

Please feel free to edit or give feedback.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20170611/03d56569/attachment.sig>