[tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  (none)
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  documentation tor-client manpage     |  Actual Points:
  easy 043-can extra-review                      |
Parent ID:  #4310                                |         Points:  0.5
 Reviewer:  catalyst                             |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by catalyst):

 Replying to [comment:6 swati]:
 > Thanks, Taylor. Regarding your comment about renaming the section to
 'Circuit Timeout Options', I see that I have added DormantClientTimeout
 and DormantTimeoutDisabledByIdleStreams options to this section. Are these
 two circuit options as well?

 I see. I think you're right there. They're client options that aren't
 directly related to circuit timeouts. They might belong in a separate
 section about Dormant mode?

 > Also, should I add the following circuit options to this section:?

 Unfortunately, I think these are a little bit tricky to classify. Maybe we
 want to expand the section heading to include client circuit behavior
 overall? (The Nodes options have to do with the details of building a
 circuit, while many of these operations are at a higher level of
 abstraction that ignores individual nodes in a circuit.)

 > MaxCircuitDirtiness

 I think this is not directly timing related? This is related to reusing a
 circuit for multiple application streams. I think there is a tradeoff
 between circuit reuse (for efficiency and decreased latency) and traffic
 analysis risk.

 > MaxClientCircuitsPending

 I'm not quite sure how this one interacts with timing.

 > CircuitPadding
 > ReducedCircuitPadding

 I think these aren't directly timing-related. These options are related to
 a countermeasure that we use against traffic analysis. There is a tradeoff
 because the countermeasure can increase bandwidth consumption. (I guess in
 situations of highly constrained bandwidth it could decrease performance
 in a user-visible way.)

 > NewCircuitPeriod
 > PathsNeededToBuildCircuits

 These help tor decide when to build new circuits.
 PathsNeededToBuildCircuits is a bit more strongly related to the
 bootstrapping process than the other options here, so I'm not quite sure
 whether it belongs with the others.

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