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

arma at seul.org arma at seul.org
Sun Mar 22 16:30:48 UTC 2009

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
+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