-----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-consensus-bootstrap.txt > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWdsFzAAoJEIN/pSyBJlsRCTsIAIe1rq9wMejw+iUzAygNo04/ qpVfbupTvCe0CcbbadAEndpboKQGVDgXSTrj7fx59DC0oQcKvOlpjyKin13xxPoy HPV2ClurHJD2PrM7p4ZUSHhSkwL2PBQyO9X3or+RXiSeqy1E+mLEyjOT9ckjawX3 6hgLm7VD9Jj2+z2GRLp8caXjfNmIb4trYZ1G1PF/AKQdpGJhIAgOHILsuRiXI9EU rFcpchYnXSksSfG9tZCVcQR3dHB6cejTIFpWMijdoLtmdy+CeDumwJa5C5CK1WCX ncERnai+KFFOQZZx3s8UyzaU8Lyk+spGL5tt5jQ8qaVPv5muKwvoK/RyzgMmto4= =XhXY -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays