[tor-bugs] #25843 [Core Tor/Tor]: Make NumEntryGuards consistent with #271 consensus params

[Tor Bug Tracker & Wiki]

#25843: Make NumEntryGuards consistent with #271 consensus params
--------------------------+------------------------------------
 Reporter:  mikeperry     |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by mikeperry):

 Here's a list of things we're trying to learn from this testing:
 1. How often does the code decide that one of these two primaries is
 "down" when it is not?
 2. How often does the code prefer one guard over the other? (They should
 be split roughly 50/50 with this patch as-is, unless you get unlucky with
 path restrictions.. does that happen a lot?).
 3. How often do we decide to use guards other than our two primaries with
 this patch?
 4. What circumstances cause us to use guards other than our two primaries
 with this patch?
 5. Do we use the same two directory guards as our primary guards?
 6. Do we ever have microdescriptor shortages or 503 directory busy issues
 with this patch?
 7. What happens when we wander into the uncharted "sampled guard"
 territory of prop271?
 8. Do our failure modes for the above/other issues ever result in complete
 downtime for the client? (Can we fix that easily?)
 9. Can the client be induced to spam or otherwise thrash on its guards
 when it thinks one or both are down/unreachable?
 10. How does the vanguard controller behave with this patch?

 I think asn has some of this information already.

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