nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 21:23:58 +01:00
Code Issues Packages Projects Releases Wiki Activity

r13437@catbus: nickm | 2007-06-15 14:29:56 -0400

Browse Source 
Incorporate comments [from april, ugh] into proposal 108.


svn:r10636
This commit is contained in:
Nick Mathewson 2007-06-17 15:10:40 +00:00
parent 5d68fc1075
commit f15df2d837
1 changed files with 27 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/spec/proposals/108-mtbf-based-stability.txt
View File

@ -46,12 +46,24 @@ Issues:
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:
@ -59,3 +71,14 @@ Limitations:
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.