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

[Tor Bug Tracker & Wiki]

#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 juga):

 Replying to [comment:15 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.

 ACK

 >
 > 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].

 Is this correct or i'm mistaken?

 > > 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 measured bandwidth was min(measured bandwidth,
 MaxAdvertisedBandwidth).
 >     Generators SHOULD NOT limit weights based on bandwidth-observed,
 because that penalises new relays.
 >

 In all your suggestions, i would not use the word `weight` to do not
 confuse it with the `weight` generated in the consensus.
 I also would not use the word `capacity` to do not confuse it with the
 `bandwidth-observed` in the descriptors that it's called
 `bandwidthcapacity` in the code and comes from relays' self-tests.


 > Then we can give an example of what sbws does:
 >
 >     sbws measures relay bandwidths, then caps the measured bandwidth
 using bandwidth-avg (MaxAdvertisedBandwidth).

 as mentioned above, isn't bandwidth-avg = min(MaxAdvertisedBandwidth,
 MaxAdvertisedBandwidth, RelayBandwidthRate)?

 > > 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)

 as mentioned above, isn't bandwidth-avg = min(MaxAdvertisedBandwidth,
 MaxAdvertisedBandwidth, RelayBandwidthRate)?

 > 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 the
 MaxAdvertisedBandwidth for a relay, Torflow reduces that relay's measured
 bandwidth.
 >

 So, sumarizing your 4 sentences suggestions with my comments, plus what
 you clarify about Torflow:

     Bandwidth generators MUST limit the relays' measured bandwidth based
 on the descriptors' bandwidth-avg.
     Descriptors' bandwidth-avg is the minimum between BandwidthRate,
 MaxAdvertisedBandwidth and RelayBandwidthRate in the relays'
 configuration, when these options are set.
     Generators SHOULD NOT limit measured bandwidths based on descriptors'
 bandwidth-observed, because that penalises new relays.
     When generators does not limit the relays' measured bandwidth on the
 descriptors' bandwidth-avg, they MUST give a similar measured bandwidth to
 the consensus bandwidth or the minimum between the descriptor's bandwidth-
 avg, bandwidth-burst or bandwidth-observed.

 Though i'm still not sure this is correct. I could just copy what you
 propose, but not sure about `capacity` and `weight` terms, as commented
 aboved.

 As a different issue to solve at some point in the future, i think we
 should unify terms for bandwidth in Tor code and `dir-spec.txt` to make it
 less confusing. It'd be also helpful to add formulae or more detailed
 descriptions on how the different bandwidth terms are generated in `dir-
 spec.txt`

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8494#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online