Proposal 167: Vote on network parameters in consensus

[Roger Dingledine]

On Tue, Aug 25, 2009 at 11:37:09AM +0200, Karsten Loesing wrote:
> > 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.
> 
> Why are medians on non-integer values a problem? If there's an odd
> number of non-integer values, we pick the middle one. Otherwise, we
> could calculate the mean of the two middle values. (This could also
> apply to integer values, instead of deciding in favor of the lower of
> the two middle values.)

Ah. By non-integer I had meant "arbitrary string". After all, I didn't
want to predict all the comparator functions we would want on our
arbitrary strings.

But you're right that we could allow floats. That's fine by me.

> Also, we might want to add a requirement that every Tor using these
> values should adapt to changes gently. Taking the maximum number of
> cells in circuit queues as an example: If we change that number from
> 1000 to 101 on half of the directories, and one directory has uptime
> problems, the consensus value might fluctuate between 101 and 1000 (or
> 550 if we used the mean of the two middle values). In that case, we
> probably don't want relays to change their parameters every hour. Maybe
> relays should change their parameters only once in, say, 12 hours, and
> ignore further updates during that time.

Maybe. I think that's quite a bit of work to get right, and will still
be bothering us with edge cases for quite a while. I'd rather take the
simpler approach on the coding side, and focus on ensuring that the
authorities don't get into a situation like that.

--Roger