[tor-bugs] #33391 [Metrics/Onionperf]: Add new metadata fields and definitions

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Apr 9 16:54:27 UTC 2020


#33391: Add new metadata fields and definitions
-----------------------------------------+------------------------------
 Reporter:  acute                        |          Owner:  metrics-team
     Type:  enhancement                  |         Status:  needs_review
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Onionperf            |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33323                       |         Points:  1
 Reviewer:  karsten                      |        Sponsor:
-----------------------------------------+------------------------------

Comment (by acute):

 On Monday, irl, karsten and I discussed three ways of identifying data
 coming from different instances of Onionperf:

 1. By source. Here we rely that sources are named in a certain way, or
 come from a certain domain.
 Pros: The easiest method to implement, no changes required in OP.
 Cons: Does not scale, and relies on us/others remembering conventions and
 occasionally even updating metrics-web in the future

 2. Using a fixed field to record whether the data is experimental or not.
 This could be true by default, and we could set this to false for the
 instances we run.
 Pros: Easy to implement, is the field we would rely on in the near future
 Cons: Cannot be changed later on to include other types of measurements,
 does not allow any granularity for the researchers to differentiate
 between their own experiments

 3. The method described in my first comment, using a variable METADATA
 field. This would be populated by the researcher/admin with useful
 information, and then added to the json and tpf outputs when analysis is
 performed.

 Pros: Very flexible, allows the admins/researchers to include a wide
 variety of metadata. Would not put any restrictions on what we can add in
 the future. Simple to implement.
 Cons: Relies on the researcher or admin to populate. It would require
 custom code to parse if used in metrics-web, and then to be useful in
 metrics-web everyone should agree on semantics.

 \\

 >Just one question: What's the point of adding that optional argument to
 the measure mode? Would the >meta data be included in the logs somewhere
 for the analyze mode to extract?
 The default measure mode calls on the analysis function at midnight - the
 analysis function would append the metadata info to the json and tpf
 output, but we need a way to signal that we want this data appended.

 Let me know if I've missed anything!

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


More information about the tor-bugs mailing list