On 21 Dec 2015, at 01:55, s7r s7r@sky-ip.org wrote:
Signed PGP part 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 there are 100 fallback directories, and clients try several (see below), it doesn't matter if a few are down or busy or are being DoSed.
And it's the relative weights among the set of fallback directories that are used by clients to select a fallback directory: if more relays are added to the Tor network, the relative weights of the fallback directories stay the same. (And we pick up the new weights in the next release.)
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?
That's a possibility, it's what we currently do for authorities - clients select an authority at random, without considering their consensus weights. I like the simplicity of giving all the fallback directories the same weight, but I think it's wise to add any extra load in proportion to the existing load on the relay.
And I don't know whether equal weights is a viable option for fallback directories - it will depend on their consensus weights being similar enough. (The code currently uses weights, but we could set them all to the same weight if we wanted to.)
The December 2015 list of candidate fallback directories[0] has relative weights from 2.3% to 0.008%.
While we'd likely exclude some relays at the lower end, a relay that helps 1 in 1000 clients connect to the Tor network is still performing a useful role. And there's several tradeoffs we will consider when creating the list.
There's a tradeoff between including small relays, and the cost of increasing the size of the tor binary with each fallback in the list. There's also the risk that including small relays will lead to them not being able to cope with the extra load.
At the higher end, there's a tradeoff between weighting according to consensus weight, and letting a fallback directory see too many clients join the network. (Authorities see approximately 11% of clients that join the Tor network, so we would set the maximum fallback weight lower than that.)
The script we use to select fallback directories has parameters that allow us to control these sorts of tradeoffs, you can see many of them listed in a comment at the top of the file[0].
[0]: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di...
As you said on irc, a client will try (maybe 3) fallback directories before giving up and going to the directory authorities.
Currently, a client will try 3 fallback directories before trying an authority, another fallback directory, another authority, then giving up for an hour. (This aims to provide ~99.9% bootstrap success within 20 seconds, without increasing the load on the authorities - even if a few authorities and many fallbacks are down. We can fine-tune it before release if we need to.)
Tim
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...
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F