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,070
    • Issues 1,070
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 38
    • Merge Requests 38
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

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
  • #7509

Closed
Open
Opened Nov 18, 2012 by Mike Perry@mikeperryDeveloper

Publish and use circuit success rates in extrainfo descriptors

arma suggests we publish create cell success rates in the extrainfo descriptors. We want to use these values to measure the actual rate of client circuit success network wide given our current path selection weights.

In this simple case, a graph traversal computation would do the trick, but ideally we want to do it in a way that is liar-resistant. Does this mean we should publish information on our observed peers' rates of CREATE success instead?

Perhaps this can be modeled as an eigenvalue problem, a-la eigenspeed (legacy/trac#5464 (moved)). Since we're computing only a single scalar value for the whole network at the end as opposed to a vector of weights, there might be a simplification we could deploy that reduces the amount of stuff we need to shove into extrainfo.

Either way, an extrainfo-based approach may end up being simpler to implement than a centralized scanner for reliably measuring circuit failure (see legacy/trac#7281 (moved)).

I'm not sure I trust a fully self-reported scheme more without some kind of liar resistance, but it might end up that doing the graph traversal already bakes in as much liar resistance as you'd get from having each node report on its peers. It might be possible to prove this even, but something tells me empirical simulation is as close as we're going to get.

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