proposals/164-reporting-server-status.txt

   1 Filename: 164-reporting-server-status.txt
   2 Title: Reporting the status of server votes
   3 Author: Nick Mathewson
   4 Created: 22-May-2009
   5 Target: 0.2.2
   6 Status: Open
   7
   8
   9 Overview:
  10
  11    When a given node isn't listed in the directory, it isn't always easy
  12    to tell why.  This proposal suggest a quick-and-dirty way for
  13    authorities to export not only how they voted, but why, and a way to
  14    collate the information.
  15
  16 Motivation:
  17
  18    Right now, if you want to know the reason why your server was listed
  19    a certain way in the Tor directory, the following steps are
  20    recommended:
  21
  22        - Look through your log for reports of what the authority said
  23          when you tried to upload.
  24
  25        - Look at the consensus; see if you're listed.
  26
  27        - Wait a while, see if things get better.
  28
  29        - Download the votes from all the authorities, and see how they
  30          voted.  Try to figure out why.
  31
  32        - If you think they'll listen to you, ask some authority
  33          operators to look you up in their mtbf files and logs to see
  34          why they voted as they did.
  35
  36    This is far too hard.
  37
  38 Solution:
  39
  40    We should add a new vote-like information-only document that
  41    authorities serve on request.  Call it a "vote info".  It is
  42    generated at the same time as a vote, but used only for
  43    determining why a server voted as it did.  It is served from
  44    /tor/status-vote-info/current/authority[.z]
  45
  46    It differs from a vote in that:
  47
  48    * Its vote-status field is 'vote-info'.
  49
  50    * It includes routers that the authority would not include
  51      in its vote.
  52
  53      For these, it includes an "omitted" line with an English
  54      message explaining why they were omitted.
  55
  56    * For each router, it includes a line describing its WFU and
  57      MTBF.  The format is:
  58
  59        "stability <mtbf> up-since='date'"
  60        "uptime <wfu> down-since='date'"
  61
  62    * It describes the WFU and MTBF thresholds it requires to
  63      vote for a given router in various roles in the header.
  64      The format is:
  65
  66        "flag-requirement <flag-name> <field> <op> <value>"
  67
  68      e.g.
  69
  70        "flag-requirement Guard uptime > 80"
  71
  72    * It includes info on routers all of whose descriptors that
  73      were uploaded but rejected over the past few hours.  The
  74      "r" lines for these are the same as for regular routers.
  75      The other lines are omitted for these routers, and are
  76      replaced with a single "rejected" line, explaining (in
  77      English) why the router was rejected.
  78
  79
  80    A status site (like Torweather or Torstatus or another
  81    tool) can poll these files when they are generated, collate
  82    the data, and make it available to server operators.
  83
  84 Risks:
  85
  86    This document makes no provisions for caching these "vote
  87    info" documents.  If many people wind up fetching them
  88    aggressively from the authorities, that would be bad.
  89
  90
  91