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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

Comment (by 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.

 >  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.

 >  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.

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

 Agreed.

 >  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.

 >
 > 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22122#comment:8>
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