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

Sun Dec 20 13:37:42 UTC 2015

> On 20 Dec 2015, at 23:42, NOC <noc at babylon.network> wrote:
> 
> Signed PGP part
> Good to hear the criteria will be reviewed. As far as I am aware there
> are under-utilised resources on these two exit relays so that is why I
> am opt-ing in these relays.
> 
> If there is any more information on the expected resources for the
> fallback directory mirrors that will be used I am all ears ;)

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/ <https://globe.torproject.org/>
[1]: https://metrics.torproject.org/dirbytes.html <https://metrics.torproject.org/dirbytes.html>
[2]: https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt <https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt>

> 
> 
> On 12/20/2015 01:31 PM, Tim Wilson-Brown - teor wrote:
> >
> >> On 20 Dec 2015, at 02:55, NOC <noc at babylon.network
> >> <mailto:noc at babylon.network>> wrote: The initial message states
> >> that the relays should be non-exit replays. All these relays are
> >> exit relays with enough resources to spare so I would love to see
> >> them added. ...
> >>
> >> -- Tim Semeijn
> >>
> >
> > Hi Tim,
> >
> > Thanks for opting-in these relays.
> >
> > I didn't realise that there are under-utilised exit relays in the
> > Tor network. (I was the one who added "not an exit relay" to the
> > fallback directory criteria.) We'll review the criteria before we
> > select the final list.
> >
> > Please feel free to opt-in other under-utilised exit relays.
> >
> > Tim
> >
> > Tim Wilson-Brown (teor)
> >
> > teor2345 at gmail dot com PGP 968F094B
> >
> > teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F
> > B5A9D14F
> >
> >
> >
> > _______________________________________________ tor-relays mailing
> > list tor-relays at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> 
> --
> Tim Semeijn
> Babylon Network
> 
> PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20151221/698b35ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20151221/698b35ba/attachment-0001.sig>