| 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.
|
