Re: Proposal 167: Vote on network parameters in consensus

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/25/2009 06:32 AM, Roger Dingledine wrote:
>   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.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.)


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.

- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqTsMAACgkQ0M+WPffBEmUqsgCeO2kifV9rLLETbdiCif6lCU5+
TesAn3gxjCzV2opQA/K+gpokm9YgvZn8
=jB8C
-----END PGP SIGNATURE-----