[metrics-team] IPv6 votes and consensus synthetic flags

teor teor2345 at gmail.com
Fri Dec 8 01:29:15 UTC 2017


> On 8 Dec 2017, at 10:15, Iain Learmonth <irl at torproject.org> wrote:
> 
> Hi All,
> 
> For context, this email is prompted by this commit:
> 
> https://gitweb.torproject.org/karsten/metrics-web.git/commit/?h=tasks-24218-23761&id=57c58b5f1b099ac61e09169661a19b8c4a82984f
> 
> We currently have synthetic flags in consensus-health and in Relay
> Search relating to IPv6. They are not amazingly consistent in my opinion.
> 
> The main distinction between the consensus-health flags and the Relay
> Search flags is that the consensus-health flags are included in votes
> whereas Relay Search bases its synthetic flags on the consensus.
> 
> I'm becoming increasingly convinced that this distinction should go
> away.

Can you be more specific about the change you are proposing?

Is it a change to the names of flags, or their glossary definitions, or
their implementations?

> For all other flags, there is no distinction between the flag in
> the votes and the flag in the consensus. consensus-health even lists
> ReachableIPv6 in the consensus column.
> 
> In the patch above, there is a distinction between "announced" and
> "confirmed". I think perhaps this distinction should be between
> "announced" and "reachable". This also gives two good properties from
> which to generate synthetic flags:
> 
> Announced | Reachable | Votes           | Consensus
> ----------+-----------+-----------------+----------------
> No        | -         | -               | -
> Yes       | No        | UnreachableIPv6 | UnreachableIPv6
> Yes       | Yes       | ReachableIPv6   | ReachableIPv6

This is what actually happens in Tor in the consensus case:

Announced | Reachable | Consistent | Votes           | Consensus
----------+-----------+------------+-----------------+----------------
No        | -         | -          | -               | -
Yes       | No        | -          | UnreachableIPv6 | UnreachableIPv6
Yes       | Yes       | No         | ReachableIPv6   | NoIPv6Consensus
Yes       | Yes       | Yes        | ReachableIPv6   | ReachableIPv6

Where "Consistent" means "the authorities voting an IPv6 address for that
relay agree on the address" (that is, there is a single most frequent address
in the votes, and not a tie for most frequent).

"NoIPv6Consensus" is a rare case. It can happen when relays change their
IPv6 ORPort, and some authorities have the old descriptor, and some have
the new descriptor. Or when two relays have the same identity keys, but
different addresses.

This needs a bug fix for consensus-health, because we leave the consensus
column blank rather than displaying "NoIPv6Consensus ". Which is ok with
me for the moment:

https://trac.torproject.org/projects/tor/ticket/24557#ticket

> The description of the "exiting" property in the above commit matches
> exactly the semantics of the existing Relay Search synthetic flag "IPv6
> Exit" and so I think that's OK. consensus-health currently does not
> generate a flag with similar meanings.
> 
> Relay Search currently does not have any vote information, as Onionoo
> currently does not have this information either. Relay Search will
> therefore only be able to generate UnreachableIPv6 flags based on the
> diff between the relay descriptor and the consensus (IIUC).
> 
> Is there something I'm missing here that means that we shouldn't unify
> these flags?

We need to work out how to handle the NoIPv6Consensus case in
consensus-health.

Otherwise, I think it's sensible to use the same terms.

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20171208/67d0cd02/attachment.sig>


More information about the metrics-team mailing list