[metrics-bugs] #33399 [Metrics/Onionperf]: Measure static guard nodes with OnionPerf

[Tor Bug Tracker & Wiki]

#33399: Measure static guard nodes with OnionPerf
---------------------------------------+--------------------------------
 Reporter:  acute                      |          Owner:  metrics-team
     Type:  enhancement                |         Status:  new
 Priority:  Medium                     |      Milestone:
Component:  Metrics/Onionperf          |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:
Parent ID:  #33325                     |         Points:  4
 Reviewer:                             |        Sponsor:  Sponsor59-must
---------------------------------------+--------------------------------

Comment (by karsten):

 Some thoughts on this ticket:

  - IIRC, we're using `UseEntryGuards=0` for the `tor` process on both
 client ''and'' server side. If we start using guards for a limited time
 now, we should do so on both sides.

  - We should experiment with the time we want to keep guards static. That
 time could range from (a) five minutes for a single measurement, (b) an
 hour, (c) a day, or even (d) several days.
    - A possible downside of changing guards at UTC midnight is that we
 might have a harder time identifying trends over time, because the choice
 of guards might overlay any other changes in the network.
    - If we pick a time that is too short, our results might be blurred by
 the stabilizing phase after choosing new guards.
    - Maybe we need to experiment with something like changing guards every
 hour and analyze how different the first few measurements in that hour are
 from those towards the end of the hour.

  - Rather than removing the `state` file we might try out the `DROPGUARDS`
 controller command which is supposed to achieve the same thing. What it
 might not do is remove circuit build timeout state, but maybe Tor is smart
 enough to consider the event of dropping all guards as drastic enough
 network change to reset the timeout back to the default and send a
 `BUILDTIMEOUT_SET RESET` event---I haven't checked. Note that even after
 going back to defaults, the first measurement or two will likely be
 different from those afterwards, because Tor will have to learn what a
 good timeout is with the new guard(s). Maybe it doesn't matter if we let
 Tor learn itself that something has changed. This is related to the
 previous thought on how often to change guards.

 Leaving this ticket assigned to metrics-team. If somebody wants to grab
 it, please do!

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