[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:11 mikeperry]:
 > Juga: Your analysis in `#1` is correct to my memory, and I agree
 probably not causing this issue.
 >
 > Re `#2` and `#3`: whats is the sbws torrc? TorFlow sets all the
 aggressive consensus and descriptor fetching options, so it may have
 descriptors *not* in the consensus, even. Or descriptors for relays
 oscillating in the consensus.
 >
 > Torflow *also* uses Tor 0.2.9, which may have different descriptor vs
 microdescriptor fetching behavior. If you are using microdescriptors, you
 might also not be getting fresh enough relay data, because those have to
 be generated by at least one consensus process.
 >
 > I think these are more likely culprits for this specific ticket.
 >
 > Here is the relevant torrc piece, which I think may behave differently
 with Tor 0.2.9:
 > {{{
 > FetchUselessDescriptors 1
 > # Workaround for Tor #24110, tracked in TorFlow #24094
 > UseMicrodescriptors 0
 > __LeaveStreamsUnattached 1
 >
 > # Bad idea? Too much consensus update activity?
 > FetchDirInfoExtraEarly 1
 > FetchDirInfoEarly 1
 > }}}

 I agree it's important to update update correctly descriptors and
 consensus, but this should has been fixed in #30733 and other tickets.

 I think i didn't make my questions clear.
 Let's assume consensus and descriptors are updated correctly, and the
 `ratio` is also calculated correctly.

 To my understanding, what basically Torflow does is:

 new_bw = min(descriptor observed bandwidth, descriptor burst bandwidth, 1)
 * ratio
 Iff consensus bandwidth is not None (for all relays).

 And what sbws is doing:

 new_bw = min(consensus bandwidth, descriptor observed bandwidth,
 descriptor average bandwidth, descriptor burst bandwidth, 1) * ratio
 Iff:
 - descriptor observed bandwidth > 0 and descriptor observed bandwidth !=
 None (for that relay) and
 - descriptor average bandwidth > 0 and descriptor average bandwidth !=
 None (for that relay) and
 - descriptor burst bandwidth != None

 I think that treating in a different way average bandwidth and burst
 bandwidth is a bug and i think that if consensus AND observed are missing,
 we should not calculate the minimum with the average and burst only cause
 those numbers could be high and are set by the operator.

 So, the main question is: should we calculate the new_bw (scale) for a
 relay when some of the bandwidth values is missing or 0 (what would result
 in `1` for the `min`)?. If not, which are the bandwidth values we should
 have at least?

 I'd answer (but not sure):
 - Iff consensus AND observed are missing: do not scale, ie, don't include
 the relay in the bandwidth file as to vote
 - scale in any other case with the values we have (and convert None values
 to 0?. If there're None values there is still a bug in sbws we need to
 solve)

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