Re: questions about MinUptimeHidServDirectoryV2 in 0.2.1.2-alpha

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Scott,

Scott Bennett wrote:
|> The default of 24 hours ensures that hidden service directories are
|> available for the next few hours with a certain probability. The idea is
|> that there are hundreds of hidden service directories at some point
|> which are not authoritative any more, but provide a more scalable and
|> robust storage than the three authoritative ones can. Hidden services
|> and clients need to have a view as consistent as possible of which
|> hidden service directories are out there, so that clients can find
|> previously stored hidden service descriptors. The 24 hours have turned
|
|      How is that different from the situation of normal directory mirrors?

The big difference is that every hidden service directory is responsible
for a certain set of hidden service descriptors and not all of them.

If you run a hidden service you determine six responsible hidden service
directories depending on a) the onion address of your service and b) the
node identities of the hidden service directories. Then you store your
descriptor on exactly those directories.

Your clients need the same or at least very similar information about
hidden service directories as you have. If their list of directories
contains further directories or misses some of those that you know, your
clients will end up requesting your descriptor from the wrong
directories. A further difficulty comes from the fact that your clients
and you might use consensuses with up to two hours time difference. A
certain number of differences is tolerable by performing replication,
but these shouldn't get too big.

|      In other words, it is already covered by the "Guard" and "Stable"
| flags from the authorities, right?

These flags have different purposes, and their definitions might change
in the future (as might the definition of "HSDir"). Apart from that
there needs to be an "HSDir" flag anyway to denote which relays want to
participate in the hidden service directory.

Admittedly, a further evaluation could compare the approach taken here
with your approach to derive usefulness of a hidden service directory
from "Guard" and/or "Stable" flags instead. Honestly, I don't know what
the result would be. Seems that there's always work left to do. ;)

|> http://freehaven.net/~karsten/dirnodesminuptime.pdf
|
|       It's very pretty, but, given the legend, which I assume denotes
| uptimes in hours, the axis labels are not helpful.  What exactly do
| "Directory Size" and "Time Index" refer to?

"Directory Size" refers to the size of the distributed hidden service
directory, assuming that *all* relays that have their directory port
open work as hidden service directory. Of course, this number differs
significantly from the current number of hidden service directories.
That's why one proposed change of proposal 143 (which is planned to be
implemented in 0.2.1.x) is to make all relays with open dir port act as
hidden service directories by default, with the possibility to opt-out.

"Time Index" is admittedly a bad axis description, which however comes
from the fact that I didn't know how to write month names at the
appropriate places of the x axis in R. :) The x values denote the hours
of evaluated consensuses between mid-January and end of March. The peaks
that you see for minimum uptimes, e.g., of 4 to 16 hours are the days in
that interval. Now compare the peaks of using no minimum uptime at all
with those of requiring an uptime of 24 hours. If there would be no
requirement for minimum uptime, replication would have to be increased
significantly.

|> The option MinUptimeHidServDirectoryV2 is mainly there to perform tests
|> with the distributed hidden service directory without having to wait for
|> 24 hours. It is not required to set it in the public Tor network. (It
|> only has an effect on directory authorities anyway.)
|
|      I understand that, though it is also useful for the operators of the
| current authorities should the policy change.  What I still don't see is
| the need for a 24-hour delay before a server stops being only potentially
| useful and becomes actually useful.  Earlier today the HSDir count was
| down to only *4*.  How is it thus helpful to keep other servers from being
| available for use?

I think I have already answered these questions above. If I should have
left out something, please ask.

Hope this helps a bit more now. :)
- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFImcwL0M+WPffBEmURAiUkAJ9MIRiesdLEenA9BxSJJ4T6mC2fZACfYWNT
2Net1ADWsE/ywa7V1l4Iqtw=
=IlPj
-----END PGP SIGNATURE-----