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.
Designs
- Show closed items
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- teor changed milestone to %sbws: 1.0.x-final in legacy/trac
changed milestone to %sbws: 1.0.x-final in legacy/trac
- teor added component::core tor/sbws in Legacy / Trac milestone::sbws: 1.0.x-final in Legacy / Trac owner::juga in Legacy / Trac parent::27107 in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac sbws-1.0-must-closed-moved-20181128 in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac type::enhancement in Legacy / Trac labels
added component::core tor/sbws in Legacy / Trac milestone::sbws: 1.0.x-final in Legacy / Trac owner::juga in Legacy / Trac parent::27107 in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac sbws-1.0-must-closed-moved-20181128 in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac type::enhancement in Legacy / Trac 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 legacy/trac#27107 (moved)I think (but i'm not sure), that
tot_net_bw
[0] is not being applied. Also, sincenew_bw
it's used in the non-pid part as the final value to write in the file, i thoughttot_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 thoughttot_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 legacy/trac#27135 (moved), legacy/trac#27386 (moved) need to be fixed first and i'll wait for legacy/trac#27398 (moved) to be fixed too to make PRs
Blocked by legacy/trac#27398 (moved). Implementented in https://github.com/juga0/simple-bw-scanner/commits/dev
Trac:
Status: new to needs_reviewImplemented in https://github.com/torproject/sbws/pull/254.
Trac:
Status: needs_review to accepted
Owner: N/A to jugaRemoved child legacy/trac#27363 (moved) since it does not need to be implemented for the MVP
Trac:
Resolution: N/A to implemented
Status: accepted to closed- Trac closed
closed
- juga mentioned in issue legacy/trac#27337 (moved)
mentioned in issue legacy/trac#27337 (moved)
- juga mentioned in issue legacy/trac#27338 (moved)
mentioned in issue legacy/trac#27338 (moved)
- juga mentioned in issue legacy/trac#27363 (moved)
mentioned in issue legacy/trac#27363 (moved)
- juga mentioned in issue legacy/trac#27690 (moved)
mentioned in issue legacy/trac#27690 (moved)
- Trac mentioned in issue tpo/core/tor#27690 (closed)
mentioned in issue tpo/core/tor#27690 (closed)
- Trac moved from legacy/trac#27336 (moved)
moved from legacy/trac#27336 (moved)
- Trac removed 1 deleted label
removed 1 deleted label