Re: [tor-bugs] #24228 [Core Tor/Tor]: Tor keeps on creating new circuits even when it's idle

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24228: Tor keeps on creating new circuits even when it's idle
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.1.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-circuit, regression,             |  Actual Points:
  backport-031                                   |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:13 asn]:
 > Replying to [comment:10 mikeperry]:
 > > The goal is to learn a circuit build timeout within 30 minutes, so
 that unused orconn connections aren't padded for too long while we learn
 this timeout (which wastes bandwidth for clients that want less padding).
 It sounds like we may actually learn it within 10. We could make this 3X
 slower I suppose.
 > >
 > > But I don't really think new clients are going to put that much of a
 strain on the network with this. The ntor handshake completes in tens of
 microseconds, IIRC. And the rate of new clients arriving is not that high.
 >
 > Hmm, not sure if it's just new clients. IIRC, CBT is per-guard, so when
 a client switches to a new guard (or its current guard gets
 offline/unreachable), it will start learning CBT of its next guard, aka
 destroy and create tons of idle circs over time.

 CBT is not per-guard. I first wrote it back when we used 3 guards, and
 does not associate any state with a guard id. It is only reset if you time
 out 18 out of 20 circuits in a rolling window. Otherwise it just gradually
 adjusts to changes like this.

 Maybe you were confusing it with path bias? That info is per guard.

 > Why is it important to learn CBT fast? What would happen if we learned
 CBT over a longer period of time, and used a bigger idle timeout value so
 that we don't destroy so many idle circuits?

 As I said to Catalyst, and in my previous comments, I lowered the CBT
 learning time so that we don't waste client battery and bandwidth on
 padding while keeping client connections opened for huge amounts of time
 while building test circuits. We're talking about the cost of crypto ops
 that take microseconds to complete vs the overhead of radio activity, CPU
 wake time, and bandwidth costs for keeping padded connections opened for
 *hours*.

 > Alternatively, perhaps we could disable the predictive circuit building
 while we area learning CBT for a guard? Or is this too much effort?

 I don't think this accomplished what we want. Again, the point is to get
 the circuit building out of the way quickly, so we don't waste resources
 on keeping connections opened forever (and needlessly padding them during
 that time).

 That said, 10 minutes *is* 3X faster than we really need. We could lower
 this by a factor of three and still get it done inside of the connection
 idle time for reduced padding clients.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs