[tor-commits] [tech-reports/master] Add authors to torperf2 report, tweak text a bit.
karsten at torproject.org
karsten at torproject.org
Wed Oct 30 18:44:39 UTC 2013
commit 23efccdcecccb0be555f1471decd40340e4167a5
Author: Karsten Loesing <karsten.loesing at 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 at torproject.org}{karsten at 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 at torproject.org}{karsten at torproject.org},%
+\href{mailto:gsathya at torproject.org}{gsathya at torproject.org},%
+\href{mailto:haqkrs at gmail.com}{haqkrs at 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}}
@@ -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/}}%
+/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}}
+
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/}}
+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}}
+as SOCKS client,
+txtorcon%
+\footnote{\url{https://github.com/meejah/txtorcon}}
+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,+ &
More information about the tor-commits
mailing list