[or-cvs] r15266: a few thoughts on the in-progress hidserv report. i also sta (projects/hidserv/trunk/doc)

[arma@xxxxxxxx]

Author: arma
Date: 2008-06-15 02:04:13 -0400 (Sun, 15 Jun 2008)
New Revision: 15266

Modified:
   projects/hidserv/trunk/doc/report.tex
Log:
a few thoughts on the in-progress hidserv report.
i also started fixing typos but quickly gave up :)


Modified: projects/hidserv/trunk/doc/report.tex
===================================================================
--- projects/hidserv/trunk/doc/report.tex	2008-06-15 03:27:49 UTC (rev 15265)
+++ projects/hidserv/trunk/doc/report.tex	2008-06-15 06:04:13 UTC (rev 15266)
@@ -23,7 +23,7 @@
 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
+limitations of Tor Hidden Services are 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
@@ -33,7 +33,7 @@
 latency of hidden service circuit setup. 
 
 This document describes measurements of setting up and accessing a Tor
-Hidden Service. The first part of these measurements consist of an
+Hidden Service. The first part of these measurements consists of an
 \emph{external view} of a user experiencing the delay in publishing a
 hidden
 service, establishing a connection to an existing hidden service, sending
@@ -43,12 +43,12 @@
 connection establishing. The following questions shall be answered:
 
 \begin{description}
-\item[Service Publication] How long does it take from a starting Tor
+\item[Service Publication] How long does it take from starting a Tor
 process that is 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
+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{\emph{TODO Christian: How many substeps are
 there in your setup?}}
@@ -64,10 +64,10 @@
 %% \emph{TODO Christian: Your protocol description might also help for
 %% understanding service publication, so it might be useful to have it here in
 %% a separate section.}
-This sections describes the protocol of establishing and accessing hidden
+This section describes the protocol for establishing and accessing hidden
 services in detail. An overview is shown in Figure~\ref{fig:hs_overview}.
 
-Consider a user called Bob wants to offer a location-hidden service.
+Consider a user called Bob who wants to offer a location-hidden service.
 All Bob needs to do to establish a hidden service is to set up the actual
 service to start the Tor client, which is configured to provide a hidden service.
 
@@ -96,6 +96,7 @@
 key. The hidden server uploads the descriptor and a unique identifier for the 
 service, the onion address built from a random hash, to the hidden service
 directory.
+% XXX actually, not random. based on public key, so we can self-sign -RD
 
 If a user called Alice wants to access a hidden service, she must have learned 
 the onion address before out-of-band.
@@ -537,6 +538,8 @@
 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}}
+% Put dates in the name or something, or you're going to be forever
+% regretting your choice of filename. :) -RD
 
 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
@@ -613,6 +616,11 @@
 It turned out that the reason for this is a minor bug in the code which is
 now fixed. See SVN revision r15113 for
 details.\footnote{\url{http://archives.seul.org/or/cvs/Jun-2008/msg00231.html}}
+% Include "and the fix was released in Tor 0.2.0.x-rc" too for each time
+% you point to an svn revision -RD
+% Also, it would probably be good to mention in which version each bug
+% introduced. This will make it look great when you fix the bugs that
+% were in since Tor 0.0.6. -RD
 This is not meant as confirmation for the usefulness of the 30-second
 delay, but only to make the implementation consistent with the
 specification.
@@ -761,6 +769,7 @@
 Figure~\ref{fig:introcirc} shows that in most cases the introduction circuit
 is open within seconds. For the values around 60 seconds the circuit could not 
 be cannibalized successfully and after a timeout of one minute a second attempt
+% Boy, a timeout of one minute seems dumb here. Almost like it's a bug? :) -RD
 is started. The reasons for failing cannibalization can be that only the actual
 extension, i.e.\ connection to the introduction point fails or that a circuit
 was chosen for extension, that was not open yet. That means, that also the first
@@ -775,6 +784,7 @@
 
 \paragraph{Cell Transfer Over the Same Circuit}
 
+% XXX do you mean \ref{fig:estrend_rendack} here? -RD
 Figure~\ref{fig:introcirc} compares the transfer times of the 
 ESTABLISH\_RENDEZVOUS and RENDEZVOUS\_ACK cells sent over the same rendezvous
 circuit. Although for very low values below 0.1 seconds the latter is
@@ -783,6 +793,7 @@
 
 Also interesting is the formation around the acknowledgments with one second, 
 which also occur for ESTABLISH\_RENDEZVOUS cell, that are twice as fast.
+% What might that mean? That's weird. -RD
 
 \begin{figure}
 \centering
@@ -820,6 +831,10 @@
 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.
+% 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
@@ -857,6 +872,9 @@
 need to put special focus on it in the attempt to improve the hidden
 service protocol.
 
+% Also worth mentioning that most of the requested ports were not in
+% LongLivedPorts, so we can expect even higher stability for IM. -RD
+
 \section{Discussion}
 
 Ideas what changes are most likely to improve the overall performance.