[tor-bugs] #20403 [Metrics]: Make it easier for relay operators to find their observed bandwidth

[Tor Bug Tracker & Wiki]

#20403: Make it easier for relay operators to find their observed bandwidth
-------------------------+---------------------
 Reporter:  teor         |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:
Component:  Metrics      |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
 Reviewer:               |        Sponsor:
-------------------------+---------------------

Comment (by teor):

 Replying to [comment:1 tom]:
 > So depictor (consensus-health) uses stem to get its info, so it's really
 easy for me to include any information here:
 https://stem.torproject.org/api/descriptor/router_status_entry.html   It's
 really difficult to get anything else - downloading descriptors for the
 network would take a _lot_ of time, just downloading the votes and
 consesnsuses takes 10+ minutes.

 I think I might be asking for the "bandwidth (int) -- bandwidth claimed by
 the relay (in kb/s)", but I am not sure how it is sourced.

 > I'm a little confused by the terms you're using.  When you say "observed
 bandwidth" do you mean the relay's 'advertised bandwidth' a relay operator
 puts in the config, the unit-less values the bwauths calculate and vote
 on, or a third thing I'm not recalling? (And if it is the third thing,
 where does that get exposed: Consensus, MicroConsensus, Descriptor,
 Microdescriptor, or ExtraInfo?)

 By "observed bandwdith" I mean the "bandwdith-observed" figure from the
 descriptor "bandwdith" line:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418

 I'd like it more easily available because it's one of the two figures that
 an operator doesn't set themselves - the other is the measured bandwidth.

 And used in conjunction with the advertised bandwidth to calculate the
 bandwidth in the consensus "w" line:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2268

 (That figure is useful, but more confusing, because it's sometimes the
 advertised bandwidth, and sometimes the observed bandwidth.)

 >  And then the same question for "consensus weight".

 Whatever Atlas uses for consensus weight in the relay details page.
 I assume it's measured bandwidth from the consensus w line, but I'm not
 sure.

 If it is, it's already there in the consensus column of the relay flags
 table.

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2274

 > Looking closer at the stem documentation, I might have done things wrong
 in #20372 actually. Adding Damian to confirm the below is correct:
 >
 > - On a vote .measured is the bwauth's vote for the relay's (unitless)
 bandwidth value
 > - On a consensus .measured is the average* of the bwauths votes for the
 relay's (unitless) bandwidth value
 > - On a vote or consensus .bandwidth is the _relay's_ advertised
 bandwidth (and is what teor wants available)

 Not quite, I think it's the minimum of advertised and observed, which
 confuses a lot of operators, because sometimes it's controlled by the
 torrc, and other times by their relay's self-reported performance:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418

 > *not really average but let's pretend it is for simplicity

 (low-median)

 > (Currently, the value on each Authority is the .measured but the value
 on the consensus is .bandwidth - which would be wrong as the consensus
 would be reporting the self-reported advertised bandwidth...)

 That's strange, because all the figures in the table appear to be a low-
 median (consensus .measured) to me.

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