[or-cvs] r18819: {projects} keep beating on section 3 (projects/performance)

Mon Mar 9 09:17:44 UTC 2009

Author: arma
Date: 2009-03-09 05:17:44 -0400 (Mon, 09 Mar 2009)
New Revision: 18819

Modified:
   projects/performance/performance.tex
Log:
keep beating on section 3


Modified: projects/performance/performance.tex
===================================================================

--- projects/performance/performance.tex	2009-03-09 06:20:15 UTC (rev 18818)
+++ projects/performance/performance.tex	2009-03-09 09:17:44 UTC (rev 18819)
@@ -449,14 +449,13 @@
 connections work better in the face of high-volume streams, and
 \prettyref{sec:too-much-load} aims to reduce the overall load on the
 network. The third reason why Tor is slow is that we simply don't have
-enough capacity in the network to handle all the users who want to use
-the network.
+enough capacity in the network to handle all the users who want to use Tor.
 
 Why do we call this the third problem rather than the number one
 problem? Just adding more capacity to the network isn't going to solve
 the performance problem. If we add more capacity without solving the
-issues with high-volume streams, then those streams will expand to use up
-whatever new capacity we add.
+issues with high-volume streams, then those high-volume streams will
+expand to use up whatever new capacity we add.
 
 Economics tells us to expect that improving performance in the Tor network
 (\ie increasing supply) means that more users will arrive to fill the
@@ -464,7 +463,7 @@
 magically just become faster once we implement these improvements.
 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.
+users, thus allowing the new capacity to be more useful to the other users.
 We discuss the supply-vs-demand question more in \prettyref{sec:economics}.
 
 \subsection{Tor server advocacy}
@@ -473,8 +472,8 @@
 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
+\prettyref{sec:congestion} and \prettyref{sec:too-much-load} also.
 
 {\bf Effort}: Medium to high, depending on how much we put in.
 
@@ -540,13 +539,87 @@
 
 \subsection{Funding more relays directly}
 
+Another option is to directly pay for hosting fees for fast relays.
 
-\subsection{incentives to relay}
+The main challenge with this approach is that the efficiency is low:
+at even cheap hosting rates, the cost of a significant number of new
+relays grows quickly. For example, if we can find 100 non-exit relays
+providing 1MB/s for as low as \$100/mo, that's \$120k per year. Figure
+twice that if we count maintenance and coordination costs, the overhead
+to find 100 locations that are on sufficiently different networks and
+administrative zones, etc.
+
+The amount of work involved in running them as exit relays might be a
+few times this cost, due to higher hosting fees, more effort involved
+in establishing and maintaining the right relationships, having lawyers
+nearby, etc.
+
+Plus the costs just keep coming, month after month.
+
+Overall, it seems more sustainable to invest in community outreach and
+education.
+
+{\bf Impact}: Medium.
+
+{\bf Effort}: High.
+
+{\bf Risk}: Low.
+
+{\bf Plan}: If we end up with extra funding, sure. Otherwise, I think
+our time and effort is better spent on the development items that will
+have long-term impact rather than be recurring costs.
+
 \subsection{Fast Tor relays on Windows}
 
-overlapped IO
+Advocating that users set up relays is all well and good, but if most
+users are on Windows, and Tor doesn't support fast relays on Windows
+well, then we're in a bad position.
 
+Nick has been adapting libevent so it can handle a buffer-based
+abstraction rather than its traditional socket-based abstraction. Then
+we will modify Tor so it uses this new abstraction. Nick's blog
+post\footnote{\url
+https://blog.torproject.org/blog/some-notes-progress-iocp-and-libevent}
+provides more detail.
+
+{\bf Impact}: Medium.
+
+{\bf Effort}: High, but we're already halfway through.
+
+{\bf Risk}: Low.
+
+{\bf Plan}: Keep at it. We're on schedule to get a test version (that
+works for Nick) out in September 2009. Then iterate until it works
+for everybody.
+
 \subsection{Node scanning to find overloaded nodes or broken exits}
+
+Part of the reason that Tor is slow is because a few of the relays are
+advertising more bandwidth than they can realistically handle. These
+anomalies might be due to bad load balancing on the part of the Tor
+designers, bad rate limiting or flaky network connectivity on the part
+of the relay operator, or malicious intent. Further, some exit relays
+might fail to give back the `real' content, requiring users to try again
+and again.
+
+If we 
+
+https://svn.torproject.org/svn/torflow/trunk/README.PerfMeasurements
+
+https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/README.ExitScanning
+
+{\bf Impact}: Low.
+
+{\bf Effort}: Medium.
+
+{\bf Risk}: Low.
+
+{\bf Plan}: Keep at it. We're on schedule to get a test version (that
+works for Nick) out in September 2009. Then iterate until it works
+for everybody.
+
+
+
 \subsection{getting dynamic ip relays back into the client list quickly}
 
 Use of nodes on dynamic IP addresses
@@ -564,7 +637,38 @@
 updated P addresses for freshly changed nodes.
 
 
+\subsection{Incentives to relay}
 
+Our blog post on this topic\footnote{\url
+https://blog.torproject.org/blog/two-incentive-designs-tor} explains
+our work to-date on this topic. The current situation is that we have
+two designs to consider: one that's quite simple but has a serious
+anonymity problem, and one that's quite complex.
+
+I think we should move forward with the first (simple but flawed)
+design. There are two phases to moving it forward. The first phase
+is changing Tor's queueing mechanisms to be able to give some circuits
+priority over others. This step also ties into the other development items
+in this document regarding cell-, circuit-, and connection-priorities. The
+second phase is then redesigning the ``gold star'' mechanism so the
+priority that relays earn lasts long enough that there's a sufficient
+anonymity set for them. We'll need to look at current network metrics
+to discover a good upper bound on relay churn.
+
+
+
+{\bf Impact}: Medium-high.
+
+{\bf Effort}: Medium-high.
+
+{\bf Risk}: Medium-high: if we screw up the balance of our
+community-oriented infrastructure, we might end up hurting more than
+we help.
+
+{\bf Plan}:
+
+
+
 \subsection{reachable clients become relays automatically}
 
 
@@ -1029,5 +1133,3 @@
 them the Running flag, they will no longer get into the consensus,
 thus saving directory overhead
 
-mike's overloaded node point
-

