Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#24785 closed enhancement (fixed)

Reduce the fallback stability and flag requirements due to extra network load

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Fallback Scripts Version:
Severity: Normal Keywords: fallback
Cc: Actual Points: 0.5
Parent ID: #22271 Points: 0.2
Reviewer: pastly Sponsor:


We're only getting 700 candidates, we should adjust the settings so we get about 1500, like last time.

Child Tickets

Change History (6)

comment:1 Changed 3 years ago by teor

Actual Points: 0.5
Status: assignedneeds_review
Type: defectenhancement

We get 101 fallbacks with the most recent list and current settings.
Our goal is about 150, or more if we don't want to rebuild the list too often.
(We want to rebuild when 25% are down. Ideally, we don't want to go much below 100 fallbacks, either, which implies that we want at least 134 to start with.)

ADDRESS_AND_PORT_STABLE_DAYS is currently 30. But address or port changes are the major reason we lose fallbacks. So let's increase it to 90 days. (I think it's ok to assume that a relay that's had the same address for 3 months will keep it for 12-24 months.)

The cutoffs are currently:

But there's no reason to require the guard flag when we have a minimum bandwidth requirement. What we really need is for fallbacks to be Running, and V2Dir:

MIN_BANDWIDTH is currently 1.0 MByte/s, or 100x the expected load.
I think it's fine to drop it to 50x the expected load.
(Also, the bandwidth system isn't that accurate, anyway, so some relays with low measured bandwidth actually have lots of spare capacity to serve directory documents.)

I also removed some old fallback list restrictions that we used to manually maintain, but haven't checked since 0.2.8 or 0.2.9. We don't try to work out if fallbacks are on the same machine, and we don't automatically blacklist fallbacks if their details change. (That's what ADDRESS_AND_PORT_STABLE_DAYS is for.)

This gives us 152 fallbacks, and relay operators are still opting-in.
So I think we'll go with that, and consider changing to opt-out for the next release (#24789).

Please see my branch ticket24785 on

comment:2 Changed 3 years ago by pastly

Status: needs_reviewmerge_ready

LGTM. Standard "wait actually this isn't merge_ready, wait for other stuff to be ready."

comment:3 Changed 3 years ago by teor

This code is now in my branch fallback-code-2018-01 at

comment:4 Changed 3 years ago by teor

Reviewer: pastly

pastly reviewed all of these

comment:5 Changed 3 years ago by teor

Resolution: fixed
Status: merge_readyclosed

This branch has been merged, so these tickets are now implemented,

comment:6 Changed 2 years ago by teor

Cc: teor@… removed

Remove useless Cc

Note: See TracTickets for help on using tickets.