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_dirs.inc

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-consensus-bootstrap.txt
>
>
>

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays