Re: [tor-dev] [PATCH] Proposal 236 and voting

[George Kadianakis <desnacked@xxxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> I inline a patch that specifies how voting should happen in proposal 236.
>
> The changes reflect a discussion I had yesterday with nickm during the
> Tor IRC meeting.
>
> BTW, while I like the simplicity of the new vote (just an integer),
> I'm afraid that this might hide any misconfigurations of the
> guardiness system in authorities. For example, maybe an authority is
> misconfigured and considers only 2 consensuses for guardiness data
> (instead of 6000 consensuses) and if it publishes only an integer
> percentage then we might not notice this misconfiguration. Maybe the
> number of consensuses parsed and the number of months considered
> should also be mentioned somewhere in the votes?
>

I attach a new patch after discussion with Nick.

Some improvements from the previous patch:

- s/GuardAppearanceFraction/GuardFraction . However, if you can think
  of a better name for that keyword, I'm all ears.
- Specify a new consensus method (hopefully I did it correctly)
- Specify that we mean low-median when we say median.

From 8db57a5d734f56c3b866e4ef5864a378d6dabba9 Mon Sep 17 00:00:00 2001
From: George Kadianakis <desnacked@xxxxxxxxxx>
Date: Sun, 31 Aug 2014 16:27:35 +0300
Subject: [PATCH] Specify how Guard Fraction voting should occur.

---
 proposals/236-single-guard-node.txt | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/proposals/236-single-guard-node.txt b/proposals/236-single-guard-node.txt
index d7c03d3..32327db 100644
--- a/proposals/236-single-guard-node.txt
+++ b/proposals/236-single-guard-node.txt
@@ -110,12 +110,14 @@ Status: Open
    To do so, everytime an authority needs to vote for a guard, it
    reads a set of consensus documents spanning the past NNN months,
    where NNN is the number of months in the guard rotation period (10
-   months if this proposal is adopted in full) and calculates the
-   visibility of the guard; that is, in how many consensuses it has
-   had the guard flag.
+   months if this proposal is adopted in full) and calculates in how
+   many consensuses it has had the guard flag for.
 
-   The authorities include the age of each guard by appending
-   '[SP "GV=" INT]' in the guard's "w" line.
+   Then, in their votes, the authorities include the Guard Fraction of
+   each guard by appending '[SP "GuardFraction=" INT]' in the guard's
+   "w" line. Its value is an integer between 0 and 100, with 0 meaning
+   that it's a brand new guard, and 100 that it has been present in
+   all the inspected consensuses.
 
    A guard N that has been visible for V out of NNN*30*24 consensuses
    has had the opportunity to be chosen as a guard by approximately
@@ -142,6 +144,20 @@ Status: Open
    D' = D + F*B, if N has the exit flag
    E' = E + (1-F)*B, if N has the exit flag
 
+1.3.1. Guard Fraction voting
+
+  To pass that information to clients, we introduce consensus method
+  19, where if 3 or more authorities provided GuardFraction values in
+  their votes, the authorities produce a consensus containing a
+  GuardFraction keyword equal to the low-median of the GuardFraction
+  votes.
+
+  The GuardFraction keyword is appended in the 'w' line of each router
+  in the consensus, after the optional 'Unmeasured' keyword. Example:
+    w Bandwidth=20 Unmeasured=1 GuardFraction=66
+  or
+    w Bandwidth=53600 GuardFraction=99
+
 1.4. Raise the bandwidth threshold for being a guard
 
    From dir-spec.txt:
-- 
2.1.0.rc1

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev