Opened 4 months ago

Last modified 3 months ago

#28099 reopened task

Make a policy for adding new sbws relay keys

Reported by: teor Owned by:
Priority: Medium Milestone: sbws: 1.1.x-final
Component: Core Tor/sbws Version:
Severity: Normal Keywords: doc, sbws-1.0-nice-moved-20181128
Cc: pastly, juga, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Split from #28085:

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.

Child Tickets

Change History (10)

comment:1 in reply to:  description ; Changed 4 months ago by 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 file earliest_bandwidth is 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 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 lot sbws. If we keep it, do we know for what we might want to use it?.

comment:2 in reply to:  1 Changed 4 months ago by teor

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 file earliest_bandwidth is 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 lot sbws. 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.

comment:3 Changed 4 months ago by juga

Milestone: sbws 1.0 (MVP nice)

Changing milestone, since this is not really needed before 1.0

comment:4 Changed 3 months ago by teor

Resolution: fixed
Status: newclosed

I don't think there's anything left to do in this ticket.

comment:5 Changed 3 months ago by teor

Milestone: sbws 1.0 (MVP nice)

comment:6 Changed 3 months ago by teor

Keywords: doc added
Resolution: fixed
Status: closedreopened

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.

comment:7 Changed 3 months ago by teor

Keywords: sbws-1.0-nice-moved-20181128 added
Milestone: sbws 1.0 (MVP nice)sbws 1.0.4

Moving all sbws 1.0 nice tickets to 1.0.4

comment:8 Changed 3 months ago by teor

Milestone: sbws 1.0.4sbws 1.1

Milestone renamed

comment:9 Changed 3 months ago by teor

Milestone: sbws 1.1sbws: 1.1.x

Milestone renamed

comment:10 Changed 3 months ago by teor

Milestone: sbws: 1.1.xsbws: 1.1.x-final

Milestone renamed

Note: See TracTickets for help on using tickets.