mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-21 21:44:58 +02:00
48 lines
1.7 KiB
Plaintext
48 lines
1.7 KiB
Plaintext
Filename: 167-params-in-consensus.txt
|
|
Title: Vote on network parameters in consensus
|
|
Author: Roger Dingledine
|
|
Created: 18-Aug-2009
|
|
Status: Open
|
|
Target: 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.
|
|
|