[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4483 [Tor]: If k of n authorities are down, k/n bootstrapping clients are delayed for minutes
#4483: If k of n authorities are down, k/n bootstrapping clients are delayed for
minutes
-------------------------------------------------+-------------------------
Reporter: arma | Owner: teor
Type: defect | Status:
Priority: High | needs_review
Component: Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: performance, bootstrap, dirauth- | Version:
dos-resistance, tor-client, large-feature, | Resolution:
prop210, 028-triage, TorCoreTeam201512, | Actual Points:
MikePerry201512R | Points:
Parent ID: #2664 | medium/large
Sponsor: SponsorU |
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:46 nickm]:
> Okay, I think I get it. Thanks for all the replies and comments; this
patch is looking good.
>
> Last questions:
> * How have you tested this in the wild? How well does it do? How
sure are you that it doesn't open a lot of extra connections, and that it
actually behaves as you think it does?
'''Improvements'''
I'm very confident that the code works as expected, and provides
significantly better bootstrap reliability for clients. (And it gets even
better when we can use fallback directories as well - see #15775.)
I've tested it as a client, hidden service, and bridge client, using
chutney and in the wild, on multiple OSs (OS X, Linux), with and without
fallback directories. It bootstraps correctly in all these cases.
It opens connections exactly on schedule (regardless of whether the other
connections fail or are delayed), and it stops when it gets a consensus.
I've been running it as my Tor Browser tor for a week or two.
(The code is only active for clients before they download a consensus.
This limits its impact to client bootstrap.)
'''Safety'''
The current schedules limit tor to trying:
* If there are no fallbacks: 3 authority connections over 10 seconds
* I feel that adding one authority connection is the minimum we could do
to make boostrapping more reliable, and it's a good tradeoff between
reliability and load.
* If there are fallbacks: 4 fallbacks and 2 authorities over 21 seconds
* We don't add any extra authorities in this case, we expect 4 fallbacks
to provide much more reliability than 1 authority.
Then each schedule waits for an hour before trying again.
There is code in the patch that limits tor to 3 simultaneous connections.
The existing code is used to limit the number of connection
attempts/failures to 4 (authorities only) or 7 (fallbacks and
authorities). Tor then waits an hour before trying again (the existing
"slow zombie" behaviour). It will also retry if there's a SOCKSPort
request.
> * Could you do one last rebase to squash the fixup! commits and
remove the reverted commits? I could try to do that, but I got conflicts
when I did, and I'm worried about getting it wrong.
The squashed commit is at `feature4483-v10-squashed`.
I'm sorry about that, some of my commits have dependencies on one another.
And one of the fixups was mislabeled. I'm trying to get better at this.
(There was also a conflict with the clock skew changes that were merged.)
I made one further fix:
* I changed the name of CONSENSUS_BOOTSTRAP_SOURCE_FALLBACK to
CONSENSUS_BOOTSTRAP_SOURCE_ANY_DIRSERVER to match the change to
DL_WANT_ANY_DIRSERVER.
(If you want to check that the squash didn't change anything (except the
name change above), a plain rebase with no squashes is at
feature4483-v10-rebased. It's not easy to do this with feature4483-v10, as
it was based on master pre-0.2.7.6 release.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4483#comment:47>
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