Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • 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.

  • Legacy
  • TracTrac
  • Issues
  • #28582

Closed (moved)
Open
Created 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
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None