[tor-bugs] #25687 [Core Tor/Tor]: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 19 05:54:44 UTC 2018


#25687: over-report of observed / self-measure bandwidth  on fast hardware --
important to torflow / peerflow
-------------------------------------------------+-------------------------
 Reporter:  starlight                            |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.6.10
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-bwauth, needs-research, needs-   |  Actual Points:
  proposal?                                      |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by teor):

 * keywords:  tor-bwauth => tor-bwauth, needs-research, needs-proposal?


Comment:

 Replying to [comment:11 juga]:
 > Replying to [comment:10 starlight]:
 > > The concern of this ticket is with regard to the observed value
 published by the daemon rather than the Torflow calculated vote resulting
 from it.
 > …
 > > of the measured bandwidth for a relay to the average of all measured
 bandwidths in a manner short on nuance.  Wrote about possible ways to
 address that here:
 > >
 > > https://github.com/torproject/sbws/issues/182#issuecomment-410745893
 >
 > sorry, i found that comment hard to read

 I found it hard to read, too.

 If we can't understand what you want, it's hard to know what we can do to
 improve tor.

 In tickets or comments, short, specific suggestions are most helpful.

 For substantial changes, please follow the proposal process:
 https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

 For substantial analysis, let's work on questions to ask researchers or
 metrics.
 Many short questions are best, rather than large blocks of text.

 > FWIW, we're continuing that ticket in multiple others. Follow the links
 of https://trac.torproject.org/projects/tor/ticket/27107

 In particular, see #27739 for our draft policy for resolving differences
 between sbws and torflow for sbws 1.0:

 > If a sbws deployment is within X% of an existing bandwidth authority,
 sbws is ok. (The total consensus weights of the existing bandwidth
 authorities are within 50% of each other, see #25459.)

 In later releases, we may modify sbws to achieve better network load-
 balancing.

 We talked about choosing an ideal distribution, but that might not be the
 best idea.

 Instead, see Mike Perry's email:

 > as you make
 choices about how to load balance, please have a specific goal as to
 what target load balancing equilibrium point you're actually going for.

 > we should definitely watch the change
 in our average and quartile variance performance metrics when we first
 switch to sbws.

 https://lists.torproject.org/pipermail/tor-dev/2018-August/013419.html

 We'll have a better idea how to achieve this goal after more network
 measurements and research.

 > > Have considered opening a Trac ticket encompassing the ideas, but am
 waiting for an opportune moment at a point where serious comparison work
 is evident.

 Perhaps a proposal and a ticket would be best?

 > on what you would like to have a serious comparison?

 I'm not sure what sort of comparisons we'll be doing. Mike's email has
 some options.

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


More information about the tor-bugs mailing list