[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #27302 [Core Tor/Tor]: Duplicate votes on 0.3.4 and later

#27302: Duplicate votes on 0.3.4 and later
----------------------------------+------------------------------------
 Reporter:  teor                  |          Owner:  teor
     Type:  defect                |         Status:  assigned
 Priority:  Medium                |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor          |        Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal                |     Resolution:
 Keywords:  regression, 034-must  |  Actual Points:
Parent ID:  #27146                |         Points:
 Reviewer:                        |        Sponsor:
----------------------------------+------------------------------------
Changes (by teor):

 * status:  new => assigned
 * owner:  (none) => teor


Comment:

 Replying to [comment:5 arma]:
 > Replying to [comment:3 teor]:
 > > I looked at the logs, and there aren't actually any duplicate POSTs by
 the sending authorities. So I don't know why 0.3.4 authorities log this
 message.
 >
 > Hint: Part of the process of making sure we've got all the votes is that
 we fetch missing votes from other dir auths. Do we just ask the others for
 all their votes? I don't remember the details.

 We ask all the others for the votes that *we* don't have yet:
 https://github.com/teor2345/tor/blob/master/src/feature/dirauth/dirvote.c#L2961

 Which can result in duplicate votes for two reasons:
 * multiple other authorities have the vote(s) we're looking for
   * we can safely ignore this case in chutney (#27303)
 * we ask an authority for its vote, while it is uploading its vote to us
   * we can safely ignore this warning in chutney (#27303), but I also have
 a patch that will mitigate it in chutney, and on the public network

 That usually doesn't happen in the public network, because there are
 usually 2.5 minutes between creating and uploading votes, and checking for
 missing votes.

 But chutney has 1 second between creating and uploading votes. It also
 starts all the authorities at about the same time.

 Here's why that matters:

 In 0.3.3 and earlier, we called dirvote_act() from
 second_elapsed_callback(). So there was almost always enough time for each
 authority to make its vote, start the upload, and the other authorities to
 get the upload, before the next second_elapsed_callback().

 In 0.3.4 and later, we call dirvote_act() when we start up to check the
 schedule. Then we call it at the end of each event loop, when a scheduled
 action is due. Sometimes there isn't enough time for an authority to
 upload, before others start downloading.

 In the case where the authority starts late, all actions are scheduled to
 happen as soon as possible.

 In 0.3.3 and earlier, all actions happen in the same callback. In most
 cases, we would calculate our vote, start uploading, start downloading,
 fail to create the consensus, and fail to publish the consensus - all in a
 few microseconds in the same callback.

 In 0.3.4 and earlier, each scheduled action happens in successive
 callbacks, which are a few hundred milliseconds apart. So we can calculate
 our vote, start uploading, start downloading, try to create the consensus,
 and try to publish the consensus - and the results are very racy, because
 the other authorities are doing the same thing.

 This issue can also happen in rare cases on the public network. If an
 authority starts up at just the right time. In particular, if an authority
 starts up just before HH:55, it will split the consensus on the other
 authorities. (Because some get its vote, and some don't.)

 Usually, that's ok, because a majority will end up with the new
 authority's vote (or not end up with its vote). But if multiple
 authorities start up near the same time (like chutney), or there's some
 other split at the same time (like consensus methods), then the consensus
 can fail.

 I have a patch that makes authorities skip creating their vote if the
 other authorities have already created the consensus for this period. (And
 similarly, they skip creating the consensus if the other authorities have
 already published it.) I'm still testing it. (And putting out other
 fires.)

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