[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r18666: {projects} Node advocacy and dynamic IP address usage (committing from (projects/performance)



Author: sjm217
Date: 2009-02-21 12:10:04 -0500 (Sat, 21 Feb 2009)
New Revision: 18666

Modified:
   projects/performance/performance.tex
Log:
Node advocacy and dynamic IP address usage (committing from the beach in Barbados)

Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex	2009-02-21 12:58:12 UTC (rev 18665)
+++ projects/performance/performance.tex	2009-02-21 17:10:04 UTC (rev 18666)
@@ -240,6 +240,26 @@
 There are few options available, as TCP is significantly more popular.
 Voice over IP is one fruitful area, as these require low latency and hence UDP is common, but further investigation is needed.
 
+\section{Tor server advocacy}
+
+Encouraging more volunteers to run Tor servers, and existing volunteers to keep their servers running, would increase network capacity and hence performance.
+One scheme currently being developed is a Facebook application, which will allow node operators to link their Tor nodes to their Facebook profile.
+Volunteers who desire can therefore publicly get credit for their contribution to the Tor network.
+This would raise awareness for Tor, and encourage others to operate nodes.
+
+Opportunities for expansion include allowing node operators for form ``teams'', and for these teams to be ranked on the contribution to the 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 node fail, other team members may notice and provide assistance on fixing the problem.
+
+\section{Use of nodes on dynamic IP addresses}
+
+Currently there is a significant delay between a node changing IP address and that node being used by clients
+For this reason, nodes on dynamic IP addresses will be underutilized, and connections to their old IP address will fail.
+To mitigate these problems, clients could be notified sooner of IP address changes.
+One possibility is to for nodes to estimate how volatile their IP address is, and advertise this in their descriptor.
+Clients ignore nodes with volatile IP addresses and old descriptor.
+Similarly, directory authorities could prioritise the distribution of updated P addresses for freshly changed nodes.
+
 \subsection*{Acknowledgements}
 
 % Mike Perry provided many of the ideas discussed here
@@ -262,8 +282,8 @@
 
 capacity-building:
 
-get dynamic ip address relays known to clients quicker, so they can be
-more useful for the network
+%get dynamic ip address relays known to clients quicker, so they can be
+%more useful for the network
 
 make guard flag easier to get, so there are more of them. also would
 improve anonymity since more entry points into the network.