Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:15:33Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33323O2.1 Add instance metadata: We need a way to distinguish our current four lon...2020-06-13T18:15:33ZGabagaba@torproject.orgO2.1 Add instance metadata: We need a way to distinguish our current four long-term OnionPerf measurements that are automatically published to the Metrics portal from short-term experimental measurements.In this task, we will add instance metadata to OnionPerf’s results in order to differentiate each experiment; we will store that data along with the actual measurement data in a separate, single archive. Without this task, we will be una...In this task, we will add instance metadata to OnionPerf’s results in order to differentiate each experiment; we will store that data along with the actual measurement data in a separate, single archive. Without this task, we will be unable to distinguish the new experiments from the currently running OnionPerf instances, which makes the data collected unusable.https://gitlab.torproject.org/legacy/trac/-/issues/34261Remove pandas warning when using bullseye version of pandas2020-06-13T18:04:41ZKarsten LoesingRemove pandas warning when using bullseye version of pandasThe following warning is shown when using OnionPerf's visualize mode with version 0.25.3 of pandas (contained in Debian bullseye). It is not shown when using buster's version of pandas. If there's an easy way to remove the warning when u...The following warning is shown when using OnionPerf's visualize mode with version 0.25.3 of pandas (contained in Debian bullseye). It is not shown when using buster's version of pandas. If there's an easy way to remove the warning when using either version, let's do it.
```
/usr/lib/python3/dist-packages/pandas/plotting/_matplotlib/converter.py:103: FutureWarning: Using an implicitly registered datetime converter for a matplotlib plotting method. The converter was registered by pandas on import. Future versions of pandas will require you to explicitly register matplotlib converters.
To register the converters:
>>> from pandas.plotting import register_matplotlib_converters
>>> register_matplotlib_converters()
warnings.warn(msg, FutureWarning)
```Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34218Split PROXY errors into whatever reasons are given in TorCtl logs2020-06-13T18:04:37ZKarsten LoesingSplit PROXY errors into whatever reasons are given in TorCtl logsIf we combine TGen transfers with Tor streams and circuits we can learn a lot more about why our proxy (Tor) failed. Including that information in visualizations might be very useful.
When we match TGen transfers with TorCtl events, we'...If we combine TGen transfers with Tor streams and circuits we can learn a lot more about why our proxy (Tor) failed. Including that information in visualizations might be very useful.
When we match TGen transfers with TorCtl events, we'll have to look [how metrics-lib does this](https://gitweb.torproject.org/metrics-lib.git/tree/src/main/java/org/torproject/descriptor/onionperf/OnionPerfAnalysisConverter.java).
Maybe we can use some ideas from #30612 where we discussed putting an error code graph on Tor Metrics.https://gitlab.torproject.org/legacy/trac/-/issues/34217Include partial downloads in existing TTLB graphs2020-06-13T18:04:37ZKarsten LoesingInclude partial downloads in existing TTLB graphsWith #26673 being resolved we should include partial downloads in existing TTLB graphs. Maybe there's a way to put less emphasis on the different file sizes and combine the various partial downloads in a single TTLB graph.With #26673 being resolved we should include partial downloads in existing TTLB graphs. Maybe there's a way to put less emphasis on the different file sizes and combine the various partial downloads in a single TTLB graph.https://gitlab.torproject.org/legacy/trac/-/issues/34215Harmonize TTFB/TTLB definitions with Tor Metrics plots2020-06-13T18:04:36ZKarsten LoesingHarmonize TTFB/TTLB definitions with Tor Metrics plotsRight now, OnionPerf plots 'command' to 'first_byte', whereas Tor Metrics plots 'start' to 'first_byte' (as found in #33258). We should harmonize these definitions, which likely means using what we have been using for Tor Metrics plots f...Right now, OnionPerf plots 'command' to 'first_byte', whereas Tor Metrics plots 'start' to 'first_byte' (as found in #33258). We should harmonize these definitions, which likely means using what we have been using for Tor Metrics plots for the past decade.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34214Remove existing Tor control log visualizations2020-06-13T18:04:36ZKarsten LoesingRemove existing Tor control log visualizationsAs found in #33258, the existing Tor control log visualizations are not really useful to us. Let's consider removing them.
As part of this change, we should rename the TGen visualizations .pdf and .csv to something starting with `onionp...As found in #33258, the existing Tor control log visualizations are not really useful to us. Let's consider removing them.
As part of this change, we should rename the TGen visualizations .pdf and .csv to something starting with `onionperf.*`, as these files will contain parts from TGen and TorCtl in the future (error codes from TorCtl logs, measurements filtered by relay fingerprints).Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34213Replace TorCtlParser with OnionTrace's control log parser2020-06-13T18:04:35ZKarsten LoesingReplace TorCtlParser with OnionTrace's control log parserSimilar to our plan to use TGen's analysis.py instead of OnionPerf's in #33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much work this is...Similar to our plan to use TGen's analysis.py instead of OnionPerf's in #33974, the idea would be to avoid keeping our own copy of a Tor control even log parser in OnionPerf.
This work should start with an analysis how much work this is going to save in the long run, and whether that justifies adding another dependency.
Feel free to adjust estimated points before starting to work on this if 2.0 doesn't make any sense.https://gitlab.torproject.org/legacy/trac/-/issues/33325O2.3 Implement static guard node support for OnionPerf.2020-06-13T18:04:15ZGabagaba@torproject.orgO2.3 Implement static guard node support for OnionPerf.Tor clients generally make three-hop circuits (that is, paths that go through three relays). The first position in the path called the guard node and is always chosen as the first hop for a fixed period of time. Using static guard nodes ...Tor clients generally make three-hop circuits (that is, paths that go through three relays). The first position in the path called the guard node and is always chosen as the first hop for a fixed period of time. Using static guard nodes help protect against a certain kind of anonymity-breaking attack. The long-running OnionPerf instances that are currently deployed do not implement this mitigation because choosing a static guard at setup time would heavily influence their measured performance. Instead, they’re configured not to choose a guard for each measurement. We want to be able to measure the effects of good, bad, or average guards and compare the results, which is not possible without the opportunity to select a static guard node for an OnionPerf instance. Implementing the option to use a static guard in future OnionPerf instances will allow us to measure Tor performance closer to how clients experience it.https://gitlab.torproject.org/legacy/trac/-/issues/33324O2.2 Develop at least one new OnionPerf model: An OnionPerf model defines the...2020-06-13T18:04:15ZGabagaba@torproject.orgO2.2 Develop at least one new OnionPerf model: An OnionPerf model defines the pattern of traffic that is generated by the instances for conducting a measurement.For example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client s...For example, a bulk download model can be used to measure time to first byte and time to last byte simulating the download of a large file. In contrast, a ping/echo service model would be used to learn the round-trip time from a client sending a ping to receiving a pong back from a server, which more closely models a real-time chat application. These models allow us to evaluate distinct circumstances and collect distinct metrics, all of which are currently unavailable with the existing OnionPerf model. We will evaluate new OnionPerf models that will allow us to measure different network workloads and deploy at least one instance of these permanently. Deploying a new OnionPerf model allows us to gain new insight into the Tor network by taking measurements that are currently unavailable.https://gitlab.torproject.org/legacy/trac/-/issues/33259Store measurements in a local database to reduce plotting time2020-06-13T18:04:09ZKarsten LoesingStore measurements in a local database to reduce plotting timeWe want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing st...We want to add graphs to OnionPerf that compare larger numbers of measurements. We also plan to add more parameters to plot different subsets of measurements. Having a local database for storing measurements and decoupling the parsing step from the plotting step might reduce overall plotting time. This will be particularly useful when we include graphs based on Tor descriptors like flags or bandwidth or consensus weight.
Part of this ticket will be to figure out which database to use. Maybe we need to experiment with SQLite to see if it's fast enough for this purpose or whether we need something like PostgreSQL here.https://gitlab.torproject.org/legacy/trac/-/issues/30798Develop and deploy tgen model resembling ping2020-06-13T18:04:04ZKarsten LoesingDevelop and deploy tgen model resembling pingAt last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every fiv...At last week's tor-scaling meeting we discussed developing a second tgen model that resembles a ping service and deploying an OnionPerf instance with that model.
The current default tgen model in OnionPerf makes a new download every five minutes. That's a tiny request with a response of 50 KiB or 1 MiB or 5 MiB.
This new model would send a tiny request once per second for, say, five minutes, and receive a tiny response back to each of these requests.
We wouldn't have to write analysis code that produces something like a .tpf file right now but could start with analyzing the raw logs for this experiment and extract some hopefully useful visualizations.
I could deploy this new model on my local machine (if it uses an onion service).
Raising priority to high, because it would be great to ideally get this deployed before All Hands.
Thoughts?https://gitlab.torproject.org/legacy/trac/-/issues/29370Measure mode with arbitrary tgen traffic models2020-06-13T18:03:52ZirlMeasure mode with arbitrary tgen traffic modelsonionperf measure currently runs using a Torperf-like measurement model by default. We should allow any tgen model to be given on the command line, and then our tgen client should use that model instead.
(Copied from https://github.com/...onionperf measure currently runs using a Torperf-like measurement model by default. We should allow any tgen model to be given on the command line, and then our tgen client should use that model instead.
(Copied from https://github.com/robgjansen/onionperf/issues/9)Ana CusturaAna Custura