Does sbws need a node cap?

Torflow caps individual nodes at 5% of the consensus weight.

When Tor gets better multithreading, we might need to implement a cap.

https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n44

Edit: fix short sentence.

changed milestone to %sbws: 1.0.x-final

added component::core tor/sbws milestone::sbws: 1.0.x-final owner::juga parent::27107 priority::medium resolution::implemented sbws-1.0-must-closed-moved-20181128 severity::normal status::closed type::enhancement labels

Since we're using observed bandwidths, we must limit the maximum node bandwidth.

5% is ok, but 1% might be better, because the largest relay is only 0.5%.

Trac:
Description: Torflow caps individual nodes at 5% of the consensus weight.

When Tor gets better multithreading, https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n44

to

Torflow caps individual nodes at 5% of the consensus weight.

When Tor gets better multithreading, we might need to implement a cap.

https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n44

Edit: fix short sentence.

Trac:
Milestone: sbws 1.1 to sbws 1.0 (MVP must)
Parent: N/A to #27107 (moved)

Trac:

sbws capped to 0.05 * sum all the relays' bandwidth

I think (but i'm not sure), that tot_net_bw [0] is not being applied. Also, since new_bw it's used in the non-pid part as the final value to write in the file, i thought tot_net_bw it just the sum of all the final relays' bandwidth that are going to be written in the file.

In previous experiments, i capped to 0.05 * sum final bandwidths, and the result makes sense, see the attchemnt.

[0] https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n758

Can you make the dots smaller please? I'd like to be able to at least somewhat see the blue dots behind the orange ones.

pyplot.scatter(..., s=5, ...)

https://matplotlib.org/api/_as_gen/matplotlib.pyplot.scatter.html

(I don't know if 5 is a good size. Trial and error is required to find a good size)

Replying to teor:

Since we're using observed bandwidths, we must limit the maximum node bandwidth.

5% is ok, but 1% might be better, because the largest relay is only 0.5%.

sbws needs to cap, so that relays can't gain too much bandwidth by changing their observed bandwidths. This is a security requirement. If torflow doesn't do it, that's a bug in torflow.

Replying to juga:

I think (but i'm not sure), that tot_net_bw [0] is not being applied.

It looks like the NODE_CAP is applied unconditionally in torflow: https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n778

But from the graph, there doesn't seem to be a cap on torflow's bandwidths.

Also, since new_bw it's used in the non-pid part as the final value to write in the file, i thought tot_net_bw it just the sum of all the final relays' bandwidth that are going to be written in the file.

In previous experiments, i capped to 0.05 * sum final bandwidths, and the result makes sense, see the attchemnt.

Great!

[0] https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/aggregate.py#n758

The cap must be configurable, so that we can turn it off in test networks, or adjust it if it is a problem.

Implementation is ready, but #27135 (moved), #27386 (moved) need to be fixed first and i'll wait for #27398 (moved) to be fixed too to make PRs

Blocked by #27398 (moved). Implementented in https://github.com/juga0/simple-bw-scanner/commits/dev

Trac:
Status: new to needs_review

Implemented in https://github.com/torproject/sbws/pull/254.

Trac:
Status: needs_review to accepted
Owner: N/A to juga

Removed child #27363 (moved) since it does not need to be implemented for the MVP

Trac:
Resolution: N/A to implemented
Status: accepted to closed

Move all closed sbws 1.0 must tickets to sbws 1.0.x-final

Trac:
Milestone: sbws 1.0 (MVP must) to sbws: 1.0.x-final
Keywords: N/A deleted, sbws-1.0-must-closed-moved-20181128 added

closed

mentioned in issue #27337 (moved)

mentioned in issue #27338 (moved)

mentioned in issue #27363 (moved)

mentioned in issue #27690 (moved)

mentioned in issue tpo/core/tor#27690 (closed)