[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 juga):

 > > Should i still take the observed bandwidth every hour and calculate
 the mean and/or decaying average?
 >
 > If the simple method works, then let's keep it simple.

 agree, i also looked again Torflow and realized the is only taking the
 last one, so it's even simpler

 > 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

 However they will be compressed after 1 day with the debian default
 configuration:

 https://salsa.debian.org/pkg-privacy-
 team/sbws/blob/debian/master/debian/sbws.cron.d#L1

 > 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?
 Regarding 3., i think that could be include in the 1. below

 > 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)

 > 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 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.

 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
 6. continue with #21377 and other little-t-tor tickets until the meeting
 7. discuss in the meeting with the network team and dirauths how sbws
 should be scaled

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