: Export END_CIRC_REASON_* to controler

[Mike Perry]

Thus spake Yousifnet (yousifnet at gmail.com):

> 
> >Any thoughts on 
> >http://fscked.org/proj/minihax/SnakesOnATor/fail_reasons 
> >http://fscked.org/proj/minihax/SnakesOnATor/fail_rates ?
> >
> >Useful, not useful, anything additional that might help? Maybe node 
> >version info? 
> >
> >Maybe not useful by itself, but might give you guys an idea if a node
> >needs some special attention/probing/stress testing, or do you already
> >do this w/ your own dev servers?
> >
> >  
> 
> The idea behind SOAT is an excellent one. We are reporting things that 
> would not show up in Tor's logs. The results are rather useful if say 
> someone wants to maintain a high quality of service and ban certain 
> nodes based on the fail rate @ say 4/5 or higher. Also can be used as an 
> indication to node operators of the quality of their nodes. Perhaps you 
> could periodically test nodes and post results with a link at 
> http://wiki.noreply.org/noreply/TheOnionRouter. Though that might 
> discourage bad-node operators. Which is better; a bad node or no node at 
> all?

Yeah.. Well there is a difference between a bad exit node and a bad
protocol node.. Bad exit nodes are fine. They can be easily detected
and flagged to only use as non-exits.

But Paul is right, bad protocol nodes are really hard to detect
automatically and be right.. But I think that if a human is involved
and banging on nodes that the automation thinks is suspicious, we fare
a much better chance. 

However, the quality approach is an interesting idea.. Maybe 
LongLivedPorts or something could make use of stats. I could export
"suspect" fail lists and "actual" failed lists. In the suspect list I
could assume any node caused the failure and count them all as failed.
In the "actual" list I could only count the node that failed to extend
the circuit/actually make the stream connection. May be enlightening
to compare the two to see if either of them look useful for any sort
of reliability info. In the absence of malicious nodes, the "suspect"
list should converge to the "actual" list, plus some noise floor
smeared among the other nodes.

I should also break down these stream failures by reason as well.
There are a lot of them...

So many neat things to investigate, so little time.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs