Opened 9 years ago

Closed 3 years ago

#3044 closed task (wontfix)

At what bandwidth threshold is being a dir mirror unwise?

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords: performance bootstrap
Cc: chiiph Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Right now you opt not to advertise your dirport if your bandwidth rate is 50KB or less.

In #1338 there's a feisty discussion about whether we should make all relays dir mirrors. Or at least make all guards dir mirrors, to prepare for the glorious future when we use directory guards.

What sort of overhead do you get from being a dir mirror in practice? Will it change as we migrate from the v3 design to the microdescriptor design?

Bridges are dir mirrors no matter their bandwidth. The load on bridges would seem to be different than the load on public relays, since bridge load is a function of how many Tor clients are bridging through them. How can we compare?

Child Tickets

Change History (8)

comment:1 Changed 9 years ago by arma

Keywords: performance added

Marking as a 'performance' question since directory mirror speed plays a major role in time-to-bootstrap.

comment:2 Changed 9 years ago by arma

Keywords: bootstrap added

comment:3 Changed 9 years ago by arma

Cc: chiiph added

Tomas: a good first experiment here would be to look at the variance for bootstrapping times. That is, when you start up a Tor client with no cached info, it will fetch a consensus from an authority, and fetch descriptors from random (weighted by bandwidth) directory mirrors from the consensus. If it picks slow directory mirrors, it will take a while. How long is the mean, median, 90th percentile, etc?

If you change the selection algorithm that the Tor client uses (e.g. to ignore choices with bandwidth less than N, and weight by bandwidth among the remaining ones), you can probably cut off part of the long tail. Another variation on the selection algorithm is to ignore mirrors that don't have the Guard flag. Another variation is to look at fetching v3 consensus + descriptors versus fetching v3 microconsensus plus microdescriptors.

You should keep in mind while doing the experiment that you are comparing the situation where 1 user chooses differently and n-1 users choose with the old algorithm. So it wouldn't directly capture the case where all n users choose with the new algorithm. If the experiment goes well, we could maybe put the threshold in the consensus and have clients and/or mirrors obey it, to do a more realistic experiment; but that would take a few years before enough Tors upgrade.

comment:4 Changed 9 years ago by arma

Another twist here is that Tor picks several directory mirrors for fetching descriptors. The goal there is actually to reduce the variance of bootstrap time. So we think we've already partially solved the problem. But by how much? And how much more progress can we make?

comment:5 Changed 8 years ago by chiiph

To be clear, I was going to work on this ticket, but I'm not anymore for time reasons. So if anybody else wants to take this, please go ahead.

comment:6 Changed 6 years ago by sysrqb

I closed #1338 (as a dup of #12538). This ticket remains an interesting question, though. We've reached the glorious future of directory guards, and will soon likely reach the future where nearly all relays are dir caches, too. But, we also reduced the number of guards a clients chooses to one, which changes the parameters of this question a bit.

The answer to this question is still useful, and we still set the cutoff at 50KB, so it will be useful to know if this should be changed.

comment:7 Changed 6 years ago by arma

A great starting research question is still one of the ones raised above: if we do a full bootstrap (zero to 100%) with the various Guard-flagged relays, what is the mean, median, 25%, 75%, 95%, etc for how long it takes? Seeing that curve should help us decide if there's a better threshold we should use.

Tracking this sort of thing over time would be even cooler, to see what effect we have from having more relays (thus more dir info), more users (so we're more likely to have congestion during bootstrap), etc.

comment:8 Changed 3 years ago by karsten

Resolution: wontfix
Status: newclosed

Closing tickets in Metrics/Analysis that have been created 5+ years ago and not seen progress recently, except for the ones that "nickm-cares" about.

Note: See TracTickets for help on using tickets.