[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23863 [Core Tor/Tor]: When our directory guards don't have each others' microdescs, we should mark some dead
#23863: When our directory guards don't have each others' microdescs, we should
mark some dead
-----------------------------------------------+---------------------------
Reporter: teor | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.2.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.0.6
Severity: Normal | Resolution:
Keywords: tor-guard, tor-bridge, tor-client | Actual Points:
Parent ID: #21969 | Points: 1
Reviewer: | Sponsor:
-----------------------------------------------+---------------------------
Comment (by teor):
I think we should implement an authority md fetch for clients that run out
of microdesc attempts. And I think they can easily handle the load of a
few mds, because they are handling a similar consensus load from clients
and relays already.
I also don't think removing fallbacks from the list will help much,
because bootstrapping clients try authorities anyway.
See below for details.
Replying to [comment:7 asn]:
> Replying to [comment:3 teor]:
> > Replying to [comment:2 asn]:
> > > Seems to me that the ways to deal with the edge case you describe
above are:
> > >
> > > a) Eventually clients try authorities to fetch mds if all else fails
(bad for the health of dirauths). I think that's what you suggested
basically.
> >
> > Yes, we should implement this, if the other fixes don't resolve the md
issue.
> > It's only bad for the authorities if a lot of clients do it all the
time.
> >
>
> True. But we have lots of clients, so I think before doing this we might
want to calculate the probability of this happening, to try to understand
how many clients will end up doing this behavior.
Yes, I think we should estimate how often it will happen. We can afford to
have a few thousand clients download a few mds per hour (0.1% of 2 million
clients per hour). Because we have a few thousand relays download two
consensus flavours and all the new mds from the authorities, and they are
handling this load fine.
> > > b) We remove dirauths from the fallback list (less traffic on
dirauths. any drawback?)
> >
> > You can't avoid this issue by stopping clients contacting authorities.
Because there are other ways that a client can have a consensus with some
microdescs that are not on its guards.
> >
>
> True. But it's less likely if dirauths are not in the picture, since
basically your edge-case is guaranteed to happen everytime a client
randomly picks a dirauth early in the hour (e.g. between hh:00 and hh:05).
Yes. Directory mirrors download at random between hh:00 and hh:30, so
missing microdescriptors are guaranteed to happen for 50% of clients that
bootstrap off authorities (9/(150*10 + 9) ~= 0.6% of clients bootstrap off
authorities) at hh:15. Assuming that clients bootstrap at random
throughout the hour, this is 0.6% * 0.25 = 0.15% of bootstrapping clients
per hour. So we can afford to have all these clients try an authority for
their mds, because the number of bootstrapping clients is much lower than
the number of running clients. (We could afford to have 0.15% of all
clients do this, not just 0.15% of the bootstrapping ones.)
The actual figure is slightly higher than this, because after trying 3
fallbacks/authorities, 0.3.2 and later clients try an authority directly.
When 10% of fallbacks are down, 0.1% of clients try an authority for this
reason. But the authorities are already handling this consensus fetch
traffic fine, so an extra few mds won't be an issue.
(For 0.3.1 and earlier clients, 100% try an authority and a fallback
straight away when bootstrapping, and they pick whichever wins. So we
might want to think a bit harder about backporting #17750 and #23347, if
we also want to backport an authority md fetch to earlier versions.)
We could easily reduce the 0.3.2 client authority fetch to 0.115% (0.015%
+ 0.1%) by weighting the fallbacks at 100 rather than 10. But that doesn't
remove the 0.1% that try an authority after 3 fallbacks. So I'm not sure
re-weighting (or removing) would have the impact you want.
> > And we already weight dirauths low on the fallback list, so not many
clients contact them.
> >
> > Removing authorities from the fallback list would break clients that
disable fallbacks, and clients on non-standard networks.
These clients would have nothing in the fallback list to bootstrap off,
because they don't use the hard-coded public fallbacks. We can avoid this
by only removing the authorities when using public fallbacks, but that
makes the code hard to test in chutney.
> > Also, it would break clients if too many fallbacks go down on the
public network.
> >
>
> Hmm, I don't understand these points exactly. Can you expand? Why would
clients break worse than currently if we remove dirauths from fallbacks?
We can add a few more relays in the fallbacks to compensate.
The idea of having authorities in the fallback list is that clients will
use them if a large number of the fallbacks break for some reason (for
example, a bad bug on mirrors). I am not sure if this actually works, but
let's not break it until we are sure:
* removing them will help this issue, and
* removing them won't create any other issues.
I don't think removing authorities from the fallback list would help this
issue, because 0.1% of bootstrapping clients will still try an authority
when they fail 3 fallbacks.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23863#comment:8>
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