[or-cvs] r10636: Incorporate comments [from april, ugh] into proposal 108. (in tor/trunk: . doc/spec/proposals)

[nickm at seul.org]

Author: nickm
Date: 2007-06-17 11:10:40 -0400 (Sun, 17 Jun 2007)
New Revision: 10636

Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt
Log:
 r13437 at catbus:  nickm | 2007-06-15 14:29:56 -0400
 Incorporate comments [from april, ugh] into proposal 108.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r13437] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt
===================================================================
--- tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt	2007-06-17 15:10:27 UTC (rev 10635)
+++ tor/trunk/doc/spec/proposals/108-mtbf-based-stability.txt	2007-06-17 15:10:40 UTC (rev 10636)
@@ -46,16 +46,39 @@
 
 Alternative:
 
-   "A router's Stability shall be defined as the sum of $alpha ^ d$ for every
+   "A router's Stability shall be defined as the sum of $\alpha ^ d$ for every
    $d$ such that the router was not observed to be unavailable $d$ days ago."
 
-   This allows a simpler implementation: every day, we multiply yesterday's
-   Stability by alpha, and if the router was running for all of today, we add
-   1.
+   This allows a simpler implementation: every day, we multiply
+   yesterday's Stability by alpha, and if the router was observed to be
+   available every time we looked today, we add 1.
 
+   Instead of "day", we could pick an arbitrary time unit.  We should
+   pick alpha to be high enough that long-term stability counts, but low
+   enough that the distant past is eventually forgotten.  Something
+   between .8 and .95 seems right.
+
+   (By requiring that routers be up for an entire day to get their
+   stability increased, instead of counting fractions of a day, we
+   capture the notion that stability is more like "probability of being
+   staying up for the next hour" than it is like "probability of being
+   up at some randomly chosen time over the next hour."  The former
+   notion of stability is far more relevant for long-lived circuits.)
+
 Limitations:
 
    Authorities can have false positives and false negatives when trying to
    tell whether a router is up or down.  So long as these aren't terribly
    wrong, and so long as they aren't significantly biased, we should be able
    to use them to estimate stability pretty well.
+
+   Probing approaches like the above could miss short incidents of
+   downtime.  If we use the router's declared uptime, we could detect
+   these: but doing so would penalize routers who reported their uptime
+   accurately.
+
+Implementation:
+
+   For now, the easiest way to store this information at authorities
+   would probably be in some kind of periodically flushed flat file.
+   Later, we could move to Berkeley db or something if we really had to.