Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  sbws:
 |  unspecified
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  doc, sbws-1.0-nice-moved-20181128,   |  Actual Points:
  no-changes-version, docs, bandwidth-file-  |
  spec, tor-spec |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 I 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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  sbws:
 |  unspecified
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  doc, sbws-1.0-nice-moved-20181128,   |  Actual Points:
  no-changes-version, docs, bandwidth-file-  |
  spec, tor-spec |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * points:   => 0.2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  sbws:
 |  unspecified
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, sbws-1.0-nice-moved-20181128,   |  Actual Points:
  no-changes-version, docs, bandwidth-file-  |
  spec, tor-spec |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * milestone:  sbws: 1.1.x-final => sbws: unspecified


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, sbws-1.0-nice-moved-20181128,   |  Actual Points:
  no-changes-version, docs, bandwidth-file-  |
  spec, tor-spec |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * keywords:
 doc, sbws-1.0-nice-moved-20181128, no-changes-version, docs, sbws-11x-
 final-removed-20190312
 =>
 doc, sbws-1.0-nice-moved-20181128, no-changes-version, docs,
 bandwidth-file-spec, tor-spec
 * milestone:  sbws: unspecified => sbws: 1.1.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  reopened
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * keywords:   => doc
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * milestone:   => sbws 1.0 (MVP nice)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => closed
 * resolution:   => fixed


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by juga):

 * milestone:  sbws 1.0 (MVP nice) =>


Comment:

 Changing milestone, since this is not really needed before 1.0

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 Replying to [comment:1 juga]:
 > Replying to [ticket:28099 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Replying to [ticket:28099 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?.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs