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

[Nick Mathewson]

On Thu, Dec 26, 2013 at 6:05 AM, Karsten Loesing <karsten at torproject.org> wrote:
> 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].

Sounds okay to me.

> - 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.

If they're already in votes, then we should just include them verbatim
in vote-info.  vote-info should not diverge from vote needlessly.

> - 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.)

There will always be more explanations we didn't think of; what if we
do something that uses enumerated error codes *and* explanatory
messages?

The total size of vote-info documents won't actually be affected if we
store them compressed.  Perhaps we should make compression mandatory.

> - 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.)

I meant that these new documents aren't cached at directory caches.
(And they possibly shouldn't be.)  But this opens a risk of creating
more traffic at authorities, which wouldn't be good.

> 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.

For proposal 164, I'd love it if you can patch the proposal to make
the uncontroversial changes above. (that is, the changes that we can
agree on how to do.)

Writing patches to merge stuff into dir-spec isn't useful without
code; we don't change dir-spec until after the code changes, per
001-process.txt.

As for writing code, that sounds fine!  Let me know which ones you're
most interested in working on some time and we can figure out how to
prioritize?

Most of these are currently in "Lorax" status[*], meaning that I agree
that they'd be a good idea, but nobody is currently writing code for
them or making a plan to do so.  (I think I got a partial
implementation of 185 at some point.)  In some cases (like 212) the
biggest issue is testing.




[*] "Unless someone like you cares a whole awful lot
     Nothing is going to get better. It's not!"
         --Dr. Seuss, _The Lorax_
-- 
Nick