Re: Proposal 164: Reporting the status of server votes

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

On Sun, Jun 14, 2009 at 02:40:05AM -0400, Roger Dingledine wrote:
> On Fri, May 22, 2009 at 03:00:42AM -0400, Nick Mathewson wrote:
> >        - Look through your log for reports of what the authority said
> >          when you tried to upload.
> > 
> >        - Look at the consensus; see if you're listed.
> > 
> >        - Wait a while, see if things get better.
> > 
> >        - Download the votes from all the authorities, and see how they
> >          voted.  Try to figure out why.
> 
> Mere mortals can't do this step either. It involves fetching a secret
> only-mentioned-in-the-spec URL ("/tor/status-vote/current/authority")
> from a set of secret only-mentioned-in-the-code IP addresses.
> 
> >        - If you think they'll listen to you, ask some authority
> >          operators to look you up in their mtbf files and logs to see
> >          why they voted as they did.
> 
> In practice, it's sufficient to ask an authority operator to go look
> through the "v3-status-votes" file in their datadir that gets written
> every voting period, and see what the recent votes have said about
> your relay.
> 
> >    This is far too hard.
> > 
> > Solution:
> > 
> >    We should add a new vote-like information-only document that
> >    authorities serve on request.  Call it a "vote info".  It is
> >    generated at the same time as a vote, but used only for
> >    determining why a server voted as it did.  It is served from
> >    /tor/status-vote-info/current/authority[.z]
> > 
> >    It differs from a vote in that:
> > 
> >    * Its vote-status field is 'vote-info'.
> > 
> >    * It includes routers that the authority would not include
> >      in its vote.
> > 
> >      For these, it includes an "omitted" line with an English
> >      message explaining why they were omitted.
 [...]
> >    * It includes info on routers all of whose descriptors that
> >      were uploaded but rejected over the past few hours.  The
> >      "r" lines for these are the same as for regular routers.
> >      The other lines are omitted for these routers, and are
> >      replaced with a single "rejected" line, explaining (in
> >      English) why the router was rejected.
> 
> How does the 'omitted' line differ from the 'rejected' line?

An omitted router is one that we know a descriptor for but don't want
to include in our vote (usually because it isn't running).  A rejected
descriptor is one that we refused to even store when it was uploaded
to us.

> Also, this reminds me of a wishlist item that Robert Hogan had a while
> back. He wants to know how many Tors are configured to be relays, but
> fail their self-reachability checks, so don't even try to publish. If
> it's hundreds or thousands, that means we should work harder to help
> users learn that they're not helping out in the way they think they are.

Sounds like something that could use a proposal, yeah.

> >    A status site (like Torweather or Torstatus or another
> >    tool) can poll these files when they are generated, collate
> >    the data, and make it available to server operators.
> 
> Sounds like a fine plan. I agree that this would be a helpful feature
> to have. But it's also not upgrade-path-critical in the way that a lot
> of the other pending proposals are -- we could do it in 0.2.2 or 0.2.3
> or later and nothing else would have to change to accommodate.

Agreed.

> Also, it can be done pretty well by a) teaching users to read their logs,
> which they're already not so bad at if they're the sort of users who know
> how to realize that this vote-info stuff exists, and b) teaching sites
> like torstatus to fetch the secret URLs from the secret IP addresses and
> crunch the vote data that's already available. This proposal only really
> adds help for folks who can't find their logs, and folks who want to
> know why they're not marked Stable (answer: "you're not stable enough;
> oh, and bug 969").

We can maybe also add some controller features to substitute for (a)
with people who use guis.

> So: if you are itching to do it (or somebody else is), by all means go
> for it. But if it seems like a big pile of hassle (and some of the ideas
> above are pretty invasive and tricky to do efficiently), feel free to
> put it off indefinitely.
>
> Here's an alternative proposal: I set up a cron job on moria to copy
> moria1's v3-status-votes file to someplace web-accessible, and then we
> tell the torstatus folks that they can fetch it and parse it if they
> want to?

Sounds like a good start.  It would be even better to keep a
(rolling?) backlog of status votes, so that we can look into questions
like "why is this server only listed in 1/3 consensuses?"

I think I'll decide that I agree with you on the relative non-urgency
of this, and put it off until somebody feels like doing it.

yrs,
-- 
Nick