-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
The estimated extra load looks good, it shouldn't be a problem.
Are we entirely sure we want to hardcode a static weight for each fallback directory relay? I know we require it to be stable enough but sometimes the weight assigned to a relay is outside the control of the operator (more relays are added to the Tor network so consensus weight distribution changes, the relay gets DoS-ed and becomes slow at the next measurement).
If all the relays eligible for being added as fallback directory relays are required to have a big enough weight, this means the estimated extra load shouldn't be a problem for neither of them. In this case how bad will it be if we do not hardcode a static weight and give equal chances to all fallback directory relays to be selected by new clients?
As you said on irc, a client will try (maybe 3) fallback directories before giving up and going to the directory authorities.
On 12/20/2015 3:37 PM, Tim Wilson-Brown - teor wrote:
With 100 fallback directory mirrors, up to an extra 50 GB per fallback per month. (This is my estimate of the maximum extra load, averaged across 100 fallbacks. But client consensus downloads will actually be distributed by the fallback's consensus weight, so larger relays may use more.) I suspect most fallback directories won't notice the extra load.
Here are the details:
At the moment, new Tor clients contact a directory authority to download their initial consensus.
After we release the fallback directory feature, new clients will contact a fallback directory mirror to download their initial consensus. (Bridges will also contact fallback directory mirrors, as they are designed to behave like clients. Most relays will contact an authority.) Clients will choose a fallback using at random, weighted based on their consensus weight.
If a client is on a slow, unreliable, or censored connection, they may contact several mirrors before they get a successful connection. (However, regardless of the number of connection attempts, the consensus download only happens once.) After the initial consensus download, clients will choose from the full set of directory mirrors in the consensus.
We expect that most clients will already have a consensus, it will only be the new installs that use a fallback directory mirror. So if you take the download counts for the new version of Tor Browser, multiply by about 1.5MB (the size of a microdesc consensus), then distribute that by consensus weight over the fallback directory mirrors, that's the extra load we expect to place on each fallback directory mirror.
Alternately, if you take the bandwidth that a directory authority uses to serve consensuses to clients, and divide by 11, then that's how much we expect a fallback directory mirror to handle on average. (There are 9 authorities, and we hope to have 100 fallback directory mirrors.)
Unfortunately, I don't know the number of Tor Browser downloads. And while I can see that the authorities use 110 - 230 KB/s of bandwidth[0], I don't know how much of that is client consensuses.
If we assume that the entire authority bandwidth is used for client consensuses, then I would expect that a fallback directory mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional bandwidth, or an extra 26 - 54 GB per month on average, distributed by consensus weight.
It's worth noting that the entire Tor network already uses 1Gbit/s to serve directory documents[1], and first-time downloads for new clients are only a fraction of that. So I suspect most fallback directory mirrors won't notice the extra load.
If you're interested in some further background, the original proposal is at [2].
Tim
[0]: https://globe.torproject.org/ [1]: https://metrics.torproject.org/dirbytes.html [2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless...