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

sjm217 at seul.org sjm217 at seul.org
Tue Mar 10 23:58:54 UTC 2009

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
@@ -541,7 +541,7 @@
operators, to give them a better sense of community, to answer questions
and concerns more quickly, etc.

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

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

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