#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs