[tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-----------------------------+------------------------------
 Reporter:  starlight        |          Owner:  metrics-team
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------

Comment (by teor):

 I'm not sure I understand the problem, or its likely cause. I am cc'ing
 Mike, because he has more experience with bandwidth weighting.

 I'm going to ask some questions to work out what is happening. I find big
 blocks of text confusing, so it would help me if you'd answer after each
 question.

 Replying to [ticket:28328 starlight]:
 > Totals of consensus weighs shift erratically due to some aspect of vote
 median behavior in the consensus.  E.g. (Exit,Exit+Guard) moved 12.5% in
 12 hours on 09-Jul-18 12:00 to 23:59 UTC while votes steady.

 The consensus is created deterministically from the votes. If the votes
 are identical, the consensus will be identical. In particular, the
 consensus weights are the low-median of the votes for each relay: they
 can't change unless the votes change.

 What is changing in the votes to change the consensus weights?

 Are some authorities not voting?
 Are the Bandwidth= figures in the votes actually different?

 Or, are you talking about overall relay selection probability, which
 depends on the total consensus weight?

 Do other relays start Running or stop Running?
 Do some relays start or stop being Guard or Exit?

 > Twenty percent in 56 hours with votes shifting.  The behavior results in
 significant adjustment to the selection probability of relays with
 unchanged consensus weights.

 The goal of the bandwidth weighting system is to provide a set of weights
 that give clients equal performance, regardless of the particular relays
 they choose.

 Maybe the load on the relay changes erratically, so its selection
 probability should also change?
 Maybe other available relays change their performance, so this relay
 should get used more (or less)?

 Do these erratic changes affect client performance?
 Would clients perform better or worse without these erratic changes?

 > Please add to
 >
 > https://metrics.torproject.org/totalcw.html

 I think a separate graph would be better: having 6 authorities * 5
 categories = 30 lines on a graph will be unmanageable.

 Replying to [comment:5 starlight]:
 > I thought more about weighting the values (as in Relay Search), but it
 makes no difference for the purpose which is to see if the totals of
 medians continue jumping about with SBWS as presently happens with
 Torflow.  Simply graphing the total consensus for each selection class,
 Exit, Guard, Middle is sufficient.

 I agree we should monitor the behaviour of each class of relays.

 > (Exit,Exit+Guard) is the total of Exit-Only and Exit+Guard flagged
 relays as this is the set used for choosing exits

 No, this is the set that is *currently* used for choosing exits. If tor
 gets more exits in future, then Exit+Guard may be used as Guard.

 So we shouldn't hard-code the assumption that Exit+Guard is only used as
 an Exit.

 Instead, I suggest that we match the sets in
 https://metrics.torproject.org/bwhist-flags.html

 Guard & Exit
 Guard only
 Exit only
 Middle only

 I noticed some other things while reviewing this ticket, I'll create child
 tickets for them.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28328#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online