On May 4, 2011, at 7:20 AM, Sebastian Hahn wrote:
On May 4, 2011, at 2:49 AM, Nick Mathewson wrote:
On Mon, May 2, 2011 at 5:23 AM, Sebastian Hahn hahn.seb@web.de wrote:
On Mar 2, 2011, at 8:06 AM, Nick Mathewson wrote:
On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn hahn.seb@web.de wrote:
Design:
When the consensus is generated, the directory authorities ensure that a param is only included in the list of params if at least half of the total number of authorities votes for that param. The value chosen is the low-median of all the votes. We don't mandate that the authorities have to vote on exactly the same value for it to be included because some consensus parameters could be the result of active measurements that individual authorities make.
This is possibly bikeshed, but I would suggest that instead of requiring half of existing authorities to vote on a particular parameter, we require 3 or more to vote on it. (As a degenerate case, fall back to "at least half" if there are fewer than 6 authorities in the clique.)
Hrm. I'm not too happy with this,
My rationale was that in practice, it's a pain in practice to try to get more than 3 or so authority operators to try out an experimental parameter in a timely basis. If the set of authority operators ever grows, getting half of the ops to tweak a parameter in a hurry will get even harder.
Yes, I understand that argument. On the other hand, getting a hold of n-3 authority operators that did set a param can also be hard (I'm thinking about the last time we thought that dirauths might crash the network by distributing ipv6 descriptors, where it took a while to even reach those who had applied our first patch).
unless we also include a way for a majority of authorities to prevent voting on that parameter altogether.
What if we say that as a matter of design, there should always be, for each parameter, a value that's semantically equivalent to the absence of the parameter? That way a majority of authorities can "turn off" any parameter without any additional machinery during the vote.
This could work, but that means we need to re-implement a bunch of our parameters that don't currently work that way. I'm thinking about bug 1947 here, for example. Overloading the param value to mean "this special integer means this specific param is not set" might also lead to interesting situations where we aren't quite sure if 0 or INT32_MIN or something else is responsible for disabling a param. Maybe that's still easier to do than other ideas, and more convenient in the common case where we don't have a bad param that we must not set, which is what we should care about. I'm not sold on your idea just yet, but I do think it can work.
Sebastian
I have since become convinced that it would be better to get this implemented quickly, even if it doesn't have a generic "prevent this param from being set" mechanism. I would thus like to change the proposal to the following (also available in my prop178 branch in my torspec repository). The diff is available at https://gitweb.torproject.org/sebastian/torspec.git/commitdiff/db9a429d005ae...
The branch safer_params in my repository has been updated to reflect the new state of the proposal, the original branch is available as safer_params_old. I'm still targetting this for 0.2.3, but if that's not possible we can also easily delay it.
Thanks Sebastian