[tor-bugs] #27135 [Core Tor/sbws]: Write descriptor bandwidths average in raw results
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 27 03:07:20 UTC 2018
#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):
This has become a huge ticket, so I'm splitting it into child tickets of
#27108.
Replying to [comment:20 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.
Let's talk about how long to keep bandwidths in #27338.
> > > 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?
Let's discuss the policy for differences between torflow and sbws in
#27339.
> > > 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
See #27338.
> 2. scale the sbws results, using:
> - measured bandwidth only (option 1)
> - observed bandwidth and measured bandwidth (option 2)
See #27339.
> 3. scale sbws results linearly so the total consensus weight is close to
torflow's
Let's talk about final scaling in #27340.
After final scaling, we also need a rounding step. See #27337.
> > > 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 will send an email to tor-dev now.
> > 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:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list