[tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."

[Tor Bug Tracker & Wiki]

#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
 Reporter:  arma                         |          Owner:                    
     Type:  enhancement                  |         Status:  needs_review      
 Priority:  normal                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                          |        Version:                    
 Keywords:  tor-client, MikePerry201210  |         Parent:                    
   Points:                               |   Actualpoints:  8                 
-----------------------------------------+----------------------------------

Comment(by mikeperry):

 Replying to [comment:9 nickm]:
 > >In my testing, any amount of integer truncation eventually led to the
 accumulation of enough roundoff error for us to either overcount or
 undercount. It was only a matter of time for larger values.
 > >
 > >I commented the scale_factor and mult_factor functions to be more clear
 about the fact that we only scale if there is no integer truncation, and
 that this means we should be careful when changing those parameters.
 >
 > Hm. I am still not comfortable about this.  Can we think about what this
 implies for possible values for those scaling factors? It seems possible
 (though unlikely) to wind up with a sequence of events in which we can
 *never* scale downwards, even with scale_factor == 2.  If you're worried
 about integer roundoff, mightn't the answer be instead to make sure that
 the scale threshold is high, and to perform rounding rather than
 truncating division?

 Hrmm.. I'm pretty sure rounding will only reduce the error.. It can still
 accumulate.. Bleh. I'm not seeing any clear way forward here, save for
 switching everything to floating point. :/

 > > This discrepancy turns out to be due to the hidden service cases in
 that function. There is no discrepancy for normal exit circuits.. It also
 is likely the source of potentially deeper issues with proper timeout
 usage for hidden service circuits...
 >
 > Ouch.  So I'm assuming this is in "don't merge it right now" state then?
 Could there be some way to re-think the design so that we *can't*
 overcount/undercount?  Perhaps to have a flag that's set the first time we
 count something or render it uncountable, so we can't double-count it?  Or
 is this not an overcounting/undercounting thing?

 Yeah, so the discrepancy I'm talking about wrt hidden services is not for
 the defense. It's for the informational "You've had these many failures
 count as timeouts" part of the log. The issue is in how
 circuit_expire_building deals with CBT. It's probably actually a separate
 bug.

 The actual success counts are already enforced with such a state flag.

 However, yeah, I'm still testing with this branch. Don't merge it just
 yet.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7157#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online