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

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

#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, nickm                      |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by swati):

 Replying to [comment:8 catalyst]:
 Currently, there are only four Dormant mode options in the manual -
 DormantCanceledByStartup, DormantOnFirstStartup, DormantClientTimeout and
 DormantTimeoutDisabledByIdleStreams. Do you think we can have a separate
 section for dormant mode with just these four options? If yes, I'll put
 them out from here and create a new section.

 > 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:10>
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