summarize proposal 111 in tor-spec

svn:r17544

doc/spec/proposals/000-index.txt

@@ -33,7 +33,7 @@ Proposals by number:
 108  Base "Stable" Flag on Mean Time Between Failures [CLOSED]
 109  No more than one server per IP address [CLOSED]
 110  Avoiding infinite length circuits [ACCEPTED]
-111  Prioritizing local traffic over relayed traffic [FINISHED]
+111  Prioritizing local traffic over relayed traffic [CLOSED]
 112  Bring Back Pathlen Coin Weight [SUPERSEDED]
 113  Simplifying directory authority administration [SUPERSEDED]
 114  Distributed Storage for Tor Hidden Service Descriptors [CLOSED]
@@ -114,7 +114,6 @@ Proposals by status:
    098  Proposals that should be written
    099  Miscellaneous proposals
  FINISHED:
-   111  Prioritizing local traffic over relayed traffic [in 0.2.0.x]
    121  Hidden Service Authentication [in 0.2.1.x]
    128  Families of private bridges [in 0.2.0.x]
    155  Four Improvements of Hidden Service Performance [in 0.2.1.x]
@@ -128,6 +127,7 @@ Proposals by status:
    107  Uptime Sanity Checking [in 0.2.0.x]
    108  Base "Stable" Flag on Mean Time Between Failures [in 0.2.0.x]
    109  No more than one server per IP address [in 0.2.0.x]
+   111  Prioritizing local traffic over relayed traffic [in 0.2.0.x]
    114  Distributed Storage for Tor Hidden Service Descriptors [in 0.2.0.x]
    119  New PROTOCOLINFO command for controllers [in 0.2.0.x]
    122  Network status entries need a new Unnamed flag [in 0.2.0.x]

doc/spec/proposals/111-local-traffic-priority.txt

@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
 Created: 14-Mar-2007
-Status: Finished
+Status: Closed
 Implemented-In: 0.2.0.x
 
 Overview:

doc/spec/tor-spec.txt

@@ -885,12 +885,26 @@ see tor-design.pdf.
 
 7.1. Link throttling
 
-   Each node should do appropriate bandwidth throttling to keep its
-   user happy.
+   Each client or relay should do appropriate bandwidth throttling to
+   keep its user happy.
 
    Communicants rely on TCP's default flow control to push back when they
    stop reading.
 
+   The mainline Tor implementation uses token buckets (one for reads,
+   one for writes) for the rate limiting.
+
+   Since 0.2.0.x, Tor has let the user specify an additional pair of
+   token buckets for "relayed" traffic, so people can deploy a Tor relay
+   with strict rate limiting, but also use the same Tor as a client. To
+   avoid partitioning concerns we combine both classes of traffic over a
+   given OR connection, and keep track of the last time we read or wrote
+   a high-priority (non-relayed) cell. If it's been less than N seconds
+   (currently N=30), we give the whole connection high priority, else we
+   give the whole connection low priority. We also give low priority
+   to reads and writes for connections that are serving directory
+   information. See proposal 111 for details.
+
 7.2. Link padding
 
    Link padding can be created by sending PADDING cells along the
@@ -942,7 +956,6 @@ see tor-design.pdf.
    cells when both a) the window is <= 450, and b) there are less than
    ten cell payloads remaining to be flushed at that edge.
 
-
 A.1. Differences between spec and implementation
 
 - The current specification requires all ORs to have IPv4 addresses, but