[metrics-bugs] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf

[Tor Bug Tracker & Wiki]

#22122: Add support for six new key-value pairs added by OnionPerf
---------------------------------+-----------------------------------
 Reporter:  karsten              |          Owner:  metrics-team
     Type:  enhancement          |         Status:  closed
 Priority:  Medium               |      Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |        Version:
 Severity:  Normal               |     Resolution:  implemented
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
 Reviewer:                       |        Sponsor:
---------------------------------+-----------------------------------
Changes (by karsten):

 * status:  merge_ready => closed
 * resolution:   => implemented


Comment:

 Replying to [comment:8 iwakeh]:
 > Replying to [comment:7 karsten]:
 > > Replying to [comment:6 iwakeh]:
 > > > I think there should be an OnionperfResult class that also supports
 the old torperf format.
 > > >
 > > > Eventually, there might be more use cases for the additional data in
 onionperf measurements.
 > > > And, onionperf already adds many keys that are not part of the
 torperf format.
 > > >
 > > > So, all 'torperf' should become 'onionperf' soon.
 > >
 > > After giving this some thoughts I think it's more complicated than
 this.  The reason is that we're using OnionPerf in a kind of Torperf-
 compatibility mode right now, where it uses the same measurement setup
 (with static downloads of 50KB, 1MB, 5MB files) and produces the same data
 format with only minimal additions.
 > >
 > > But we'll soon want to add more realistic measurement setups
 (simulated website downloads), produce a richer data format (probably JSON
 based, IIRC), and present more useful measurement results on Tor Metrics.
 That's what we'll want to call OnionPerf, not what we're doing right now.
 And we'll still want to refer to past measurements and data formats as
 Torperf.
 >
 > Valid concerns.
 >
 > >
 > > How about we:
 > >  1. change the type annotation in .tpf files produced by OnionPerf to
 `@type torperf 1.1`, because that format is still backward compatible to
 `@type torperf 1.0` but adds new fields that a parser for the old format
 does not recognize;
 >
 > Agreed.

 Opened #22263 for this.

 > >  2. keep referring to everything in CollecTor that downloads from
 OnionPerf instances as OnionPerf, because we're really downloading from
 that new tool, not from the old Torperf tool;
 >
 > Agreed.

 Nothing to be done here.

 > >  3. update https://collector.torproject.org/#type-torperf to say that
 these are "Torperf and OnionPerf Measurement Results" and specify what
 fields are new in version 1.1;
 >
 > Agreed.

 Also part of #22263.

 > >  4. leave metrics-lib's `TorperfResults` unchanged and just say that
 it supports new fields added in version 1.1;
 >
 > Agreed.

 Nothing to be done here.  We don't explicitly say which minor versions are
 supported.  Maybe we should, but in that case we should do that for all
 descriptor types.  In any case, this shouldn't block closing this ticket.

 > >  5. rename metrics-web's `onionperf.csv` (beta) to `torperf2.csv`,
 because it still uses the same measurement setup and data format as the
 former `torperf.csv`.  It just adds a new column that makes it backward-
 incompatible with `torperf.csv`.
 >
 > I would suggest `torperf-1.1.csv` to reflect the type version.

 Done.

 > > And how about once we're moving to more complex measurement setups and
 a richer data format in OnionPerf we call that `@type onionperf 1.0`,
 `OnionPerfMeasurement`, `onionperf.csv`, and so on.
 > >
 > > What do you think?
 >
 > That all makes sense. Fine.

 Okay, great.  I think we're done here now.  Thanks for reviewing!
 Closing.

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