146-long-term-stability.txt 3.3 KB

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