[or-cvs] r15163: Wrote motivation section and first half of measurement setup (projects/hidserv/trunk/doc)

kloesing at seul.org kloesing at seul.org
Thu Jun 12 15:37:21 UTC 2008


Author: kloesing
Date: 2008-06-12 11:37:21 -0400 (Thu, 12 Jun 2008)
New Revision: 15163

Modified:
   projects/hidserv/trunk/doc/report.pdf
   projects/hidserv/trunk/doc/report.tex
Log:
Wrote motivation section and first half of measurement setup.

Modified: projects/hidserv/trunk/doc/report.pdf
===================================================================
(Binary files differ)

Modified: projects/hidserv/trunk/doc/report.tex
===================================================================
--- projects/hidserv/trunk/doc/report.tex	2008-06-12 15:27:09 UTC (rev 15162)
+++ projects/hidserv/trunk/doc/report.tex	2008-06-12 15:37:21 UTC (rev 15163)
@@ -1,37 +1,163 @@
 \documentclass{article}
+\usepackage{url}
 \begin{document}
-\title{Hidden Service Measurements}
+\title{Tor Hidden Service Performance Analysis}
 \date{June 15, 2008}
 \maketitle
 
 \begin{abstract}
-This document describes measurements of setting up and accessing a Tor hidden service. The objective is to spot performance bottlenecks in the hidden service protocol and suggest which parts should be changed in order to improve the overall performance of Tor hidden services.
+This document describes measurements of setting up and accessing a Tor
+hidden service. The objective is to spot performance bottlenecks in the
+hidden service protocol and suggest which parts should be changed in order
+to improve the overall performance of Tor hidden services.
 \end{abstract}
 
 \section{Motivation}
+Tor Hidden Services\footnote{\url{https://tor-svn.freehaven.net/svn/tor/trunk/doc/design-paper/tor-design.pdf}}
+allow users to set up anonymous information services, like websites, that
+can only be accessed through the Tor network and are protected against
+identification of the host that runs the services. The most critical
+limitation of Tor Hidden Services is the time it takes until a hidden
+service is registered in the network and the latency of contact
+establishment when accessed by a user. Due to design issues in the original
+Tor protocol, the connection to a new hidden service can take several
+minutes, which leads most users to give up before the connection has been
+established. Using Tor Hidden Services for direct interactive user-to-user
+communication (e.g. messaging) is nearly impossible due to the high latency
+of hidden service circuit setup. 
 
-Motivate what parts of the protocol we want to measure:
+This document describes measurements of setting up and accessing a Tor
+Hidden Service. The first part of these measurements consist of an
+\emph{outside view} of a user experiencing the delay in publishing a hidden
+service, establishing a connection to an existing hidden service, sending
+and receiving messages, and the durability of an established connection.
+The intention of the second part of these measurements is to obtain an
+\emph{internal view} of the delay that is introduced by single substeps of
+connection establishing. The following data was collected:
 
-Leverage existing measurements of establishing a connection to a hidden service. (TODO Christian: what exact parts are measured here?)
+\begin{description}
+\item[Service Publication] How long does it take from starting Tor
+configured to provide a hidden service until the hidden service is
+advertised in the network and accessible by clients?
+\item[Connection Establishment] How long does it take for a client to open
+a connection to an existing hidden service. As this includes multiple
+substeps, there are two distinct measurements to answer this question, one
+measuring the overall connection establishment time and one measuring the X
+internal substeps\footnote{TODO Christian: How many substeps are there?}
+that are involved in this process.
+\item[Message Transfer] What is the delay of transferring messages from
+client to server and back over an established connection?
+\item[Connection Durability] How long do connections persist before
+breaking due to some network failure?
+\end{description}
 
-Create new measurement setup to measure the missing parts (server-side descriptor publication time, connection opening time for cross-check with first measurements, request/response times, connection duration)
-
 \section{Measurement Setup}
 
-\subsection{Connection Establishment}
+\subsection{Outside View Measurements}
 
-TODO Christian: describe setup here, possibly re-use parts of diploma thesis.
+The first set of measurements aims at the user experience of a hidden
+service provider or client requesting an existing hidden service. The setup
+consists of two Tor clients, one of them being the \emph{server-side Tor
+process} that is configured to provide a hidden service and the other one
+being the \emph{client-side Tor process} that is used to access the hidden
+service. 15 minutes after starting the two Tor processes, two more
+processes are started: a \emph{server process} acts as hidden server and
+listens for requests from the server-side Tor process and a \emph{client
+process} uses the client-side Tor process to establish a connection to the
+hidden service. The client process, after establishing the connection to
+the server process via Tor, sends numbered echo messages every minute
+until the connection breaks (or four hours elapse). The server process
+echoes all received messages back to the client. Both Tor processes as
+well as client and server process run on the same physical machine and log
+their actions to local files.
 
-\subsection{Descriptor Publication, Data Transfer, and Connection Duration}
+\paragraph{Service Publication}
 
-Describe timing of one test run (create two Tor clients, one with hidden service configured, wait for 15 minutes, open connection to hidden service, send packet with sequence number every minute that is echoed by server, keep connection open for at most 4 hours)
+There are at least three log statements in the server-side Tor process log
+that can be used to determine service publication: the first informs about
+starting up Tor and opening the log file, the second reports that Tor has
+enough directory information to build circuits, and the third announces
+that a hidden service descriptor has been uploaded to the hidden service
+directory:
 
-Identify Tor log statements for later evaluation. Describe simplified Java application with places which measurements will be based on (open connection, send/receive request/reply, closing connection)
+% log statements taken from test-id 1212519002008
+\begin{verbatim}
+Jun 03 20:50:02.100 [notice] Tor 0.2.1.0-alpha-dev (r14739)
+  opening new log file.
+Jun 03 20:50:11.151 [notice] We now have enough directory
+  information to build circuits.
+Jun 03 20:51:22.878 [info] connection_dir_client_reached_eof():
+  Uploaded rendezvous descriptor (status 200 ("Service
+  descriptor stored"))
+\end{verbatim}
 
+Using these log statements both \emph{initialization time} that is required
+to download enough directory information (here: 9.051 seconds) and
+\emph{publication time} that is used to establish introduction points and
+upload a descriptor (here: 71.727 seconds) can be calculated by subtracting two
+timestamps.
+
+\paragraph{Connection Establishment}
+
+The connection time---from a user perspective---is the time that it takes
+to open a socket connection on client-side. In the client process this is
+performed by a single line of code (with a previous initialization to use
+the client-side Tor process as SOCKS proxy):
+
+\begin{verbatim}
+socket.connect(hiddenServiceAddress);
+\end{verbatim}
+
+Connection establishment time is measured by firing a log event immediately
+before and after this code line and subtracting the first timestamp from
+the second.
+
+\paragraph{Message Transfer}
+
+The client process sends a numbered message to the server process every
+minute and logs the sending event locally. Upon receiving the message, the
+server logs receipt including message number and replies immediately. As
+soon as the client receives the reply, it also logs receipt including
+message number. 
+
+\paragraph{Connection Durability}
+
+If the client process observe a connection break before the test duration
+of four hours elapses, it logs this event locally. The difference between
+the timestamp of having established the connection and the timestamp of the
+connection break is considered the connection durability.
+
+\subsection{Connection Establishment}
+
+TODO Christian: describe setup here, possibly re-use parts of diploma
+thesis.
+
 \section{Results}
 
-Descriptive statistics and diagrams of both measurements.
+The \emph{outside view} measurements were performed between June 1, 2:50pm
+(starting time of first test run) and June 5, 9:35am (starting time of last
+test run), resulting in a total of 1,090 data samples. A tarball with all
+log files is available
+online.\footnote{\url{http://freehaven.net/~karsten/hidserv/test-env.tar.gz}}
 
+TODO Christian add meta-data of your measurements here
+
+\subsection{Service Publication}
+
+TODO Karsten
+
+\subsection{Connection Establishment}
+
+TODO Christian: your results here
+
+\subsection{Message Transfer}
+
+TODO Karsten
+
+\subsection{Connection Durability}
+
+TODO Karsten
+
 \section{Discussion}
 
 Ideas what changes are most likely to improve the overall performance.



More information about the tor-commits mailing list