[tor-bugs] #34257 [Metrics/Onionperf]: Analyze unusual distribution of time to extend to first hop in circuit

[Tor Bug Tracker & Wiki]

#34257: Analyze unusual distribution of time to extend to first hop in circuit
-------------------------------------------------+-------------------------
 Reporter:  karsten                              |          Owner:
                                                 |  metrics-team
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Metrics/Onionperf                    |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  metrics-team-roadmap-2020, metrics-  |  Actual Points:  1.5
  team-roadmap-2020-june                         |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor59-must
-------------------------------------------------+-------------------------

Comment (by karsten):

 Replying to [comment:20 arma]:
 > Replying to [comment:17 karsten]:
 > > So, what do we do after learning this? Should we work harder on
 tickets like #33399 to avoid setting `UseEntryGuards 0` and to get more
 realistic measurements in the future?
 >
 > You could pretty easily have your Tor client keep an ORConn open, by
 leaving an unused circuit on it (e.g. put it in purpose 'controller' on
 the client side, unless you're using that special purpose in onionperf
 already). Then subsequent circuit builds on the circuit will reuse that
 already open conn. You'd want to have a way to recognize when circuits
 were requested where the ORConn had to be (re)built (e.g. because it's the
 first circuit or because something happened to the old ORConn), so you can
 annotate results from those circuits differently. But that would be one
 way to leave UseEntryGuards at 0 while getting mostly circuits that didn't
 need to wait for a new ORConn.

 I think that what you describe would only work if OnionPerf selected paths
 and built circuits. But that's not the case. OnionPerf only creates
 configuration files and starts processes, and then the `tor` processes
 build all the circuits they need by themselves. Unless I misunderstood
 your suggestion.

 I still think that #33399 is our best bet here. I'll know better after
 having made more progress on that ticket.

 > That leads to another performance research question for the onionperf
 folks. Because ORConns are backbone long-lived TCP connections, their
 throughput takes a while to ramp back up (in terms of TCP windows, slow
 start, etc) if they haven't sent traffic lately. Are ORConns for an
 "active" Tor client, using their guard at this moment, better off because
 the ORConn is already "warm"? Or does this factor not matter much compared
 to other issues like network latency, the tiny amount of bandwidth needed
 for circuit building, etc?
 >
 > And this reminds me of a different issue I was thinking about, based on
 the above graphs. Sometimes two relays won't have an existing ORConn
 connection between them, and so establishing a circuit between the two
 will take longer than it would otherwise. So I would expect a much more
 subtle bimodal distribution for the second hop and the third hop as well,
 where every so often it takes a lot longer than it should, because those
 relays need to reconnect to each other. But on the plus side, *this*
 difference is one that real-world Tor clients will experience too, in the
 same way as onionperf.

 I don't have any data about this, but I'd assume that both effects exist
 but are hard to measure.

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