commit 23efccdcecccb0be555f1471decd40340e4167a5 Author: Karsten Loesing karsten.loesing@gmx.net Date: Tue Oct 29 17:14:02 2013 +0100
Add authors to torperf2 report, tweak text a bit. --- 2013/torperf2/torperf2.tex | 71 +++++++++++++++++++++++++++----------------- 1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex index b8f2e71..8e522bf 100644 --- a/2013/torperf2/torperf2.tex +++ b/2013/torperf2/torperf2.tex @@ -10,13 +10,14 @@ \title{Requirements and Software Design for a\ Better Tor Performance Measurement Tool}
-\author{Karsten Loesing} +\author{Karsten Loesing, Sathyanarayanan Gunasekaran, and Kevin Butler}
-\contact{\href{mailto:karsten@torproject.org}{karsten@torproject.org}} -\reportid{} -\date{\emph{\--- This report has not been published yet, so it has no -number and its URL is going to change once it's published; better not -reference it yet. Work in progress. ---}} +\contact{\href{mailto:karsten@torproject.org}{karsten@torproject.org},% +\href{mailto:gsathya@torproject.org}{gsathya@torproject.org},% +\href{mailto:haqkrs@gmail.com}{haqkrs@gmail.com}} + +\reportid{2013-10-002 (DRAFT)} +\date{October 31, 2013}
\maketitle
@@ -35,7 +36,7 @@ Also, Torperf consists of a bunch of shell scripts which makes it neither very user-friendly to set up and run, nor extensible to cover new use cases.
-For reference, we made an earlier approach 1.5 later that suggested +For reference, we made an earlier approach 1.5 years later that suggested redesigning the Python parts in Torperf, but that redesign never happened.% \footnote{\url{https://trac.torproject.org/projects/tor/ticket/2565%7D%7D @@ -49,13 +50,10 @@ After that, we discuss actual functional requirements, so experiments that we want to perform to measure things in the Tor network on a regular and automated basis. Finally we suggest a software design that fulfills all these requirements. -This report is meant to be updated in the process of writing this new -software, so that it can later serve as documentation. -Only then it's going to be published officially.
\section{Requirements}
-Before we talk about functional requirements, that is, actual experiments +Before we talk about actual experiments the new Torperf is supposed to perform, we want to discuss more general requirements of a Torperf rewrite. For the time being, assume that the major functional requirement is to @@ -87,7 +85,8 @@ The new Torperf should run as OS service, unrelated to a specific user. It should have a config file that is easy to understand, and it should come with scripts to start, restart, and stop the Torperf service. -If the service operator wants to run multiple experiments at once, they'd +If the service operator wants to run multiple experiments in parallel, +they'd simply configure all those experiments in the configuration file or directory, rather than starting multiple instances of Torperf.
@@ -118,8 +117,9 @@ single tool: think of how a tor relay does bandwidth self-tests to itself. \end{itemize}
What's not easily possible with this approach is to configure client and -server to run on different hosts. Is there an experiment where this -might be useful? +server to run on different hosts. +It's unclear yet whether there is an experiment where this might be +useful.
% Commented out Kevin's text on 2013-09-24: % \subsubsection{Experiment extensibility considerations} @@ -162,11 +162,11 @@ might be useful? % speak Torperf's programming language. If people want to add a simple % experiment, they can write a wrapper for using their tool in Torperf.
-This requirement is still subject to discussion, because it's unclear how -this will work when users just \verb+apt-get install torperf+. -Ideally if someone writes a good experiment, they should send the patches -upstream and get it merged, and then we update Torperf to include those -tests and then the users just update Torperf with their package managers. +% This requirement is still subject to discussion, because it's unclear how +% this will work when users just \verb+apt-get install torperf+. +% Ideally if someone writes a good experiment, they should send the patches +% upstream and get it merged, and then we update Torperf to include those +% tests and then the users just update Torperf with their package managers.
\subsubsection{User-defined tor version or binary}
@@ -190,13 +190,13 @@ results.
It might be beneficial to provide a mechanism to download and verify the signature of new tor versions as they are released. The user could specify -if they plan to test stable, beta or alpha versions of tor with their +if they plan to test stable, beta, or alpha versions of tor with their Torperf instance.
This requirement should be implemented in three phases: 1) Torperf uses the default tor binary that comes with the operating system; 2) Torperf accepts the path to a tor binary that was previously built by the user; -3) Torperf accepts that path to a Git tag or tor source directory and +3) Torperf accepts the path to a Git tag or tor source directory and downloads, verifies, and builds a tor binary itself.
\subsubsection{User-defined third-party software version or binary} @@ -220,7 +220,9 @@ But at the same time we want to keep it as easy as possible to process results.
Results may come from various sources, e.g., an HTTP/SOCKS client, -Selenium/Firefox, a tor client used to make the request or to answer the +Selenium% +\footnote{\url{http://www.seleniumhq.org/%7D%7D% +/Firefox, a tor client used to make the request or to answer the request as hidden service, an HTTP server, etc. Torperf should not store original logs, because that would only shift the issue of processing different log formats to the analysis step. @@ -228,12 +230,14 @@ Such an approach would also generate unnecessarily large results files. Torperf should rather process data from these sources and store them in a custom results format that can be easily processed using tools shipped with Torperf. + Results may include data which appear not immediately relevant to measuring Tor performance, but which may be useful for related purposes. For example, Torperf should include data about circuit failures in its results, even though these circuits may not have been used in actual requests.% \footnote{\url{https://trac.torproject.org/projects/tor/ticket/8662%7D%7D + Deciding which data to store should be the responsibility of whoever designs a Torperf experiment, though formats should be somewhat uniform between experiments. @@ -307,7 +311,9 @@ The new Torperf should come with an easy-to-use library to process its results. The library should also make it simple to create Torperf compatible results or clearly highlight areas of non conformance with existing results. Alternatively, this library could be provided and maintained as part of -stem or another parsing library. +stem% +\footnote{\url{https://stem.torproject.org/%7D%7D +or another parsing library.
\section{Experiments}
@@ -445,8 +451,12 @@ deploying Twisted applications, rather than forcing us to solve these problems yet another time. Of course, at the same time it forces us to follow the Twisted model of writing applications, which seems not too bad in this case. -The current prototype also requires twisted-socks as SOCKS client, -txtorcon for communicating with tor clients, and stem for event parsing. +The current prototype also requires twisted-socks% +\footnote{\url{https://github.com/ln5/twisted-socks%7D%7D +as SOCKS client, +txtorcon% +\footnote{\url{https://github.com/meejah/txtorcon%7D%7D +for communicating with tor clients, and stem for event parsing.
The following list outlines tasks that the new Torperf needs to perform. These could be implemented as Python classes, though this list was not @@ -504,6 +514,11 @@ and produce graphs and other aggregate statistics. Could also become part of stem instead, together with a tutorial. \end{description}
+\section*{Acknowledgments} + +Lunar, Zack Weinberg, and Rob van der Hoeven provided valuable feedback +for this report. + \bibliography{torperf2}
\appendix @@ -596,7 +611,8 @@ Document type string; always \verb+"stream"+ for this document type; required.\ \verb+ "guid": "ec2_9001_1365473922.76_884",+ & Globally unique identifier for a stream document, consisting of service -identifier, tor SOCKS port, and stream creation time; required.\ +identifier, tor SOCKS port, and stream creation time, and +locally unique stream identifier; required.\ \verb+ "source": "ec2",+ & Configured service identifier; required.\ \verb+ "socks": 9001,+ & @@ -632,7 +648,8 @@ Document type string; always \verb+"circuit"+ for this document type; required.\ \verb+ "guid": "ec2_9001_1365473682.13_501",+ & Globally unique identifier for a circuit document, consisting of service -identifier, tor SOCKS port, and circuit launch time; required.\ +identifier, tor SOCKS port, circuit launch time, and +locally unique circuit identifier; required.\ \verb+ "source": "ec2",+ & Configured service identifier; required.\ \verb+ "socks": 9001,+ &