#8494: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it? -------------------------------------------------+------------------------- Reporter: alphawolf | Owner: juga Type: defect | Status: | assigned Priority: Low | Milestone: Tor: | 0.3.5.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-spec, consensus, bandwidth, | Actual Points: MaxAdvertisedBandwidth tor-relay tor-dirauth | needs-insight tor-bwauth | Parent ID: #25925 | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by teor): This spec tells us what a bandwidth generator needs to do to be compatible with the Tor network. Sometimes it is useful to give examples of how sbws or torflow implements a feature. But first we need to say what *any* generator must do. Then we can give examples. So let's start with a sentence like this: If a relay sets MaxAdvertisedBandwidth, generators MUST give it a similar weight to relays with that bandwidth capacity. Replying to [comment:13 juga]: > Bandwidth terms are different in `dir-spec.txt` and the code. > If i'm not mistaken, what is called `bandwidthrate` [0] in the code when creating the descriptor, is called `bandwidth-avg` in `dir-spec.txt` [1]. > And it is calculated as the min(BandwidthRate, MaxAdvertisedBandwidth, RelayBandwidthRate) [2]. > If this is correct, the paragraph to add in `bandwidth-file-spec.txt` could be: > > sbws limits the relay's measured bandwidth to the bandwidth-avg advertised Please say "Bandwidth generators MUST limit the relay's weight based on", not "sbws limits the relay's measured bandwidth to". > in the relay's descriptor, which is the minimum between BandwidthRate, > MaxAdvertisedBandwidth and RelayBandwidthRate in the relay's configuration. > > Though probably the last sentence not needed. I think we need the last sentence, because we need to explain why bandwidth generators need to implement MaxAdvertisedBandwidth. Let's also say: Relays limit their bandwidth when BandwdithRate or RelayBandwidthRate are set. These options reduce a relay's bandwidth capacity. But MaxAdvertisedBandwidth doesn't change the relay's bandwidth capacity. Instead, it asks the bandwidth generator to limit the weight of the relay as if the relay's bandwidth capacity was min(generated bandwidth capacity, MaxAdvertisedBandwidth). Generators SHOULD NOT limit weights based on bandwidth-observed, because that penalises new relays. Then we can give an example of what sbws does: sbws measures relay bandwidths, then caps the measured bandwidth using bandwidth-avg (MaxAdvertisedBandwidth). > If Torflow is using also `bandwidth-avg`, then it could also be added in `bandwidth-file-spec.txt`: > > Torflow does not need to limit the relay's measured bandwidth since it > partions relays to be measured by bandwidth-avg > > Is this correct?. No, Torflow partitions based on: * bandwidth-consensus, if available, or * min(bandwidth-avg, bandwidth-burst, bandwidth-observed), or * 1, if either bandwidth is zero. https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n376 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n459 Torflow also calculates weights based on the descriptor bandwidth to measured bandwidth ratio. So let's say: Torflow partitions relays based on their bandwidth. For unmeasured relays, Torflow uses the minimum of all descriptor bandwidths, including bandwidth-avg (MaxAdvertisedBandwidth) and bandwidth-observed. Then Torflow measures the relays in each partition against each other, which implicitly limits a relay's measured bandwidth to the bandwidths of similar relays. Torflow also generates consensus weights based on the ratio between the measured bandwidth and the minimum of all descriptor bandwidths (at the time of the measurement). So when an operator reduces MaxAdvertisedBandwidth in a relay, Torflow reduces that relay's bandwidth rate. > [0] https://gitweb.torproject.org/tor.git/tree/src/or/router.c#n2370 > [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n427 > [2] https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1693 Once we add these paragraphs, the bandwidth section will be really long. Let's split it up into subsections: No Zero Bandwidths Bandwidth Aggregation Bandwidth Scaling MaxAdvertisedBandwidth -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8494#comment:15> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs