[tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

[Tor Bug Tracker & Wiki]

#34303: Find out why onion service measurements have gotten slower
-------------------------------+--------------------------------
 Reporter:  karsten            |          Owner:  karsten
     Type:  defect             |         Status:  accepted
 Priority:  Medium             |      Milestone:
Component:  Metrics/Onionperf  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:  Sponsor59-must
-------------------------------+--------------------------------
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  new => accepted


Comment:

 Okay, I think I know what the issue is: Tor stopped cannibalizing circuits
 which do not have a current guard as their first hop in 0.3.3.2-alpha
 (#24469). While this seems useful in the common case, it affects us badly,
 because we're setting `"UseEntryGuards 0"` to avoid using guards at all.

 Here are the latest measurement results with various Tor versions to
 narrow down the issue:

 [[Image(onionperf-2020-05-28.png, 700px)]]

 Some observations:
  - There are two classes of measurement results here which we can
 distinguish very clearly at the median. Things get less clear towards the
 worst-case measurements, but that's likely due to the small number of
 measurements.
  - Versions until 0.3.3.1-alpha (brown line) fall into the "fast" class,
 versions starting at 0.3.3.2-alpha (dark gray) fall into the "slow" class.
  - Version 0.4.4.0-alpha-dev (cyan) is current master with the patch below
 to undo the #24469 change. It falls into the "fast" class. While it looks
 like it's the fastest of all measurements, I doubt that it's any different
 from the other "fast" measurements in the worst case.

 Here's the patch to current master that I used for measurements:

 {{{
 diff --git a/src/core/or/circuitlist.c b/src/core/or/circuitlist.c
 index 4c37ef8b41..35057c5176 100644
 --- a/src/core/or/circuitlist.c
 +++ b/src/core/or/circuitlist.c
 @@ -1946,7 +1946,8 @@ circuit_find_to_cannibalize(uint8_t
 purpose_to_produce, extend_info_t *info,
         * that the Guard was removed from the samepled set after the
 circuit
         * was created so avoid using it. */
        if (!entry_guard_could_succeed(circ->guard_state)) {
 -        goto next;
 +        /* Commented out this bugfix of #24469 to work around bug #34303.
 +        goto next*/;
        }

        if ((!need_uptime || circ->build_state->need_uptime) &&
 }}}

 It would be nice to get this analysis confirmed by a network team person.

 If this is indeed the issue, I think we'll need to change Tor to only
 apply this check if `"UseEntryGuards 1"` is set. This doesn't only affect
 us, it also affects other users who run Tor without guards for whatever
 reasons.

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