[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25843 [Core Tor/Tor]: Make NumEntryGuards consistent with #271 consensus params
#25843: Make NumEntryGuards consistent with #271 consensus params
--------------------------+------------------------------------
Reporter: mikeperry | Owner: (none)
Type: defect | Status: needs_review
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 asn):
Replying to [comment:1 mikeperry]:
> Here's a list of things we're trying to learn from this testing:
OK, I've been running the above branch for a week or so. Here are the
things I can answer already:
----
> 1. How often does the code decide that one of these two primaries is
"down" when it is not?
This is the same behavior as single-guard, so not much has changed here.
Tor doesn't have many false positives here when the network is good, but
it can have false negatives [i.e. tor keeps on thinking that a guard is
up, but that guard is overheating and sending DESTROYs to every circuit
(#25347)].
When the network is bad, it's a totally different situation. See question
3.
> 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?).
I think we good here. It's a `smartlist_choose()` in
`select_entry_guard_for_circuit()`.
> 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?
This is related to question 1. Usually this can happen when the network is
bad, and Tor thinks that some guards are down when they are not. There are
cases where Tor can end up thinking that the primaries are down, and it
will use the guards below the primaries (i.e. enter the wilderness). I
tested this manually using iptables and I immediately found #25783. We
need to fix this bug and re-test this, to see what else appears.
The iptables command was a simple:
`iptables -A OUTPUT -d 202.54.1.22 -j DROP`
where `202.54.1.22` was my top primary guard.
> 5. Do we use the same two directory guards as our primary guards?
Yes. We only use our two primary guards for directory guards.
> 6. Do we ever have microdescriptor shortages or 503 directory busy
issues with this patch?
I haven't encountered such a thing yet, but also I haven't looked for it.
I haven't encountered #21969 either.
> 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?)
I haven't done enough testing here, but sometimes things work perfectly,
and some other times Tor gets stuck for a bit and then gets unstuck and
works fine. In the case of #25783 Tor got stuck for about 6 minutes tho...
We really need to look into this more.
> 9. Can the client be induced to spam or otherwise thrash on its guards
when it thinks one or both are down/unreachable?
This is #25347. Tor will keep on trying to establish circuits to its
guards even tho they are overloaded and sending DESTROYs all the time.
There is no single best approach to solve that problem.
> 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:3>
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