Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[s7r <s7r@xxxxxxxxxx>]

-----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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays