Onionperf deployment

Hello, I have finished deploying a test of OnionPerf on OTF Cloud. It can be accessed at: https://199.119.112.144/ (certificate is self signed atm)

Now that we can look at the generated files, we can start thinking and planning about how we want to consume them. I think this is a good moment to decide if we want to include an option to generate a different format within OnionPerf, or we want to write a script to parse the files in a format we can use.

added component::metrics owner::metrics-team priority::medium resolution::fixed severity::normal status::closed type::enhancement labels

Adding a link from our mail conversation to the first analysis: https://github.com/hiromipaw/onionperf-notebook

Changed ticket type to 'enhancement'.

Trac:
Type: defect to enhancement

Hi,

So I have updated the wiki for onionperf: https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure/onionperf Now we have onionperf-one which is in DC, United States, and onionperf-eu which is in Amsterdam.

• onionperf-one in DC: ​https://199.119.112.144

• onionperf-eu in AMS: ​https://37.218.247.40/

I am finishing installing also the tpo instance as I will need some libraries installed there first. I will let you know once this is completed by updating this ticket.

My notebook can be accessed on: https://github.com/hiromipaw/onionperf-notebook And the results can be displayed from https://github.com/hiromipaw/onionperf-notebook/blob/master/transfer_times.html which is basically the quick-n-dirty test I did to make sure measurements made some sense.

I could try to make onionperf measurements available for collector, or maybe you prefer me to do something else instead. I haven't honestly touched Java in a very long time ;)

hiro, I'm having a difficult time reading your results. Can you put them on GitHub Pages or export some images and attach them here? And can you add explanations what your results show and why you consider them close enough to Torperf data that we can switch over? That would be awesome!

Regarding the CollecTor integration, I started hacking on that yesterday evening. No need for you to touch Java just for this. :)

Hi Karsten, sure I will generate some annotated images.

I have started this board: https://github.com/hiromipaw/onionperf-notebook/blob/master/board.md I will be collecting graphs for all the measurements provided by onionperf. At the moment I only have the 50KiB download time but I will be adding more measurements before our meeting tomorrow.

My idea up to this point has been that if I do not find something that it is completely unreasonable when comparing w/ Torperf I assume the measurements (and my analysis) can be considered as accurate.

Talk more tomorrow at the meeting.

Hi,

I have discovered I was making an error in plotting the time differences. In fact I was just plotting the microseconds difference :( Now I have fixed this and it looks more accurate: https://github.com/hiromipaw/onionperf-notebook/blob/master/board.md

Trac:
Cc: karsten, iwakeh to karsten, iwakeh, teor

Looks good to me, thanks! I'd say let's go ahead and include these measurements on Metrics, and if we later find out that there are measurement issues, we can still take broken measurements out. But if nobody looks at the data, nobody will spot any issues.

So, seems like the missing piece is the CollecTor integration. I'll continue working on that.

hiro, can you rename the sources to op-$cc with $cc being the country code where the instance is running in as discussed at the last team meeting?

And can you check why https://37.218.247.40/ is still empty?

And what's the URL for the third instance, or did you not set that up yet?

Thanks!

Oh, and can you look into getting (Let's Encrypt) certificates, maybe using op-$cc.$something as domain names? Otherwise we'll first have to look into ways to tell CollecTor which (self-signed) certificate to expect on each OnionPerf instance, which might be possible but which is probably not trivial. Thanks!

Hi Karsten, I have renamed the op-us and op-nd ones already. Also renamed the files too. I will have left to rename the hostname fields in the already generated log. Doing that at the moment. Regarding the logs I am checking why these are generated but not copied over. Maybe there is a mismatch in directories. I am checking that. Regarding op-tpo I am working to have the webserver running. Also installing let's encrypt right now :)

Also do you think we could have these running on op-$cc.torproject.org ?

Update: I have also replaced the REMOTEHOSTNAME in the tpf files.

Let's encrypt is running. New domain names are:

• op-us.onionperf.torproject.net

• op-nl.onionperf.torproject.net

Working on tpo setup.

For OFT Cloud we have a new location available: Hong Kong. Are we interested in setting this up?

Regarding the tpf files not showing up in the directory. Logs are generated but files are not "packed" into tpf at midnight. I am trying to investigate why this is happening.

Thanks for configuring domain names and Let's Encrypt! Downloading using Java works just fine now!

However, I just looked at one of the .tpf files and found a couple of onion addresses:

$ grep START op-us-1048576-2017-03-07.tpf | sed 's/.*ENDPOINTREMOTE=\([^ ]*\) .*/\1/' | sort | uniq -c
  19 199-119-112-144.i95.net:199.119.112.144:8080
  17 5rk7srcqqtesjxpo.onion:0.0.0.0:8080
   1 ggxgcnswjxwjcqoe.onion:0.0.0.0:8080
   7 ysfuzafp5bhhhhis.onion:0.0.0.0:8080

Any idea what's up with those? Could it be that this instance is configured to make more requests than it should? Can you maybe paste the configuration here?

Please review my task-21272 branch with a commit that downloads .tpf files from OnionPerf instances. Still quite rough around the edges, but passed an initial test by successfully downloading .tpf files from https://op-us.onionperf.torproject.net/.

Trac:
Status: new to needs_review

From reading the git diffs, I have a few questions and suggestions:

Does this code reflect the transition period of processing both torperf and onionperf files? Is that the reason for introducing the empty property with the meaning of 'nothing to download'?

Surely tests will be added for the new functionality of Configuration's getStringArray and getStringArrayArray methods? I assume current code that uses these methods relies on receiving a non-empty array or double array. It needs to be verified that we don't run into trouble in the existing code using these methods.

All storing of files should be done by the persist-mechanism, i.e., a o.t.c.persist.TpfPersistence class needs to be introduced (this would shorten TorperfDownloader quite a bit and prevent another re-implementation of this functionality). And, this is a prerequisite for also syncing these files with CollecTor's sync-mechanism, which was left out because we knew a Torperf replacement is coming.

It might be useful to put the Configuration's getUrlArray method to work. The old Torperf code wasn't modernized, b/c we knew it will be replaced. Now, it might be better to have OnionPerfHosts as Url array property. This way the url-property checking in the downloader class is not necessary anymore as Configuration already provides it. Why is the host-nick-name needed and could not be replaced by the hostname itself? (For torperf it is used for further configuration.) Or, is this one of the rough edges and note yet available? If so, maybe have a different configuration approach instead of the hybrid-String-Url array? It would be great to make the configuration simpler to read and edit and keep allmost all property-checking code in the Configuration class. For example, an url-array and a string-array-array property, the latter for the configuration similar to torperf. The only check left for the TorperfDownloader would be to match length of these two array- properties, but there might be other good approaches.

Replying to iwakeh:

From reading the git diffs, I have a few questions and suggestions:

Wow, quick review there. Thanks!

Does this code reflect the transition period of processing both torperf and onionperf files? Is that the reason for introducing the empty property with the meaning of 'nothing to download'?

Huh, good point. What I had in mind that we could use this code to 0) run the same configuration as we do now, 1) start collecting OnionPerf files, and soon after 2) stop collecting Torperf files. But we could achieve the same by deploying this code when we do 1) and deploy another patch for 2). I can undo that change.

Surely tests will be added for the new functionality of Configuration's getStringArray and getStringArrayArray methods? I assume current code that uses these methods relies on receiving a non-empty array or double array. It needs to be verified that we don't run into trouble in the existing code using these methods.

Right. Let me undo this part of the change.

All storing of files should be done by the persist-mechanism, i.e., a o.t.c.persist.TpfPersistence class needs to be introduced (this would shorten TorperfDownloader quite a bit and prevent another re-implementation of this functionality). And, this is a prerequisite for also syncing these files with CollecTor's sync-mechanism, which was left out because we knew a Torperf replacement is coming.

Hmm, is this something you might be able to do? I'd really want us to deploy this code before Amsterdam, so that we can discuss next steps there. Otherwise, how about we defer this part until after Amsterdam?

It might be useful to put the Configuration's getUrlArray method to work. The old Torperf code wasn't modernized, b/c we knew it will be replaced. Now, it might be better to have OnionPerfHosts as Url array property. This way the url-property checking in the downloader class is not necessary anymore as Configuration already provides it. Why is the host-nick-name needed and could not be replaced by the hostname itself? (For torperf it is used for further configuration.) Or, is this one of the rough edges and note yet available? If so, maybe have a different configuration approach instead of the hybrid-String-Url array? It would be great to make the configuration simpler to read and edit and keep allmost all property-checking code in the Configuration class. For example, an url-array and a string-array-array property, the latter for the configuration similar to torperf. The only check left for the TorperfDownloader would be to match length of these two array- properties, but there might be other good approaches.

Well, my idea was that we should use the configured source name to make sure that an OnionPerf host doesn't send us measurement results for other sources, either accidentally or on purpose. I'm not sure how we could use the hostname there if we want to stick to the current naming schema of .tpf files. But it could be that I overlooked something.

However, if we want to keep this, what we could do is add a new method Configuration.getStringUrlMap() that returns a (sorted) map of Strings to URLs. Again, would you want to write such a thing?

Thanks again!

Only two short questions about naming scheme and host url:

Currently the beginning of the host url is reflected in the file name. Why can't we just use the beginning of the host url, i.e., the op-$cc part for checking the filenames?

Is the goal now to just download all available measurements regarding file size?