[tor-bugs] #33871 [Core Tor/sbws]: Scale exactly as torflow does?

[Tor Bug Tracker & Wiki]

#33871: Scale exactly as torflow does?
-------------------------------------------------+-------------------------
 Reporter:  juga                                 |          Owner:  juga
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  sbws:
                                                 |  1.1.x-final
Component:  Core Tor/sbws                        |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33775                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by juga):

 Replying to [comment:14 mikeperry]:
 > Oh I missed that sbws was including avg_bandwidth in the min().. That
 definitely should not be there. Average will always be below observed,

 I don't think this is the case, just taking randomly a relay from my
 `cached-descriptors`:
 {{{
 router rotateRelay21 188.227.170.106 2109 0 0
 fingerprint 1387 BB67 C0A1 BCE2 8133 FF72 39E0 27D5 4C56 538D
 bandwidth 2621440 10485760 5445375
 }}}

 I also looked 2 years ago at the spec and the code
 (https://onbasca.readthedocs.io/en/latest/bandwidth_tor.html) and
 concluded that the average is `min(RelayBandwidthRate, BandwidthRate,
 MaxAdvertisedBandwidth)`, which are all set by the operator (or torrc
 defaults), am i mistaken?.
 Maybe you're thinking on the `advertised` bandwidth, not the average?

 > and we want observed or burst because burst can be limited by config by
 operators who don't want traffic, giving them at least one (admittedly
 sloppy) knob to try to reduce traffic.

 I agree with this, but for the same reason we should also limit it by the
 average
 (https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py#n1340)

 >
 > I just dug a bit deeper into the 0 bw issue, and I found that we
 actually set it to at leasty 1, to simplify computation. This is done in
 the TorCtl.Router class:
 https://gitweb.torproject.org/pytorctl.git/tree/TorCtl.py#n379
 >
 > So we should probably do something that in sbws too (either hack to 1 or
 riddle with special cases everywhere), so we can still measure 0-bw
 relays.

 Yes, we're doing that in sbws, note that in my previous reply i included a
 `1` in the `new_bw` equations, ie. `new_bw = min(consensus bandwidth,
 descriptor observed bandwidth, descriptor average bandwidth, descriptor
 burst bandwidth, 1) * ratio`

 What i mean is that it's a different thing to calculate the minimum when
 one of those values is 0 (the result will be 1) or to exclude one of those
 values when it's 0 (the result will be greater or equal than 1).

 Note that AFAIU, Torflow code is not calculating the `new_bw` using the
 consensus bandwidth, though, it just does not produce any bandwidth file
 if any consensus bandwidth is missing.

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