[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #34257 [Metrics/Onionperf]: Analyze unusual distribution of time to extend to first hop in circuit
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs