[or-cvs] r18871: {projects} Few minor typos, and expand the latter sections a little (projects/performance)

[sjm217 at seul.org]

Author: sjm217
Date: 2009-03-10 19:58:53 -0400 (Tue, 10 Mar 2009)
New Revision: 18871

Modified:
   projects/performance/performance.tex
Log:
Few minor typos, and expand the latter sections a little

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-10 17:53:13 UTC (rev 18870)
+++ projects/performance/performance.tex	2009-03-10 23:58:53 UTC (rev 18871)
@@ -93,7 +93,7 @@
 connection. This approach is a smart idea in terms of anonymity, since
 putting all circuits on the same connection prevents an observer from
 learning which packets correspond to which circuit. But over the past
-year research has shown that it's a bad idea in terms of performance,
+year, research has shown that it's a bad idea in terms of performance,
 since TCP's backoff mechanism only has one option when that connection
 is sending too many bytes: slow it down, and thus slow down all the
 circuits going across it.
@@ -246,7 +246,7 @@
 \prettyref{sec:congestion} described mechanisms to let low-volume
 streams have a chance at competing with high-volume streams. Without
 those mechanisms, normal web browsing users will always get squeezed out
-by people pulling down larger content. But the next problem is that some
+by people pulling down larger content and tolerating high latency. But the next problem is that some
 users simply add more load than the network can handle. Just making sure
 that all the load gets handled fairly isn't enough if there's too much
 load in the first place.
@@ -541,7 +541,7 @@
 operators, to give them a better sense of community, to answer questions
 and concerns more quickly, etc.
 
-\subsubsection{A facebook app to show off your relay}
+\subsubsection{A Facebook app to show off your relay}
 
 We're currently developing a Facebook
 application that will allow relay operators to link their Tor relays
@@ -1244,11 +1244,12 @@
 Polipo makes Tor appear faster, for some web browsing activities. Yay.
 We should continue our plans to migrate to it.
 
-\subsection{better timeouts for giving up on circuits and trying a new one}
+\subsection{Better timeouts for giving up on circuits and trying a new one}
 
-Proposal 151 and friends.
+Proposal 151 suggests that clients should estimate their normal circuit extension time, and give up on circuits which are taking substantially longer.
+This should hopefully reduce load on overloaded nodes, and also improve performance for clients.
 
-\subsection{when a circuit has too many streams on it, move to a new one}
+\subsection{When a circuit has too many streams on it, move to a new one}
 
 This would prevent any single circuit from getting too overloaded.
 
@@ -1265,9 +1266,9 @@
 \subsection{Bundle the first data cell with the begin cell}
 
 This would be great for latency and time-to-page-starts-getting-rendered.
-But it's hard because socks wants the handshake to complete before you're
+But it's hard because SOCKS wants the handshake to complete before you're
 allowed to send data. we could hack polipo to optimistically send it
-anyway, since we ship with polipo. seems like a risky move. but quite a
+anyway, since we ship with polipo. Seems like a risky move, but quite a
 good payoff.
 
 \section{Network overhead too high for modem users}
@@ -1275,13 +1276,13 @@
 \subsection{We've made progress already at directory overhead}
 \label{sec:directory-overhead}
 
-proposal 158
-and blog post in general
+Tor clients must download information on the network, before they can start building connections.
+The current directory format (version 3) is 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 the directory overhead was given in a blog post~\footnote{\url{http://blog.torproject.org/blog/overhead-directory-info%3A-past%2C-present%2C-future}}
 
-\subsection{tls overhead also can be improved}
+\subsection{TLS overhead also can be improved}
 
-TLS application record overhead reduction
-
 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
@@ -1399,6 +1400,12 @@
 Alternatively, the network could be configured to share resources in a manner such that the utility to each user is more equal.
 In this case, it will be acceptable to all users that a single equilibrium point is formed, because its level will no longer be in terms of simple bandwidth.
 
+\prettyref{sec:too-much-load} is an example of the former strategy.
+Web browsing users will be offered better performance, so we should attract more of them, but hopefully not so many that the performance returns to current levels.
+In constrast, bulk-traffic users will be given poorer performance, but since they are less sensitive to latency, it could be that they do not mind. 
+\prettyref{sec:congestion} could be used to implement the latter strategy.
+If web-browsing users are more sensitive to latency than bandwidth, then we could optimize the network for latency rather than throughput.
+
 \subsection{Metrics}
 
   Two approaches: "research conclusively first" vs "roll it out and see"