[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8494 [Core Tor/Tor]: Does MaxAdvertisedBandwidth do anything useful and if not, can we deprecate it?

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs