[tor-bugs] #3443 [Tor Client]: Client with low CBT can't switch to a bridge if it's slow

[Tor Bug Tracker & Wiki]

#3443: Client with low CBT can't switch to a bridge if it's slow
------------------------+---------------------------------------------------
 Reporter:  arma        |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  major       |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Client  |        Version:                    
 Keywords:  regression  |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by ioneyes):

 Replying to [comment:15 ioneyes]:

 In summary. Tor appears to be behaving as expected. A low
 CircuitBuildTimeout (too low for the current network) will result in
 circuits timing out before Tor gets a chance to build them.

 From testing it seems you have to allow at least 2 seconds of circuit
 build time for every second of ping response time on the current network.
 This seems to give Tor the time it needs to build circuits.

 It also gives Tor enough latitude to increase its CircuitBuildTimeout in
 conjunction with the pareto distribution its modelled on, when a network
 connection speed reset (to a slower responding network) occurs.

 > Tor is capable of tracking quite large ( a ratio I have seen of up to
 1:10 ) differences in response time from varying networks.
 >
 > To test this I ran Tor and switched in a slower network (Mobile GSM) and
 then a faster network (DSL) letting it settle in between switching.
 >
 > The key is to use a CircuitBuildTimeout that allows for circuits to
 build on the slower network.
 >
 > I have a graph that illusrates Tor's 'tracking' ability.
 >
 > The graph, Graphs - LAN to Dialup.jpg, reveals ping responses on the
 left.
 > In Blue is the ping time seen on the GSM (slower) network and in green
 the DSL (faster) network.
 >
 > It is clearly higher for GSM.
 >
 > On the right is the observed Network Reset Timeout as the networks are
 switched with each other. It does seem to cope. The secret is to make sure
 CircuitBuiltTimeout is larger than you largest expected latency in
 seconds.
 > Obviously if the network does not allow circuit creation within the
 CircuitBuildTimeout there will be no circuits available to move traffic.
 >
 > Or... I have got it all wrong...

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