Remove advertised bandwidth fraction field from relay details document
Onionoo currently reports the "advertised_bandwidth_fraction"
field in its details documents which is specified as follows:
Relative advertised bandwidth of this relay compared to the total advertised bandwidth in the network. If there were no bandwidth authorities, this fraction would be a very rough approximation of the probability of this relay to be selected by clients. Omitted if the relay is not running, or router descriptor containing this information cannot be found.
This field is unrelated to the advertised bandwidth fraction graph. I'm planning to remove that one, too, but that's for another ticket.
This field is also unrelated to the "advertised_bandwidth"
(without "_fraction"
) field that contains the absolute advertised bandwidth value in bytes per second. That one is going to stay.
So, I'm pondering to take out the "advertised_bandwidth_fraction"
field, because its computation is complex and already slightly wrong. Here's why:
-
We need to parse all server descriptors of relays contained in a consensus before we can compute these fractions. If we're missing relays, the other relays will be assigned higher fractions than they really have. This parsing order increases code complexity, and it increases complexity of initializing an Onionoo instance from descriptor archives.
-
We use the advertised bandwidth value from the latest known server descriptor published by a relay, which may be different from the descriptor referenced from the consensus. If a relay published a new descriptor after :50 of the hour, we'll compute a different fraction for it.
It seems that neither Atlas nor Globe uses this field. Compass does use it in its "Advertised Bandwidth" column, but it will remain useful with the other four percentages, too.
I'll leave this ticket open for discussion until beginning of next week. If there are no convincing arguments for keeping this field, I'll remove it. It's an optional field, so there's no need for a month-long heads-up here.