Re: [tor-bugs] #9321 [Tor]: Load balance right when we have higher guard rotation periods

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

#9321: Load balance right when we have higher guard rotation periods
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:
         Type:  project  |     Status:  new
     Priority:  normal   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  needs-proposal, tor-auth, tor-
Actual Points:           |  client, 026-triaged-1
       Points:           |  Parent ID:  #11480
-------------------------+-------------------------------------------------

Comment (by NickHopper):

 Replying to [comment:13 asn]:

 > Few questions that will need to be answered:
 >
 > - Will the script be called periodically and the authorities will have
 > to parse the output file every once in a while? Or will the script
 > be ran once, and then it's the job of the authorities to internally
 > update their state with new information?
 >
 > I'm currently aiming for the former behavior, to minimize the amount
 > of code that needs to be written for little-t-tor. OTOH, this means
 > that authorities will need to keep 9 months worth of consensuses in
 > their filesystem. As we move closer to completion of this task we
 > will see if the former behavior is indeed better.

 FWIW, I agree this is probably the right design, though parsing 9 months
 worth of consensuses with stem is no mean feat.  An alternative would be
 to have the script keep a summary file that is updated as new consensuses
 are fetched; it might store, e.g. the number of consensuses a relay
 appeared in for each day, and then could get batch updated.


 > - What should we do about consensus signatures? If we are fetching
 > consensuses from metrics, it's reasonable that we don't want to
 > trust them blindly. It would be nice if the script (or the auth)
 > could validate the consensus signatures, but it's not an easy task:

 I recently submitted a patch to stem (#11045) that can check consensus
 signatures, and certificates, so that part should be simple. Getting the
 certificates should also be easy -- every directory server serves the list
 of current certs at http://<hostname>:<dirport>/tor/keys/all.z and every
 tor client stores the list in .tor/cached-certs .  stem will happily parse
 these with parse_file(), though you might need to give it a hint about the
 file type.  Getting historical keys is more problematic; the script
 probably needs to retain a cache of old certs.  (Incidentally, metrics
 serves this, it's not very big.)



 > - What should happen if we are missing a few consensuses? Sometimes
 > the auths fail to establish a consensus, so it's reasonable that a
 > few consesuses will be missing if we look 9 months back. Should our
 > Python script recognize their absense? What if half of the
 > consesuses are missing? What if just one is missing? How should our
 > script react?

 These are good questions.  At the winter dev meeting, I think Nick
 suggested that when the auths fail to establish a consensus, there should
 be a signed "consensus failed" message.  I guess this requires another
 proposal, but if we had it going forward, then there shouldn't be a
 missing consensus.


 > - We need to think how the guardiness information will be passed to
 > clients (since clients need to change their path selection procedure
 > according to the guardiness). Proposal 236 simply says:
 > {{{
 > The authorities include the age of each guard by appending
 > '[SP "GV=" INT]' in the guard's "w" line.
 > }}}
 > But I don't think that's enough. What is an age anyway?
 >
 > Should we pass to clients information like "Node was a guard for
 > 3031/6574 consensuses during the past 9 months"? Should this be
 > passed in the consensus as part of the 'w' line or something?

 Agreed that the number of consensuses counted for GV should appear in the
 consensus; it could be in the w line or could also appear once in the
 document, e.g. before 'bandwidth-weights' there could be a line of the
 form

 {{{
 "guard-visibility-max" INT NL
 }}}
 And this would help with the deployment also; we could start with 3
 months' worth of consensuses and just add consensuses as they are
 produced.

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