[tor-bugs] #27135 [Core Tor/sbws]: Write descriptor bandwidths average in raw results

[Tor Bug Tracker & Wiki]

#27135: Write descriptor bandwidths average in raw results
---------------------------+-------------------------------------
 Reporter:  juga           |          Owner:  juga
     Type:  defect         |         Status:  assigned
 Priority:  Medium         |      Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:  #27108         |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-------------------------------------

Comment (by teor):

 Replying to [comment:19 juga]:
 > ...
 >
 > > How long do you keep old relay bandwidths before deleting them?
 > > I suggest 1 week is a good time.
 >
 > If you mean the `v3bw` files, that's the default right now:
 >
 > https://github.com/pastly/simple-bw-
 scanner/blob/master/sbws/config.default.ini#L77

 You said:

 > > > Taking the descriptor observed bandwidth only when the relay is
 measured and calculating the mean when there're several observed bandwidth
 values for the same relay

 How many observed bandwidth values does sbws use for the mean?
 Does sbws stop using old observed bandwidths after 1 week?

 I think 1 day or 1 measurement is too short. Most observed bandwidths are
 the maximum for 1 day, so they include the whole daily cycle. But the tor
 network has a weekly cycle as well.

 Also, if we want stable bandwidths, using a few days of activity is a good
 idea.

 > > How should we deal with differences between sbws and torflow?
 > >
 > > Here are some example rules:
 > > 1. Any difference between sbws and torflow is a bug in sbws that
 should be fixed
 > > 2. If a sbws deployment is within 50% of any existing bandwidth
 authority, sbws is ok (the existing bandwidth authorities are within 50%
 of each other)
 > > 3. Let's choose an ideal bandwidth distribution for the Tor network,
 and modify sbws until we get that distribution
 > >
 > > I suggest we use 2 as a transition rule, and 3 as a long-term rule.
 (Before we do rule 3 designs, we will need more research.)
 >
 > 2. sounds good. By 50% you mean each relay bandwidth? (or the mean or
 median?). How do we know that the existing bandwidth authorities are
 within 50% each other?, is there any script or graph that shows that?

 Karsten made a graph betweenn July 2017 and February 2018:
 https://trac.torproject.org/projects/tor/ticket/25459#comment:5

 In the graph, the lowest bwauth has 35M total consensus weight, and the
 highest has 70M.

 Adding the graph to metrics.torproject.org is on the metrics roadmap.
 Until then, we can ask Karsten to re-do the graph, or we can write a
 script that adds the bandwidths from each vote.

 > Regarding 3., i think that could be include in the 1. below

 I agree.

 > > Which mode do you think should be the default?
 > > 1. Ignore self-reported bandwidth, so sbws can be more secure (and
 then scale linearly)
 >
 > maybe it does not have to be linear, but use here exponentail decaying
 average or other method over the sbws measurements (not self-reported)

 While sbws shares the network with torflow, we need three stages:
 1. produce measured and observed bandwidths for each relay, using:
   - the most recent result or
   - an average of recent results or
   - a decaying average
 2. scale the sbws results, using:
   - measured bandwidth only (option 1)
   - observed bandwidth and measured bandwidth (option 2)
 3. scale sbws results linearly so the total consensus weight is close to
 torflow's

 > > 2. Use observed bandwidth to scale measurements, so sbws can be more
 like torflow
 >
 > i was imaging that we'd start running it as 2. and after some more
 research on how to scale sbws, switch to 1.

 I agree.

 > > I think we should ask the bandwidth authority operators and network
 team for feedback, so we can answer both these questions.
 >
 > i think so too. All of this would be easier to explain and discuss in
 the next meeting. It's still 1 month away, but anyway it won't be possible
 to run sbws in the dirauths until then, since there won't be new stem
 release until them #26914#comment:3.

 Ok, let's make sure we have meetings for:
 * status update and overall plan
 * helping dirauths (and test network operators) install sbws
 * detailed designs and bug fixes

 (Let's not have too many meetings!)

 > What i would propose is:
 > 1. make PR with the code that store descriptors' observed bandwidth
 > 2. make PR with the code that scale as torflow (previous graph) #27108
 > 3. update sbws documentation with this (probably new ticket)
 > 4. update debian package with new release
 > 5. continue with #27107: obtain more measurements, make more graphs,
 think about previous 3. maybe update the bandwidth file specification

 Yes, we need to update the scaling part of the bandwidth file
 specification. I can do that if you want. Please assign the spec ticket to
 me, when the code is ready for review. Then we can do the spec and code
 and make sure they match before we merge.

 > 6. continue with #21377 and other little-t-tor tickets until the meeting

 Let's catch up with pastly and prioritise the remaining tickets.

 Please take a break if you want to.

 > 7. discuss in the meeting with the network team and dirauths how sbws
 should be scaled

 Sounds good to me.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27135#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online