Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,067
    • Issues 1,067
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #28582

Closed
Open
Opened Nov 22, 2018 by teor@teor

Document the load-balancing goal for sbws

We should include a section early in the bandwidth spec that documents the load balancing goal for sbws.

Here's my initial draft:

Bandwidth scanners should have a well-defined network equilibrium goal.

For sbws and Torflow without PID control, the network equilibrium goals are:
  1. clients experience reasonably consistent performance
  2. clients experience performance that is as fast as possible, without compromising goal 1
These performance goals include both throughput and latency.

For Torflow with PID control, the goal was:
  1. Each relay has exactly the same spare capacity for an additional stream
This goal was unachievable because Tor did not provide enough feedback on circuit failure.

These non-goals are common suggestions:
  1. Bandwidth is allocated equally across relays
  2. All relay bandwidth is used
These goals are unachievable, because they conflict with the consistent client performance goal.

Based on mike's response from this thread:

I believe quite strongly that even if the Tor network gets faster on
average, if this comes at the cost of increased performance variance,
user experience and perceived speed of Tor will be much worse. There's
nothing more annoying than a system that is *usually* fast enough to do
what you need it to do, but fails to be fast enough for that activity at
unpredictable times.

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

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#28582