[tor-bugs] #17598 [Core Tor/Tor]: Trace cell queue times in Tor to measure Tor application "congestion"

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Feb 26 19:20:29 UTC 2017


#17598: Trace cell queue times in Tor to measure Tor application "congestion"
---------------------------------------------+-----------------------------
 Reporter:  robgjansen                       |          Owner:  pastly
     Type:  enhancement                      |         Status:
                                             |  needs_review
 Priority:  Medium                           |      Milestone:  Tor:
                                             |  unspecified
Component:  Core Tor/Tor                     |        Version:
 Severity:  Normal                           |     Resolution:
 Keywords:  kist, tor-03-unspecified-201612  |  Actual Points:
Parent ID:  #12541                           |         Points:  4
 Reviewer:                                   |        Sponsor:
---------------------------------------------+-----------------------------

Comment (by robgjansen):

 David's tracing branch is great, and I think it will be extremely useful
 for a variety of research and testing purposes. We have already
 implemented and are using a feature that uses the tracing branch to
 measure congestion times of cells in Tor.

 If there are concerns about merging such individual "tracing modules" like
 this, I'd like to offer some reasons why I think it is a good idea to
 merge. Here are some advantages to merging tracepoint modules, in this
 case specifically our cell tracing module:

 * make sure the tracepoints are in the correct spot - future
 researchers/devs that want to measure congestion don't have to make the
 mistakes we first made about where to place the tracepoints
 * very few lines of code added to Tor for cell tracing  (just a few
 tracepoints and a cell id) - most logic is in the cell tracing module
 * the cell tracing feature doesn't get compiled in unless manually setting
 a  configure option
 * the cell tracing module is self contained and private and therefore not
 vulnerable to code rot, the only code that needs to be maintained are the
 tracepoint locations, which are indeed valuable to maintain by those who
 know the codebase and not by researchers/devs who want cell congestion
 data but are not Tor code experts
 * currently, our cell congestion tracing implementation minimizes the
 lines of code changed in Tor, but we could instead opt to provide more
 fine grained tracepoints  - we could trace cell queue times in all of the
 inbuf and outbuf queues separately - more data could mean more useful to
 more researchers

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


More information about the tor-bugs mailing list