[tor-dev] Using the consensus-health web page to debug the Tor network

[Karsten Loesing]

On 9/25/13 5:45 AM, Damian Johnson wrote:
>> I think Roger uses it in his role as network debugger, not as authority
>> operator.  There may be more people wanting to help with network
>> debugging who are not authority operators.  And there may be expert
>> relay operators who are wondering why their relay isn't listed or isn't
>> listed with a given flag.
> 
> I would be really surprised if relay operators, even expert ones, find
> the table useful.

I disagree.  It's useful information to know if some authorities don't
assign flags or assign extra flags to a relay.  That can help explain
why the relay sometimes gets the flag if some of the authorities don't
vote.  Or in case of Named/Unnamed and Exit/BadExit, the flags contained
in votes can help explain why a relay gets the Named or Exit flag.
There may be more examples.  Sure, this is like debug information, and
not many relay operators will understand what's going on there.  But
saying that the information contained in the table is not useful is not
correct.

> That said, on irc Roger mentioned that he finds the
> table handy for finding trends he previously didn't know to look for.
> I suspect he's the only person using it for that, but it's both a
> reasonable use case and one that's frustratingly tricky to provide a
> good solution for that's also useful to others...

I have to say that I don't fully understand how skimming through the
table provides an even basic understanding of trends.  The table that
shows the overlap between votes and consensuses would be a better start
to discover trends:

https://metrics.torproject.org/consensus-health.html#overlap

(I didn't mention this, but I'd expect a replacement tool, CLI or
web-based, to provide such a summary, too.)

>> A command-line tool doesn't sound too crazy.  That tool (or suite of
>> scripts) should be able to cache downloads and votes and share them
>> among all queries we might want to ask it.
> 
> Agreed, this is a capability I'd *love* to have...
> 
> https://trac.torproject.org/projects/tor/ticket/9351
> 
> One bit I'm not sure how to address is cache invalidation. We can
> check when a descriptor has expired, but not when it is no longer the
> freshest.

Consensuses and votes contain these lines:

valid-after 2013-09-25 13:00:00
fresh-until 2013-09-25 14:00:00
valid-until 2013-09-25 16:00:00

You could invalidate consensuses and votes after fresh-until.  Checking
when a server descriptor or extra-info descriptor is not used anymore is
slightly more difficult and probably requires looking at dir-spec.txt or
the code.  (We can move this discussion to the ticket.  Feel free to
paste this there if it's useful.)

>>  $ ./doctor --download
>>  $ ./doctor --flag moria1:Running --flag maatuska:Running --noflag
>> consensus:Running --count
> 
> I think you're misunderstanding my suggestion. My proposal is to
> *teach* Roger to write or adapt scripts to solve his questions. This
> would both empower him to answer more interesting questions than he
> presently can and, in the long run, save him time. I would be more
> than happy to write the first dozen, which he could then use to both
> learn stem and adapt to answer similar questions.
> 
> I'm not proposing a new tool. Rather, I'm suggesting that I teach a
> man to fish. ;)

Not sure if that's going to swim.  Is it really a good use of Roger's
time to write or adapt Python scripts?  I guess he can answer that
better than I (though I'm not sure it's a good use of his time to follow
this thread ;)).  However, we shouldn't be developing this tool just for
Roger, because hopefully other people care about debugging the network,
too.  Just imagine what Tor devs would want to use whenever somebody
shows up on #tor and asks why their relay doesn't have this or that
flag, and imagine what's the easiest way to share results with the relay
operator.

Thanks for your efforts here!

All the best,
Karsten