[tor-bugs] #2004 [Tor Client]: Capping descriptor build times notice log

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Dec 7 06:06:29 UTC 2010


#2004: Capping descriptor build times notice log
------------------------+---------------------------------------------------
 Reporter:  Sebastian   |       Owner:  mikeperry         
     Type:  defect      |      Status:  assigned          
 Priority:  normal      |   Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client  |     Version:                    
 Keywords:              |      Parent:                    
------------------------+---------------------------------------------------

Comment(by arma):

 Replying to [comment:6 Sebastian]:
 > Erm. So that means we don't go to gradually worse timeouts?

 We do, in the general case. This hack is to handle the case where the
 distribution that Mike decided best fit the timeouts decides that your
 "80% percentile" timeout is actually higher than any observed circuit
 build time. This edge case can happen when you have too many right
 censored inputs, i.e. when too many circuits take more than twice the
 timeout so we give up on them.

 The real problem here is that the distribution Mike picked is more complex
 than it needs to be, leading to weird hacks to try to make it realistic
 again, like the one we're talking about here.

 >What happens when you have an insanely low timeout, your network becomes
 worse, and almost all your circuits fail except really few don't, but we
 never have a circuit timing out slower than our slowest timeout so far,
 but not worse than twice as slow?

 I don't know. Would that situation ever happen? It seems a very funny-
 shaped situation. Why would no circuits ever finish in the [x, 2x]
 interval but we would still want to raise x? I guess we could fit this
 with another hack where we don't cap it if x is less than some number.

 This whole timeout calculation algorithm is a mess. Mike, how can we go
 about simplifying it, ditching the right censoring part, etc? It doesn't
 have to be perfect according to the math, it has to be approximately
 correct and simple to analyze and verify.

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


More information about the tor-bugs mailing list