146-long-term-stability.txt 3.4 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586
  1. Filename: 146-long-term-stability.txt
  2. Title: Add new flag to reflect long-term stability
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Nick Mathewson
  6. Created: 19-Jun-2008
  7. Status: Open
  8. Target: 0.2.1.x
  9. Overview
  10. This document proposes a new flag to indicate that a router has
  11. existed at the same address for a long time, describes how to
  12. implement it, and explains what it's good for.
  13. Motivation
  14. Tor has had three notions of "stability" for servers. Older
  15. directory protocols based a server's stability on its
  16. (self-reported) uptime: a server that had been running for a day was
  17. more stable than a server that had been running for five minutes,
  18. regardless of their past history. Current directory protocols track
  19. weighted mean time between failure (WMTBF) and weighted fractional
  20. uptime (WFU). WFU is computed as the fraction of time for which the
  21. server is running, with measurements weighted to exponentially
  22. decay such that old days count less. WMTBF is computed as the
  23. average length of intervals for which the server runs between
  24. downtime, with old intervals weighted to count less.
  25. WMTBF is useful in answering the question: "If a server is running
  26. now, how long is it likely to stay running?" This makes it a good
  27. choice for picking servers for streams that need to be long-lived.
  28. WFU is useful in answering the question: "If I try connecting to
  29. this server at an arbitrary time, is it likely to be running?" This
  30. makes it an important factor for picking guard nodes, since we want
  31. guard nodes to be usually-up.
  32. There are other questions that clients want to answer, however, for
  33. which the current flags aren't very useful. The one that this
  34. proposal addresses is,
  35. "If I found this server in an old consensus, is it likely to
  36. still be running at the same address?"
  37. This one is useful when we're trying to find directory mirrors in a
  38. fallback-consensus file. This property is equivalent to,
  39. "If I find this server in a current consensus, how long is it
  40. likely to exist on the network?"
  41. This one is useful if we're trying to pick introduction points or
  42. something and care more about churn rate than about whether every IP
  43. will be up all the time.
  44. Implementation:
  45. I propose we add a new flag, called "Longterm." Authorities should
  46. set this flag for routers if their Longevity is in the upper
  47. quartile of all routers. A router's Longevity is computed as the
  48. total amount of days in the last year or so[*] for which the router has
  49. been Running at least once at its current IP:orport pair.
  50. Clients should use directory servers from a fallback-consensus only
  51. if they have the Longterm flag set.
  52. Authority ops should be able to mark particular routers as not
  53. Longterm, regardless of history. (For instance, it makes sense to
  54. remove the Longterm flag from a router whose op says that it will
  55. need to shutdown in a month.)
  56. [*] This is deliberately vague, to permit efficient implementations.
  57. Compatibility and migration issues:
  58. The voting protocol already acts gracefully when new flags are
  59. added, so no change to the voting protocol is needed.
  60. Tor won't have collected this data, however. It might be desirable
  61. to bootstrap it from historical consensuses. Alternatively, we can
  62. just let the algorithm run for a month or two.
  63. Issues and future possibilities:
  64. Longterm is a really awkward name.