#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs