# [or-cvs] r18872: {projects} minor edits and questions. (projects/performance)

phobos at seul.org phobos at seul.org
Wed Mar 11 04:06:18 UTC 2009

Author: phobos
Date: 2009-03-11 00:06:17 -0400 (Wed, 11 Mar 2009)
New Revision: 18872

Modified:
projects/performance/performance.tex
Log:
minor edits and questions.

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-10 23:58:53 UTC (rev 18871)
+++ projects/performance/performance.tex	2009-03-11 04:06:17 UTC (rev 18872)
@@ -172,7 +172,7 @@
%Voice over IP is one fruitful area, as these require low latency and
%hence UDP is common, but further investigation is needed.

-Prof.~Goldberg has a second student named Chris Alexander picking up
+Prof.~Goldberg has a new student named Chris Alexander picking up
where Joel left off. He's
currently working on fixing bugs in OpenSSL's implementation of DTLS along
with other core libraries that we'd need to use if we go this direction.
@@ -217,7 +217,7 @@
More investigation is needed on precisely what should be the new value
for the circuit window, and whether it should vary.
Out of 200, 1\,000 (current value in Tor) and 5\,000, the optimum was
-200 for all levels of packet loss.
+200 for all levels of packet loss. (I'm confused, how do these numbers map to the 512KB and 256KB numbers 2 paragraphs above?)
However this was only evaluated for a fixed network latency and relay
bandwidth, and where all users had the same \texttt{CIRCWINDOW} value.
Therefore, a different optimum may exist for networks with different
@@ -294,6 +294,7 @@

This meddling is tricky though: we could encounter feedback effects if
we don't perfectly anticipate the results of our changes.
+(feedback effects such as?)

Also, Bittorrent is designed to resist attacks like this -- it
periodically drops its lowest-performing connection and replaces it with
@@ -334,6 +335,7 @@
we going to get for throttling or blocking certain content? And does the
capability to throttle certain content change the liability situation
for the relay operator?
+(Imagine an AG, I demand you block all things immoral, or provide me the API to do it myself; you clearly have the ability.  Also anyone who doesn't is going to get served.'')

{\bf Impact}: Medium-high.

@@ -541,6 +543,8 @@
operators, to give them a better sense of community, to answer questions
and concerns more quickly, etc.

+(What about offering paid support options so relay operators have a place to go for help?  Such as corporations or universities running relays get direct phone, email, IM support options?)
+

@@ -554,7 +558,7 @@
network. This competition may give more encouragement for team members to
increase their contribution to the network. Also, when one of the team
members has their relay fail, other team members may notice and provide
-assistance on fixing the problem.
+assistance on fixing the problem.  (Real world examples being SETI screensaver and the MD5 hash crack challenges?  Would this also introduce an incentive to cheat to be the top team?)

\subsection{Funding more relays directly}

@@ -703,7 +707,7 @@
what do we mean by sufficiently?'', that we'll just have to guess about.
The third phase is to actually sort out how to construct and distribute
gold-star cryptographic certificates that entry relays can verify.
-
+(Is this just for public relays?  If I offer 10 bridges, do I lose?)
{\bf Impact}: Medium-high.

{\bf Effort}: Medium-high.
@@ -1242,7 +1246,7 @@
\subsection{The switch to Polipo: prefetching, pipelining, etc}

Polipo makes Tor appear faster, for some web browsing activities. Yay.
-We should continue our plans to migrate to it.
+We should continue our plans to migrate to it. (Polipo needs a more active maintainer, and someone with unix to Windows porting experience to make polipo work correctly in Windows.  Alternatively, could privoxy include some of the polipo features we like?)

\subsection{Better timeouts for giving up on circuits and trying a new one}

@@ -1374,7 +1378,7 @@
As the price increases, their value as status symbols grows, so more people want to buy them.
I don't think it is likely to be the case with Tor, but there could be a few users who might think that the slower the network is, the better it is for anonymity.

-To keep the explanation simple, I have ve made quite a few assumptions, some more reasonable than others.
+To keep the explanation simple, I have made quite a few assumptions, some more reasonable than others.
For the supply curve, I assume that all Tor's bandwidth goes into servicing user requests, it is shared fairly between users, there is no overhead when the number of Tor clients grows, and the performance bottleneck is the network, not clients.
I don't think any of these are true, but the difference between the ideal case and reality might not be significant enough to nullify the analysis.
The demand curves are basically guesswork -- it's unlikely that the true one is as nicely behaved as the ideal ones shown.