Calculate directory request shares from descriptor archives
We should not rely on the dirreq-v3-share that directory mirrors report, but (be able to) calculate directory request shares from the descriptor archives. Three possible approaches are:
- advertised bandwidth / sum of advertised bandwidth
- measured bandwidth / sum of measured bandwidth
- weighted measured bandwidth / sum of weighted measured bandwidth
The first approach is used by 0.2.0.x clients to decide which directory mirror to pick for requesting a network status consensus (among other things). For every relay with non-zero directory port, the weight is the advertised bandwidth (minimum of bandwidth rate and observed bandwidth) as reported by the relay in its server descriptor.
The second approach is used by 0.2.1.x clients and is based on measured bandwidths as written to consensuses. (To be precise, the Bandwidth lines in consensuses are only measured bandwidths if at least three votes contain Measured lines for relays; otherwise, the Bandwidth lines contain the advertised bandwidths as used by 0.2.0.x clients.)
The third approach is used by 0.2.2.x clients and is based on the measured bandwidths plus bandwidth weights as written to consensuses. Before summing up bandwidths, they are weighted depending on a directory's flags: Wbg for Guard, Wbe for Exit, Wbd for Guard+Exit, and Wbm for neither Guard nor Exit.
The graphs in the attachment show the calculated directory request shares for the first and second approach plus the reported dirreq-v3-shares before bandwidth weights were introduced to consensuses. New graphs will follow for the third described approach.
We need to decide if these calculated shares are stable enough to estimate user numbers from them. If not, we should find out what causes volatility, or rather, what made dirreq-v3-share such a nice stable metrics so far.