Bandwidth Scanner

Notes presented during the session:


The overall goal of bandwidth weights is to balance load so that each stream has approximately the same performance, regardless of the relays chosen by the client.

In 200?, Mike measured the Tor network. He partitioned relays by their self-reported bandwidth, then measured their stream capacity.

The highest-bandwidth relays had much more capacity than the lower-bandwidth relays. So we decided to re-balance network load towards high-bandwidth relays.

Each relay's self-reported bandwidth is scaled by the ratio between its measured bandwidth, and the network average measured bandwidth.

Bandwidth Distribution

The distribution of relay bandwidths is exponential. This was our original goal when we wrote torflow.

sbws can match Torflow's bandwidths.

If we deploy a network full of sbws, we think it will scale like Torflow does.

Scanner Transition

sbws is ready to install using a python virtual environment.

The Debian package has been patched and needs some testing.

As we deploy sbws instances, we should check:

  • client performance: onionperf is the same or better, with the same or less variance
  • bandwidth map (across the network, and per authority?) on relay search is the same
  • relay bandwidth history graph is stable (and doesn't go down)

Next Steps at this Meeting

Metrics: getting data from sbws

Bwauth operators: talk through deployment issues

Metrics, scanner, research: How to decide if sbws is working or not?

Future Work

Let's deploy sbws first. Then we can make it different to Torflow.

Do we need a better distribution of relay bandwidths?

Should we give less weight to low-bandwidth relays, so that they can handle random variation better?

Last modified 2 years ago Last modified on Oct 9, 2018, 12:27:40 PM