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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 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`.

 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?

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

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

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24456#comment:4>
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