[or-cvs] r19104: {projects} move steven's "circuit-building efficiency" subsec to sectio (projects/performance)

[arma at seul.org]

Author: arma
Date: 2009-03-22 12:30:47 -0400 (Sun, 22 Mar 2009)
New Revision: 19104

Modified:
   projects/performance/performance.tex
Log:
move steven's "circuit-building efficiency" subsec to section 5


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-22 16:05:13 UTC (rev 19103)
+++ projects/performance/performance.tex	2009-03-22 16:30:47 UTC (rev 19104)
@@ -671,23 +671,6 @@
 our time and effort are better spent on design and coding that will
 have long-term impact rather than be recurring costs.
 
-\subsection{Improving efficiency of the Tor protocol}
-\label{sec:protocol-efficiency}
-
-A number of proposals~\cite{kate-pet2007,overlier:pet2007} have been published in the literature on how to improve the efficiency of the Tor handshake protocol.
-These would reduce the latency of circuit establishment, and lower CPU load on nodes.
-Applying a modification like this would break existing clients, so Tor's version negotiation functionality would be required to permit both protocol to operate in parallel.
-Compared to the existing Tor protocol, the proposed modifications are not as well analyzed so there is a risk that they will have some weaknesses.
-Some also relax Tor's security assurances (e.g. perfect forward secrecy) in order to offer improved performance.
-
-{\bf Impact}: Low.
-
-{\bf Effort}: High.
-
-{\bf Risk}: High.
-
-{\bf Plan}: Not yet. Cryptographic overhead does not appear to be a significant component of latency. If, later on, circuit establishment overhead starts to be a significant contributor to performance problems, we should re-evaluate.
-
 \subsection{Handling fast Tor relays on Windows}
 \label{sec:overlapped-io}
 
@@ -1453,6 +1436,33 @@
 
 {\bf Plan}: Do the computations, then write a proposal, then do it.
 
+\subsection{Improving efficiency of the Tor circuit-building protocol}
+\label{sec:protocol-efficiency}
+
+A number of proposals~\cite{kate-pet2007,overlier:pet2007} have been
+published in the literature on how to improve the efficiency of the Tor
+handshake protocol.
+These would reduce the latency of circuit establishment, and lower CPU
+load on nodes.
+Applying a modification like this would break existing clients, so
+Tor's version negotiation functionality would be required to permit both
+protocol to operate in parallel.
+Compared to the existing Tor protocol, the proposed modifications are not
+as well analyzed so there is a risk that they will have some weaknesses.
+Some also relax Tor's security assurances (e.g. perfect forward secrecy)
+in order to offer improved performance.
+
+{\bf Impact}: Low.
+
+{\bf Effort}: High.
+
+{\bf Risk}: High.
+
+{\bf Plan}: Not yet. Cryptographic overhead does not appear to be a
+significant component of latency. If, later on, circuit establishment
+overhead starts to be a significant contributor to performance problems,
+we should re-evaluate.
+
 \subsection{Bundle the first data cell with the begin cell}
 
 In Tor's current design, clients send a ``relay begin'' cell to specify