Make a policy for adding new sbws relay keys
Split from #28085 (moved):
I think we should also come up with some policy to add/remove key/values. Even if all the ones we have so far seem useful, we are not using it.
I don't understand. Do you mean:
There are some keys in the spec that are not in the code. Or There are some keys in the code that are not in the spec. Or There are some keys in the spec and the code that are not being used by anyone.
For instance, do we have tickets of cases where these key/values were needed/requested?.
When we find this information, we should update the spec so it tells us why we need each value.
Activity
changed milestone to %sbws: unspecified
Replying to teor:
There are some keys in the spec and the code that are not being used by anyone.
It is what i meant. Also, maybe i used wrong the word policy, and i meant any key/value in the bandwidth-file-spec, not only in sbws, and not only for the relays, also for the header
For instance, do we have tickets of cases where these key/values were needed/requested?.
When we find this information, we should update the spec so it tells us why we need each value.
Header key example not being used so far:
earliest_bandwidth. with it we know from which time in the past we considered results in the current bandwidth file. But in which cases we might need to look at that?, when a relay had a very different bandwidth 11 days ago and the fileearliest_bandwidthis 10 days ago?. There was any case in the past (ticket, metrics, irc, ...) where having that information would have helped?. Maybe we don't need a justification for all key/values, but i think having it will also help to understand why it would be useful to archive the file and how it can helps to understand the metrics or problems. A relay key example isrtt. I used it once and generated a graph with the bandwidths. With that i could check that all relays' bandwidth were slightly faster but the shape of the graph was not changing. We are not using it anymore, and the code to obtain it seems to slow down a lotsbws. If we keep it, do we know for what we might want to use it?.Replying to juga:
Replying to teor:
There are some keys in the spec and the code that are not being used by anyone.
It is what i meant. Also, maybe i used wrong the word policy, and i meant any key/value in the bandwidth-file-spec, not only in sbws, and not only for the relays, also for the header
For instance, do we have tickets of cases where these key/values were needed/requested?.
When we find this information, we should update the spec so it tells us why we need each value.
Header key example not being used so far:
earliest_bandwidth. with it we know from which time in the past we considered results in the current bandwidth file. But in which cases we might need to look at that?, when a relay had a very different bandwidth 11 days ago and the fileearliest_bandwidthis 10 days ago?. There was any case in the past (ticket, metrics, irc, ...) where having that information would have helped?. Maybe we don't need a justification for all key/values, but i think having it will also help to understand why it would be useful to archive the file and how it can helps to understand the metrics or problems.earliest_bandwidth is Timestamp formatted as a human-readable date. Timestamp is used by Tor to work out when a bandwidth file is too old to use to vote.
A relay key example is
rtt. I used it once and generated a graph with the bandwidths. With that i could check that all relays' bandwidth were slightly faster but the shape of the graph was not changing. We are not using it anymore, and the code to obtain it seems to slow down a lotsbws. If we keep it, do we know for what we might want to use it?.I think we should disable rtt by default. rtt is useful for debugging, so we should allow operators to turn it on, with a warning that it slows down sbws.
We should document a new key policy. Let's use the bandwidth file spec?
Here are my draft key rules: Each new key should add new information, that can't be calculated from other keys. Keys that contain repeated information should be in the header. The good case and the bad case should be easy for humans to see. Add a small number of keys to identify problems. Then add more keys to diagnose the important problems.
Trac:
Resolution: fixed to N/A
Keywords: N/A deleted, doc added
Status: closed to reopenedI suggested that we use the tor proposals process, or bandwidth-file-spec patches for small changes.
Let's continue the conversation on this thread: https://lists.torproject.org/pipermail/tor-dev/2019-April/013785.html
Trac:
Resolution: N/A to fixed
Status: reopened to closedmentioned in issue #29333 (closed)