[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r15277: Minor cleanups, some more TODOs. (projects/hidserv/trunk/doc)
Author: kloesing
Date: 2008-06-15 12:23:30 -0400 (Sun, 15 Jun 2008)
New Revision: 15277
Modified:
projects/hidserv/trunk/doc/report.pdf
projects/hidserv/trunk/doc/report.tex
Log:
Minor cleanups, some more TODOs.
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-15 15:12:48 UTC (rev 15276)
+++ projects/hidserv/trunk/doc/report.tex 2008-06-15 16:23:30 UTC (rev 15277)
@@ -117,7 +117,7 @@
rendezvous point. The advantage is that the rendezvous circuit is immediately
built and Alice's Tor client can send an \texttt{ESTABLISH\_RENDEZVOUS} cell
over the circuit. This cell contains a random rendezvous cookie for
-identification purpose. The rendezvous point saves the rendezvous cookie and
+identification purposes. The rendezvous point saves the rendezvous cookie and
acknowledges its new
functionality by replying with a \texttt{RENDEZVOUS\_ESTABLISHED} cell.
@@ -220,15 +220,15 @@
publication time is required by Tor for downloading enough directory
information to build circuits before being able to setup a hidden service.
However, the focus here is to speed up the hidden service related parts of
-Tor. Therefore, service establishment time focuses only on the time between
-Tor knows enough directory information (2) until uploading the first hidden
-service descriptor (6); here: 71.727 seconds
+Tor. Therefore, the \emph{service establishment time} focuses only on the
+time between Tor knows enough directory information (2) until uploading the
+first hidden service descriptor (6); here: 71.727 seconds
\end{description}
-The remaining events of giving up an introduction point candidate (3),
+The remaining events of giving up on an introduction point candidate (3),
successful establishment of an introduction point (4) and initiating upload
-of a hidden service descriptor (5) are used to further examine individual
-components of service establishment times.
+of a rendezvous service descriptor (5) are used to further examine
+individual components of service establishment times.
\paragraph{Connection Establishment}
@@ -311,19 +311,19 @@
A second
measurement environment is set up to measure the multiple substeps necessary to access a hidden service. Tor clients generate log statements during
-runtime, which are used to gain insight, when certain internal events occur.
+runtime, which are used to gain insights, when certain internal events occur.
To have access to all log files needed, the most important roles in the
process of connection establishment are set up especially for the measurements.
This includes the two roles mentioned in the first measurement environment, a
client-side Tor process and a server-side Tor process, providing the hidden
-service. In addition to that, two more Tor processes are started on the same machine,
+service. In addition to that, two more Tor processes configured as relays are started on the same machine,
acting as introduction point and rendezvous point. All other Tor relays involved
in the process, constituting the circuits between the above-mentioned roles, are
selected from the global Tor network during runtime using the regular Tor
path-selection algorithm.
Special configuration of client-side and server-side processes is necessary to
-make them select the specific relays as introduction and rendezvous point, on
+make them select the specified relays as introduction and rendezvous point, on
the one hand using the regular Tor configuration options, on the other hand
changing the Tor source code to achieve the desired behavior. After
starting introduction and rendezvous point processes first, the hidden
@@ -334,8 +334,13 @@
\emph{TODO Christian: Mention bug here that selecting a rendezvous by means
of configuring it in torrc fails. This bug was probably introduced with the
-config option for RendNodes, right? When was this?}
+config option for RendNodes, right?}
+\emph{TODO Karsten: When was this?}
+\emph{TODO Christian: You started the Tor process configured to provide the
+hidden service only \emph{minutes} after the Tor relays? Then you didn't
+use the V3 directory, right? You should mention this fact.}
+
%% The following paragraphs describe the measured substeps in detail and which
%% log statements are used to determine the values. An overview of all steps
%% is shown in Figure \ref{fig:substeps}. Messages are indicated by solid lines,
@@ -369,8 +374,8 @@
\paragraph{Open Rendezvous Circuit}
In the next step the client opens a circuit to a rendezvous point. More
-precisely, it is not the actual time to open the rendezvous circuit that is
-measured here, but the time until
+precisely, what is measured here is not the actual time to open the
+rendezvous circuit, but the time until
a usable circuit is open after receiving the rendezvous descriptor. If there
is a problem with the first rendezvous circuit and a second one must be opened,
both together constitute this value.
@@ -389,10 +394,12 @@
\paragraph{Open Introduction Circuit}
-The time to open an introduction circuit is also not necessarily equal to
+In parallel to opening the rendezvous circuit, an introduction circuit is
+opened.
+The measured time is not necessarily equal to
the opening time of a single circuit, but may
-consist of multiple attempts, if the chosen 3-hop circuit cannot be built,
-or if it cannot be extended to the introduction point.
+consist of multiple attempts, if a circuit cannot be built or a
+cannibalized circuit cannot be extended to the introduction point.
\begin{verbatim}
Apr 23 20:21:37.905 [info] connection_dir_client_reached_eof():
@@ -404,7 +411,7 @@
\paragraph{Rendezvous Establishment}
The ESTABLISH\_RENDEZVOUS cell is sent from the client to the rendezvous point
-to deliver the rendezvous cookie. While the first statement occurs in the
+to make the rendezvous cookie known. While the first statement occurs in the
client log
file the second appears in the rendezvous point log file.
@@ -419,7 +426,7 @@
\paragraph{Rendezvous Acknowledgment}
The rendezvous point acknowledges with a RENDEZVOUS\_ESTABLISHED cell, that
-is sent immediately after receiving the ESTABLISH\_RENDEZVOUS cell. Therefore
+it sends immediately after receiving the ESTABLISH\_RENDEZVOUS cell. Therefore
the latter is used as starting time for this value.
\begin{verbatim}
@@ -445,11 +452,11 @@
Received an INTRODUCE1 request on circuit 49661
\end{verbatim}
-\paragraph{Forwarding The Request To The Hidden Service}
+\paragraph{Forwarding Request to Hidden Service}
The introduction point forwards the client request to the hidden service relay,
immediately after receiving it. The introduction point uses the circuit that was built
-during establishing the hidden service.
+during establishing the hidden service and since then kept open.
\begin{verbatim}
Apr 23 20:21:39.305 [notice]
@@ -478,7 +485,7 @@
the rendezvous point, together with the rendezvous cookie. Then it extends
a circuit to the rendezvous point. Again, the time to open the rendezvous
circuit on server-side does not need to be constituted by a single
-circuit extension or build attempt.
+circuit cannibalization or build attempt.
\begin{verbatim}
Apr 23 20:21:39.873 [info] rend_service_introduce():
@@ -504,10 +511,10 @@
4815A117.
\end{verbatim}
-\paragraph{Forwarding The Confirmation To The Client}
+\paragraph{Forwarding Rendezvous Confirmation to Client}
-The rendezvous point forwards the content of the RENDEZVOUS1 cell immediately
-after reception as RENDEZVOUS2 cell to the client and connects the circuits
+The rendezvous point forwards the content of the RENDEZVOUS1 cell to the client immediately
+after receiving a RENDEZVOUS2 cell and connects the circuits
of client and server. When the client
receives this cell the connection to the hidden service is open and user
data can be transfered via the rendezvous point.
@@ -532,10 +539,10 @@
During evaluation it has turned out that there is a bug in Tor that leads
to a delay in service publication (see below for details). This made it
necessary to perform a second set of measurements between June 12, 9:22pm
-and June 13, 3:31pm with Tor version 0.2.1.0-alpha-dev (r15153). This time a
-new test was started every single minute instead of every five minutes and
-tests were aborted after uploading the first hidden service descriptor. The
-resulting 1,090 data samples are also available for
+and June 13, 3:31pm with Tor version 0.2.1.0-alpha-dev (r15153). This time
+a new test was started every single minute instead of every five minutes
+and tests were aborted after uploading the first rendezvous service
+descriptor. The resulting 1,090 data samples are also available for
download.\footnote{\url{http://freehaven.net/~karsten/hidserv/perfdata-2008-06-12.tar.gz}}
The \emph{internal view} measurements started on April 22 at 4:00pm and
@@ -656,18 +663,20 @@
the next regular descriptor republication one hour later to perform a
second upload attempt. As a solution to avoid these outliers, a
significantly shorter timeout or exception handling routine for failed
-descriptor uploads appears useful.
+descriptor uploads appears useful. This should improve performance of
+service publication by greatly reducing its variation.
\paragraph{Exceeding the 30-Seconds Delay}
% see test IDs 1213300081565 for 34-seconds delay and 1213347721610 for
% 41-seconds delay
-The current logic for publishing a hidden service descriptor is to wait for
-30 seconds after the last change to the set of introduction points. Though,
-in some test cases these 30 seconds were exceeded: In one test case, there
-is a 34 seconds gap inbetween two introduction establishments, but without
-an attempt to upload a descriptor. In another case, a descriptor is not
-uploaded until 41 seconds after an introduction point establishment.
+The current logic for publishing a rendezvous service descriptor is to wait
+for 30 seconds after the last change to the set of introduction points.
+Though, in some test cases these 30 seconds were exceeded: In one test
+case, there is a 34 seconds gap inbetween two introduction establishments,
+but without an attempt to upload a descriptor. In another case, a
+descriptor is not uploaded until 41 seconds after an introduction point
+establishment.
An inspection of the log files revealed that the abandoning of an
introduction point candidate resets the 30-seconds counter, too, even
@@ -682,10 +691,10 @@
counter when abandoning an introduction point candidate: In very rare cases
the 30-seconds counter is initialized by such an abandoning event, but then
Tor does not succeed in establishing an introduction point within the next
-30 seconds. The result is the upload of an empty hidden service descriptor,
-i.e.\ a descriptor containing zero introduction points. Under certain
-circumstances this might be considered an improvement for clients if the
-most recent descriptor originates from a previous run of Tor and is
+30 seconds. The result is the upload of an empty rendezvous service
+descriptor, i.e.\ a descriptor containing zero introduction points. Under
+certain circumstances this might be considered an improvement for clients
+if the most recent descriptor originates from a previous run of Tor and is
entirely wrong. However, in most cases it would be sufficient and even more
useful to wait for the construction of a non-empty descriptor before
uploading.
@@ -698,16 +707,14 @@
the first descriptor. It appears rather unlikely, that 10 out of 13 circuit
establishment fail. In fact, it turned out that there is another major bug
in Tor that completely ignores introduction points when they were
-established by cannibalizing an existing circuit. This bug was introduced
-in Tor with version 0.2.0.14-alpha released on December 23, 2007. It will
-probably be fixed in the upcoming Tor versions 0.2.0.29(-rc) and
-0.2.1.2-alpha.
+established by cannibalization of an existing circuit. Even though there
+may in general be other reasons for failing establishment of a circuit,
+this bug was the reason for all 10 failed establishments in the considered
+case. This bug was introduced in Tor with version 0.2.0.14-alpha released
+on December 23, 2007. It will probably be fixed in the upcoming Tor
+versions 0.2.0.29(-rc) and 0.2.1.2-alpha. This should significantly speed
+up and reduce variance in service publication time.
-Even though there may in general be other reasons for failing establishment
-of a circuit, this bug was the reason for all 10 failed establishments in
-the considered case. Fixing this bug will probably significantly speed up
-and reduce variance in service publication time.
-
\paragraph{Usefulness of 30-Seconds Delay}
The 30-seconds delay before publishing a descriptor unsurprisingly leads to
@@ -734,6 +741,16 @@
\emph{TODO Christian: Which data did you use for your evaluations? You
should mention that here.}
+\emph{TODO Christian: Can you add a table containing means, minimums,
+etc.\ of all substeps taken in connection establishment? Otherwise the
+reader has to believe you in your selection of presented results.}
+
+\emph{TODO Christian: Were 100\% of all connection attempts in your setup
+successful? In mine only 88.25\% were successul. Any ideas why connection
+attempts failed? We should put this on the list of things to investigate
+in the future. In an ideal world, 99\% of connection establishments should
+succeed. (In a perfect world even 100\%.)}
+
\paragraph{Overall Establishment Time}
Figure~\ref{fig:opentime} shows the distribution of user experienced connection
@@ -747,6 +764,9 @@
\centering
\includegraphics[width=0.8\textwidth]{opentime.png}
\caption{Histogram of connection opening times}
+
+\emph{TODO Christian: Can you add some summary values here as it is done
+in the figures above?}
\label{fig:opentime}
\end{figure}
@@ -774,11 +794,22 @@
establishment, e.g.\ 20 seconds for connecting to the introduction point
and 40 seconds for the rest of connection establishment? It might be
another improvement to further investigate this and recommend new
-timeouts.}
+timeouts.
+(Would it further make sense to include receipt of INTRO\_ACK into a new
+timeout logic?)}
+\emph{TODO Christian: The text implies that cannibalization takes place in
+\emph{all} cases. Is this really the case?}
+
+\emph{TODO Christian: You text implies that a circuit would be chosen for
+extension if it is not open? Does this really happen?}
+
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{introcirc.png}
+
+\emph{TODO Christian: Can you add some summary values here as it is done
+in the figures above?}
\caption{Histogram of times until introduction circuit is open}
\label{fig:introcirc}
\end{figure}
@@ -796,9 +827,15 @@
\emph{TODO Christian: What might that mean? That's weird. -RD}
+\emph{TODO Christian: What kind of improvement would you suggest from these
+findings?}
+
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{estrend_rendack.png}
+
+\emph{TODO Christian: Can you add some summary values here as it is done
+in the figures above?}
\caption{ESTABLISH\_RENDEZVOUS and RENDEZVOUS\_ACK transfer times}
\label{fig:estrend_rendack}
\end{figure}
@@ -844,9 +881,10 @@
At the moment, message transfer times raise more questions than can be
answered. However, these questions are not directly related to hidden
-services, but also apply to regular Tor circuits. A solution to improve
-message transfer times would probably require changes to the core Tor
-design including its path selection algorithm. Therefore, message transfer
+services, but also apply to regular Tor circuits. There are no hints so far
+that delays in message transfer times are specific to hidden services. A
+solution to improve message transfer times would probably require changes
+to Tor's general path selection algorithm. Therefore, message transfer
times will not be further considered in this attempt to speed up hidden
services. The presented data may nevertheless be helpful for later attempts
to speed up Tor message transfer times in general.