146-long-term-stability.txt 3.4 KB

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