Uptime Sanity Checking

[Nick Mathewson]

On Fri, Mar 09, 2007 at 10:05:57AM -0700, Damon Liwanu Mc Coy wrote:
> 
> Yes this is a band-aid fix, and a better fix would be as Nick said
> to have the directory servers ignore uptime and track stability.
>
> 

> Some of the issues with having the directory servers do this are:
> (1) A set of rules as to how they measure stability needs to be
> thought up. 

Proposed rule:

  "An authority should call a server Stable if its observed MTBF for
  the past month is at or above the median MTBF for Valid servers."

  MTBF shall be defined as the mean length of the Runs observed by a
  given directory authority.  A Run begins when an authority decides
  that the server is Running, and ends when the authority decides that
  the server is not Running.  In-progress runs are counted when
  measuring MTBF."

This shouldn't be too hard to implement.

>  (2) The directory servers would need to retain more
> state, so that when they are restarted they would remember all the
> past stability information.

Right; HD is pretty cheap, though, and I bet there's a nice incremental
algorithm to maintain an estimate of MTBF as defined above without
having to scan a server's complete history every time we want to
generate a networkstatus.

> (3) If a new authoritative directory
> server is added how would they integrate into the network?

That's mostly a separate issue; it only affects the Stable flag to the
extent that a new authority would disagree with other authorities
about which hosts are Stable.  This disagreement is fine, since
clients make decisions based on the majority opinions of the
authorities.  As long as new servers remain in a minority, they should
be fine.  (See dir-spec.txt and the in-progress 101-dir-voting.txt .)

> (4) If
> the directory servers became grossly out of sync could the clients
> handle this?

With respect to the Stable flag, yes; we can't get so out-of-sync
that an odd number of voters don't reach a majority on a yes/no
question.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070309/049a382a/attachment.pgp>