[or-cvs] r18878: {projects} flesh out section 6 (projects/performance)

[arma@xxxxxxxx]

Author: arma
Date: 2009-03-11 06:38:01 -0400 (Wed, 11 Mar 2009)
New Revision: 18878

Modified:
   projects/performance/performance.tex
Log:
flesh out section 6


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-11 10:21:37 UTC (rev 18877)
+++ projects/performance/performance.tex	2009-03-11 10:38:01 UTC (rev 18878)
@@ -1462,23 +1462,38 @@
 {\bf Plan}: Overall, it seems like a risky move, but with potentially
 quite a good payoff. I'm not convinced either way.
 
-\section{Network overhead too high for modem users}
+\section{The network overhead is still too high for modem users}
 
+Even if we resolve all the other pieces of the performance question,
+there still remain some challenges posed uniquely by users with extremely
+low bandwidth -- for example, users on modems or cell phones. We need
+to optimize the Tor protocols so they are efficient enough that Tor can
+be practical in this situation too.
+
 \subsection{We've made progress already at directory overhead}
 \label{sec:directory-overhead}
 
-Tor clients must download information on the network, before they can
-start building connections.
-The current directory format (version 3) already gives a substantial
-reduction in size.
-However, more improvements are possible and Proposal 158, which further
-reduces the directory overhead, is scheduled to be deployed in the Tor
-0.2.2.x series.
-Further background on directory overhead progress is given in our blog
-post\footnote{\url{https://blog.torproject.org/blog/overhead-directory-info\%3A-past\%2C-present\%2C-future}}.
+We've already made great progress at reducing directory
+overhead, both for bootstrapping and maintenance. Our
+blog post on the topic provides background and
+details\footnote{\url{https://blog.torproject.org/blog/overhead-directory-info\%3A-past\%2C-present\%2C-future}}.
 
-\subsection{TLS overhead also can be improved}
+Proposal 158, which further reduces the directory overhead, is scheduled
+to be deployed in the Tor 0.2.2.x series.\footnote{\url{https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt}}
 
+{\bf Impact}: Low for normal users, high for low-bandwidth users.
+
+{\bf Effort}: Medium, but we're already a lot of the way through it.
+
+{\bf Risk}: Low.
+
+{\bf Plan}: Once we roll out proposal 158, I think we'll be in good
+shape for a while. The next directory overhead challenge will be in
+splintering the network, but first we must get enough relays that the
+step is needed.
+
+\subsection{Our TLS overhead can also be improved}
+
 OpenSSL will, by default, insert an empty TLS application record before
 any one which contains data.
 This is to prevent an attack, by which someone who has partial control
@@ -1510,25 +1525,33 @@
 Of course, the empty application record was inserted for a reason --
 to prevent an attack on the CBC mode of operation used by TLS, so before
 removing it we must be confident the attack does not apply to Tor.
-Ben Laurie (one of the OpenSSL developers), concluded that in his
+Ben Laurie (one of the OpenSSL developers) concluded that in his
 opinion Tor could safely remove the insertion of empty TLS application
 records~\cite{tls-empty-record}.
-I was able to come up with only certificational weaknesses (discussed
+Steven was able to come up with only certificational weaknesses (discussed
 in the above analysis), which are expensive to exploit and give little
 information to the attacker.
 
-To be successful, the attacker must have full control of the plaintext
-application record before the one he wishes to guess.
-Tor makes this difficult because all cells where the payload is controlled
-by the attacker are prepended with a two byte circuit ID, unknown to
-the attacker.
-Also, because the majority of cells sent in Tor are encrypted by a key
-not known by the attacker, the probability that an attacker can guess
-what a cell might be is extremely small.
-The exception is a padding cell, which has no circuit ID and a zero
-length payload, however Tor does not currently send padding cells,
-other than as a periodic keep-alive.
+%To be successful, the attacker must have full control of the plaintext
+%application record before the one he wishes to guess.
+%Tor makes this difficult because all cells where the payload is controlled
+%by the attacker are prepended with a two byte circuit ID, unknown to
+%the attacker.
+%Also, because the majority of cells sent in Tor are encrypted by a key
+%not known by the attacker, the probability that an attacker can guess
+%what a cell might be is extremely small.
+%The exception is a padding cell, which has no circuit ID and a zero
+%length payload, however Tor does not currently send padding cells,
+%other than as a periodic keep-alive.
 
+{\bf Impact}: Low.
+
+{\bf Effort}: Low.
+
+{\bf Risk}: Medium, since our initial analysis might be wrong.
+
+{\bf Plan}: Do it in the Tor 0.2.2.x or 0.2.3.x timeframe. Not critical.
+
 %\subsection{Hibernating relays shouldn't be listed as Running}
 
 %we are giving Running flags to hibernating relays. if we stop giving