[tor-dev] Review of Proposal 164: Reporting the status of server votes (was: Tor proposal status (December 2013))

[Karsten Loesing]

On 12/17/13 10:31 PM, Nick Mathewson wrote:
> 164  Reporting the status of server votes
> 
>      This proposal explains a way for authorities to provide a
>      slightly more verbose document that relay operators can use to
>      diagnose reasons that their router was or was not listed in the
>      consensus.  These documents would be like slightly more verbose
>      versions of the authorities' votes, and would explain *why* the
>      authority voted as it did.  It wouldn't be too hard to
>      implement, and would be a fine project for somebody who wants
>      to get to know the directory code. (5/2011)

Hi Nick,

I very much like this proposal!  I want to help move it forward and
integrate the additional information into Onionoo, so that people can
diagnose the network better.  Knowing why an authority rejected a
descriptor, when it last performed a successful and an unsuccessful
reachability test, why it didn't include a relay in its vote, why it
assigned which relay flags, etc. can be very helpful information.

Here's some feedback:

- The URL /tor/status-vote-info/current/authority[.z] doesn't really fit
into the schema that prefixes everything related to the voting process
with /tor/status-vote/(next|current)/.  A more consistent choice would
be /tor/status-vote/current/vote-info[.z].

- The WFU and MTBF thresholds are already contained in votes in
"flag-thresholds" lines since February 2013 (admittedly, four years
after the proposal was written).  We should either use the same line
format in vote-info documents, or leave out flag thresholds here.

- The proposal says in two places that explanations should be given in
English.  The better approach, IMO, would be to enumerate all possible
explanations in dir-spec.txt and assign error codes to them.  Reasons
include: a) requires fewer bytes in an authority's memory; b) requires
fewer bytes in vote-info documents; c) easier for applications to
process vote-info documents; d) forces us to enumerate reasons for
rejecting a router descriptor or not including a router in a vote and
explicitly specify them in dir-spec.txt.  (Happy to help enumerating
reasons.)

- I'd want to make the format of vote-info documents more compact,
though I don't have a good suggestion yet.  (But I also didn't want to
delay sending this email, so here's my half-baked thought.)  Ideally,
every status entry has one "r" line to identify the relay and then one
line per noteworthy event.  Noteworthy events are: a) the authority
receives a router descriptor and decides whether to accept or reject it;
b) the authority performs a reachability test that is either successful
or not; c) the authority produces a vote document and decides whether to
include a relay and what flags to assign.  (Are there more events that
are worth including?)  I'm aware that you mentioned the same information
in the proposal, I'm just wondering about better ways to represent it.
As I said, this thought is only half-baked and will hopefully become
clearer when going through the code.

- The proposal says under "Risks" that it doesn't make provisions for
caching these documents.  But authorities have to cache these documents!
 An authority can only generate a vote-info document at the same time as
it generates a vote document.  Any later attempts to say why it voted
the way it did would require the authority to keep state that it doesn't
need for anything else.  The authority should simply write its vote-info
document to disk and serve it whenever somebody asks for it.  (To be
extra precise, it should only serve a vote-info document when the
consensus becomes valid.)

There, that concludes my review of directory-protocol related proposals.
 Looking forward to what you think.  Please let me know how I can best
move these proposals forward, e.g., by writing patches to the proposals
or dir-spec.txt, by writing code, etc.

All the best,
Karsten