[or-cvs] r15285: Some more cleanups. (projects/hidserv/trunk/doc)

[kloesing@xxxxxxxx]

Author: kloesing
Date: 2008-06-15 17:20:49 -0400 (Sun, 15 Jun 2008)
New Revision: 15285

Modified:
   projects/hidserv/trunk/doc/report.pdf
   projects/hidserv/trunk/doc/report.tex
Log:
Some more cleanups.

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 20:31:38 UTC (rev 15284)
+++ projects/hidserv/trunk/doc/report.tex	2008-06-15 21:20:49 UTC (rev 15285)
@@ -334,8 +334,8 @@
 which try to access the hidden service 75 seconds after their launch to let 
 them build circuits previously.
 
-When setting up the measurement environment, a bug considering the RendNodes
-configuration option was discovered. Using this configuration option the user
+When setting up the measurement environment, a bug considering the
+configuration option RendNodes was discovered. Using this configuration option the user
 can suggest specific Tor relays to be selected as rendezvous node by providing
 a list of nicknames or identifiers. Since the rendezvous point is usually 
 established using cannibalization, there must be an existing circuit available 
@@ -346,10 +346,9 @@
 during startup. In the latter case the circuit could be easily cannibalized,
 while the former scenario reduces performance, because we have to wait until 
 the new circuit is built.
+This bug was introduced with the configuration option RendNodes itself in
+version 0.0.6pre1 that was released on April 8, 2004.
 
-\emph{TODO Karsten: This bug was probably introduced with the
-config option for RendNodes, right? When was this?}
-
 \paragraph{Rendezvous Descriptor Round-trip Time}
 
 The time for fetching the rendezvous service descriptor from a hidden
@@ -823,8 +822,8 @@
 \includegraphics[width=0.8\textwidth]{estrend_rendack.png}
 \begin{tabular}{lrrrrrr}
 & Min. & 1st Qu. & Median & Mean & 3rd Qu. & Max.\\\hline
-ESTABLISH\_RENDEZVOUS & 0.0090 & 0.1100 & 0.2670 & 0.8891 & 0.7775 & 56.1000 \\
-RENDEZVOUS\_ACK & 0.0040 & 0.0720 & 0.2040 & 0.7455 & 0.8993 & 32.7700
+EST\_REND & 0.009 & 0.110 & 0.267 & 0.889 & 0.778 & 56.100 \\
+REND\_ACK & 0.004 & 0.072 & 0.204 & 0.746 & 0.899 & 32.770
 \end{tabular}
 \caption{ESTABLISH\_RENDEZVOUS and RENDEZVOUS\_ACK transfer times}
 \label{fig:estrend_rendack}
@@ -848,8 +847,8 @@
 \includegraphics[width=0.8\textwidth]{reqres.png}
 \begin{tabular}{lrrrrrr}
 & Min. & 1st Qu. & Median & Mean & 3rd Qu. & Max.\\\hline
-Mean request time & 0.312 & 2.302 & 4.154 & 7.596 & 8.234 & 143.300\\
-Mean response time & 0.298 & 2.184 & 3.682 & 6.560 & 6.911 & 135.000
+Mean request time & 0.312 & 2.302 & 4.154 & 7.596 & 8.234 & 143.3\\
+Mean response time & 0.298 & 2.184 & 3.682 & 6.560 & 6.911 & 135.0
 \end{tabular}
 \caption{Mean request and response times}
 \label{fig:reqres}
@@ -859,16 +858,9 @@
 inacceptable for most applications. A look into the log statements
 confirmed that these mean values result from normal connections and not
 from short-lived connections with few, very high message transfer times.
-
 Further, in some cases mean request times are up to two orders of magnitude
-higher than mean response times and vice versa. This is rather surprising,
-because both messages are routed via the same Tor circuit.
+higher than mean response times and vice versa.
 
-\emph{TODO Karsten: Perhaps it's because there's a high-volume flow moving in one direction
-over one of the nodes in the circuit but it's only light in the other?
-I would imagine that's pretty common actually. Mike Perry can speculate
-more here. -RD}
-
 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. There are no hints so far
@@ -984,13 +976,13 @@
 allow clients to establish connections to more than one hidden service at
 a time.
 %
-\item[Build More Introduction Circuits than Needed on Hidden Server] When
+\item[Build More Introduction Circuits] When
 establishing introduction points, a hidden service could launch 5 instead
 of 3 introduction circuits at the same time and use only the first 3 that
 could be established. The remaining two circuits could still be used for
 other purposes afterwards.
 %
-\item[Parallel Connection to Two Introduction Points by Clients] A client
+\item[Parallel Connections to Introduction Points] A client
 could attempt to establish two introduction circuits to two different
 introduction points simultaneously and only use the first that succeeds.
 The slower circuit could still be used for another purpose. However, there
@@ -1007,8 +999,7 @@
 These items will be considered in the course of this project:
 
 \begin{description}
-\item[Rendezvous Protocol Simplifications] {\O}verlier and Syverson have
-proposed two simplified rendezvous protocols.\footnote{Lasse {\O}verlier
+\item[Rendezvous Protocol Simplifications] {\O}verlier and Syverson proposed two simplified rendezvous protocols.\footnote{Lasse {\O}verlier
 and Paul Syverson, Improving Efficiency and Simplicity of Tor Circuit
 Establishment and Hidden Services,
 \url{http://www.freehaven.net/anonbib/#overlier-pet2007}}
@@ -1021,8 +1012,8 @@
 without the authors' proposed valet node approach which requires a major
 redesign of hidden services.
 %
-\item[Distributed Hidden Service Directory] The current measurements have
-been performed using the central hidden service directory only. In the near
+\item[Distributed Hidden Service Directory] Current measurements have been
+performed using the central hidden service directory only. In the near
 future the central directory will be replaced by a distributed directory
 consisting of a subset of all Tor relays. This design is already deployed
 and in an experimental state. As soon as a reasonable number of distributed
@@ -1031,8 +1022,14 @@
 might turn out that more sophisticated means for load balancing between
 distributed directory nodes are necessary than are currently implemented.
 %
-\item[Grand Scaling Plan] \emph{TODO Karsten: Find out some details about
-this one.}
+\item[Grand Scaling Plan] There are other attempts to make Tor more useful
+for low-bandwidth
+clients.\footnote{\url{https://www.torproject.org/projects/lowbandwidth}}
+Part of this project might be that clients do not download the complete
+set of router descriptors, but request descriptors during the process of
+circuit establishment. Alas this would slow down circuit creation even
+more, so that hidden services should even try harder to avoid on-demand
+circuit creation.
 %
 \item[Low-Bandwith Measurements] For some improvement suggestions,
 e.g.\ reducing timeouts, the effect on clients with low bandwidth is yet