Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #4487

Closed (moved)
(moved)
Open
Created Nov 17, 2011 by Roger Dingledine@arma

Research: Does N23 help especially much in cases where the first hop is slow/flaky?

Once upon a time I thought that using Tor on a modem shouldn't be that bad -- the modem is bad, and the Tor network is bad, but the combination of them should be dominated by whichever is worse.

Tor turns out to not work that way in practice: composing a bad first link with a bad Tor network yields a way worse experience than can be explained by either component by itself.

My hypothesis is that this crummy experience is due to the same issue that N23 aims to address: the fact that our end-to-end flow control needs cells to make it through an entire round trip before more cells are sent.

We should explore N23 simulations in the case where Alice's connection to her first hop is flaky (where flaky might be some combination of low bandwidth, high latency, and non-trivial packet loss), and for various loads on the Tor network side.

Oh, and we should probably get some control runs where we do the simulations with vanilla Tor rather than Tor+N23.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking