[or-cvs] r18817: {projects} cleanups from reading through it once more (projects/performance)

[arma@xxxxxxxx]

Author: arma
Date: 2009-03-09 02:19:20 -0400 (Mon, 09 Mar 2009)
New Revision: 18817

Modified:
   projects/performance/performance.tex
Log:
cleanups from reading through it once more


Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-03-09 03:34:12 UTC (rev 18816)
+++ projects/performance/performance.tex	2009-03-09 06:19:20 UTC (rev 18817)
@@ -167,7 +167,8 @@
 %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 picking up where Joel left off. He's
+Prof.~Goldberg has a second 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.
 
@@ -177,7 +178,8 @@
 
 {\bf Risk}: High risk that it would need further work to get right.
 
-{\bf Plan}: We should keep working with them to get this project closer
+{\bf Plan}: We should keep working with them (and help fund Chris)
+to get this project closer
 to something we can deploy. The next step on our side is to deploy
 a separate testing Tor network that uses datagram protocols, based on
 patches from Joel and others, and get more intuition from that. We could
@@ -227,14 +229,12 @@
 {\bf Risk}: Medium risk that we haven't thought things through well
 enough and we'd need to back it out or change parts of it.
 
-{\bf Plan}: Once we start on 0.2.2.x (in the next few months), we should
+{\bf Plan}: Once we start on Tor 0.2.2.x (in the next few months), we should
 put the patch in and see how it fares. We should go for maximum effect,
 and choose the lowest possible setting of 100 cells (50KB) per chunk.
 
 %\subsection{Priority for circuit control cells, e.g. circuit creation}
 
-
-
 \section{Some users add way too much load}
 \label{sec:too-much-load}
 
@@ -284,7 +284,8 @@
 give priorities based on recent activity (``if you've sent much more
 than the average in the past 10 seconds, then you get slowed down''),
 or we could base it on the total number of bytes sent on the circuit so
-far, or some combination.
+far, or some combination. Even once we switch to DTLS+UDP, we may still
+want to be able to enforce some per-circuit quality-of-service properties.
 
 This meddling is tricky though: we could encounter feedback effects if
 we don't perfectly anticipate the results of our changes.
@@ -305,7 +306,7 @@
 it will be hard to measure whether we've gotten it right or wrong.
 
 {\bf Plan}: Step one is to evaluate the complexity of changing the
-current code. We should do that for 0.2.2.x in mid 2009. Then we should
+current code. We should do that for Tor 0.2.2.x in mid 2009. Then we should
 write some proposals for various meddling we could do, and try to find
 the right balance between simplicity (easy to code, easy to analyze)
 and projected effect.
@@ -322,9 +323,10 @@
 This is a slippery slope in many respects though. First is the wiretapping
 question: is an application that automatically looks at traffic content
 wiretapping? It depends which lawyer you ask. Second is the network
-neutrality question: ``we're just delaying the traffic''.  Third is the
+neutrality question: remember Comcast's famous ``we're just delaying
+the traffic'' quote. Third is the
 liability concern: once we add this feature in, what other requests are
-we going to get for throttling or blocking certain content, and does the
+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?
 
@@ -370,10 +372,10 @@
 up to 250KB but enforce a long-term rate for all streams of 5KB/s),
 we would probably provide similar performance to what clients get now,
 and it's possible we could alleviate quite a bit of the congestion and
-then get even better performance.
+then get even better and more consistent performance.
 
-Plus, we could make the defaults higher if you're a relay and have passed
-your reachability test.
+Plus, we could make the defaults higher if you sign up as a relay and
+pass your reachability test.
 
 The first problem is: how should we choose the numbers? So far we have
 avoided picking absolute speed numbers for this sort of situation,
@@ -383,7 +385,8 @@
 The second problem is the same as in the previous subsection -- users
 could modify their clients to disable these checks. So we would want
 to do this step only if we also put in throttling at the exits or
-intermediate relays. And if that throttling works, changing clients
+intermediate relays, a la \prettyref{sec:squeeze}. And if that throttling
+works, changing clients
 (and hoping they don't revert the changes) may be unnecessary.
 
 {\bf Impact}: Low at first, but medium-high later.
@@ -394,7 +397,7 @@
 If we pick low numbers, we could accidentally choke users too much.
 
 {\bf Plan}: It's not crazy, but may be redundant. We should consider
-in 0.2.2.x whether to do it, in conjunction with throttling at other
+in Tor 0.2.2.x whether to do it, in conjunction with throttling at other
 points in the circuit.
 
 \subsection{Default exit policy of 80,443}
@@ -404,19 +407,20 @@
 and 443'', and no longer hear DMCA complaints.
 
 Does that mean that most file-sharing attempts go over some other port? If
-only a few exit relays permitted ports other than web browsing, we would
+only a few exit relays permitted ports other than 80 and 443, we would
 effectively squeeze the high-volume flows onto those few exit relays,
 reducing the total amount of load on the network.
 
 First, there's a clear downside: we lose out on other protocols. Part
-of the point here is to be application-neutral. Also, it's not clear
+of the point of Tor is to be application-neutral. Also, it's not clear
 that it would work long-term, since corporate firewalls are continuing
 to push more and more of the Internet onto port 80.
 
 To be clearer, we have more options here than the two extremes. We could
 switch the default exit policy from allow-all-but-these-20-ports to
-accept-only-these-20-ports. We could even get more complex, and apply
-per-stream rate limiting at the exit relays to some ports but not others.
+accept-only-these-20-ports. We could even get more complex, for example
+by applying per-stream rate limiting at the exit relays to streams
+destined for certain ports.
 
 {\bf Impact}: Low? Medium? High?
 
@@ -425,7 +429,7 @@
 {\bf Risk}: The Tor network becomes less useful, roughly in proportion
 to the amount of speedup we get.
 
-{\bf Plan}: I think we should take some of these steps in the 0.2.2.x
+{\bf Plan}: I think we should take some of these steps in the Tor 0.2.2.x
 timeframe. The big challenge here is that we don't have much intuition
 about how effective the changes should be, so we don't know how far to go.
 
@@ -458,19 +462,19 @@
 (\ie increasing supply) means that more users will arrive to fill the
 void. So in either case we shouldn't be under the illusion that Tor will
 magically just become faster once we implement these improvements.
-We place the first two sections higher in priority because their goals
-are to make the new capacity get used by new users, rather than just
-let the high-volume users become even higher-volume users.
+We place the first two sections higher in priority because their goals are
+to limit the ability of the high-volume users to become even higher-volume
+users. Thus the new capacity can be more useful to the other users.
 We discuss the supply-vs-demand question more in \prettyref{sec:economics}.
 
 \subsection{Tor server advocacy}
 
 Encouraging more volunteers to run Tor servers, and existing volunteers
-to keep their servers running, would increase network capacity and
+to keep their servers running, will increase network capacity and
 hence performance.
 
-{\bf Impact}: High, assuming we work on the plans from Sections 1 and
-2 also.
+{\bf Impact}: High, assuming we work on the plans from Sections~1 and~2
+also.
 
 {\bf Effort}: Medium to high, depending on how much we put in.
 
@@ -506,13 +510,15 @@
 We've been working on a new service for relay operators called Tor
 Weather\footnote{\url{https://weather.torproject.org/}}. The idea is
 that once you've set up your relay, you can subscribe to get an email
-when it goes down. We need to work on the interface more, for example to
+whenever it goes down. We need to work on the interface more, for example to
 let people subscribe to various levels of notification, but the basic
-idea seems like a very useful one. Notice that you can also subscribe
-to watch somebody \emph{else}'s relay; so this service should tie in
-well for the people doing advocacy, to let them do easy follow-ups when
-a relay they helped set up disappears.
+idea seems like a very useful one.
 
+With Tor Weather you can also subscribe to watch somebody \emph{else}'s
+relay; so this service should tie in well for the people doing advocacy,
+to let them focus their follow-ups when a relay they helped set up
+disappears.
+
 We are also considering setting up a mailing list exclusively for relay
 operators, to give them a better sense of community, to answer questions
 and concerns more quickly, etc.