[tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
------------------------------------+------------------------------------
 Reporter:  asn                     |          Owner:  (none)
     Type:  defect                  |         Status:  needs_revision
 Priority:  Medium                  |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor            |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  tor-dirauth, tor-guard  |  Actual Points:
Parent ID:                          |         Points:  2
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:4 asn]:
 > Replying to [comment:3 teor]:
 > > Replying to [comment:2 asn]:
 > > > OK I did it! I ripped off the code from the codebase. Here are the
 rewards:
 > > > {{{
 > > > 19 files changed, 11 insertions(+), 1063 deletions(-)
 > > > }}}
 > > >
 > > > Please see branch `ticket24456` in my repo for this.
 > >
 > > Quick structural review:
 > >
 > > We don't delete options, we OBSOLETE() them.
 > >
 > > We can't just delete code from networkstatus_compute_consensus() and
 any the functions it calls. Instead, we add a new consensus method, and
 only run the old code when the consensus method is old enough. For
 guardfraction, there will be a range of consensus methods that run the
 guardfraction code.
 > >
 >
 > Oh man you are right. I guess we need to do this even tho no dirauths
 run the guardfraction code right now and they don't plan to start... So
 I'd need to define a new consensus method
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION` and only run the guardfraction
 consensus code if it's between `MIN_METHOD_FOR_GUARDFRACTION` and
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION`.

 It's >= MIN_METHOD_FOR_GUARDFRACTION and <
 MIN_METHOD_FOR_REMOVING_GUARDFRACTION.

 > And then eventually when all dirauths are upgraded to versions `>=
 MIN_METHOD_FOR_REMOVING_GUARDFRACTION` we can remove that consensus
 guardfraction code too. Does this plan make sense?

 Technically, we can't remove the guardfraction code until we remove all
 the consensus methods that could have used it.
 At the moment, we support all methods from 13-28, excluding 21.

 We can't remove all the buggy guardfraction methods like we removed 21,
 because the buggy range is 20-28.
 (Maybe we could remove 20, because we'll never use it.)

 See also #24378, where I suggest we start removing some of the lower
 methods. The last time we removed consensus methods was in #10163.

 > > Votes are different: we can make authorities stop voting guardfraction
 without needing a new consensus method.
 > >
 > > How buggy is guardfraction?
 >
 > It suffers from #16255 and perhaps other unknown bugs. It's extremely
 hard to test this feature on chutney (because chutney's bandwidth weights
 are not realistic), so we only learned of #16255 when we deployed it on
 the real net.
 >
 > > Does it work?
 >
 > It "works" but it's buggy. Authorities compute bad consensus weights for
 the relays and
 > then the bandwidth equations complain.
 >
 > > Does it cause consensus failures when it's turned on?
 >
 > Yes.

 Ok, so let's rip out the vote generation code in master as soon as we
 obsolete the option.

 > > Should we backport the "don't vote guardfraction" part of this patch
 to 0.3.1 and 0.3.2?
 >
 > Not sure. Perhaps not. No dirauths have the guardfraction torrc option
 enabled anyway.

 Let's backport making the option obsolete to 0.2.9 and later.
 That's a one-line patch.

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