| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 | 
							- Filename: 167-params-in-consensus.txt
 
- Title: Vote on network parameters in consensus
 
- Author: Roger Dingledine
 
- Created: 18-Aug-2009
 
- Status: Closed
 
- Implemented-In: 0.2.2
 
- 0. History
 
- 1. Overview
 
-   Several of our new performance plans involve guessing how to tune
 
-   clients and relays, yet we won't be able to learn whether we guessed
 
-   the right tuning parameters until many people have upgraded. Instead,
 
-   we should have directory authorities vote on the parameters, and teach
 
-   Tors to read the currently recommended values out of the consensus.
 
- 2. Design
 
-   V3 votes should include a new "params" line after the known-flags
 
-   line. It contains key=value pairs, where value is an integer.
 
-   Consensus documents that are generated with a sufficiently new consensus
 
-   method (7?) then include a params line that includes every key listed
 
-   in any vote, and the median value for that key (in case of ties,
 
-   we use the median closer to zero).
 
- 2.1. Planned keys.
 
-   The first planned parameter is "circwindow=101", which is the initial
 
-   circuit packaging window that clients and relays should use. Putting
 
-   it in the consensus will let us perform experiments with different
 
-   values once enough Tors have upgraded -- see proposal 168.
 
-   Later parameters might include a weighting for how much to favor quiet
 
-   circuits over loud circuits in our round-robin algorithm; a weighting
 
-   for how much to prioritize relays over clients if we use an incentive
 
-   scheme like the gold-star design; and what fraction of circuits we
 
-   should throw out from proposal 151.
 
- 2.2. What about non-integers?
 
-   I'm not sure how we would do median on non-integer values. Further,
 
-   I don't have any non-integer values in mind yet. So I say we cross
 
-   that bridge when we get to it.
 
 
  |