wiki:org/meetings/2019Stockholm/Notes/ScalabilityProjectFunding

Scalability Project, Creating Funding Proposals

Goal: Understand next steps in scalability work, outline how we can approach funders with this project.

Where are we now?

  • Tor network capacity has increased over time
  • But we need to make that experience more predictable, more uniform
  • Tune our network and look for performance issues
  • Even if Tor is good on average the worst cases are quite bad, they are bad enough to turn users away (‘long tail’)
  • We want to improve the network and add more relays, but it isn’t at the place to handle that effectively
  • Right now we don’t have a good handle on what’s going on the Tor network
    • Baselines help us keep a consistent experience for the user
    • Human knowledge
  • Building a cycle: every time we make improvements after this improvement will happen faster, work better, be more effective

What is the benefit of a scalability project?

  • Remove a major barrier for people to start and continue using Tor
    • Give up because it’s slow: we want to retain users
    • Problems could put them in danger
    • Popularizing Tor / reputation
  • Better prepared for the load that will happen later: handle more people, more third party integration
  • Better handle spikes in usage
    • Censorship happens, large spikes in users, the better the network can handle these spikes, the better we can respond to censorship

Who benefits from this?

  • Third party integrators
  • Users under censorship
  • Users in general

Thinking through a phase 0-2 project

  1. Phase 0 is low hanging fruit
  2. Phase 1 baseline metrics & measurements + building list of performance improvements & evaluating
    • baselines of browser level usability (ie, testing performance of webpages—how does it go, what is it like for a user?). we’re at the beginning of this process, we need to measure success and prove that what we’re doing is working.
  3. Phase 2 doing the science, deploying improvements, measure to see if we are right
  • If we want the average user experience to get better…
    • We need to increase our capacity
  • If we want the drastically negative experiences… (long tail)
    • We cut off the smaller relays
    • We could do right now, it’s easy enough to measure
  • Production tuning
  • Low-hanging single client tasks: we’re going to do two key performance changes; we’re going to test and see which one made the biggest difference
  • We do tests, get results, not sure if we believe them, need experts to look over the data to verifying / figuring out what went wrong, debugging analysis (this is an important part of this proposal)
  • Developing a new data model that will allow us to more quickly run experiments b/c we can design queries that help us look at the data quickly
  • Staff: 1 to 2 devs on network, 1 to 2 metrics/network health side
  • Time: ~6 months. Requires wall clock time to measure changes: at least weeks per experiment. Gets faster if we have both the machines & engineers to simultaneously compare Shadow to the live network—getting to the point that we can trust Shadow
  • The more funding we get for this, the faster we can do these experiments, the better we get at this process, the faster we can provide results

After Phase 2, what happens?

  • Start to add the dedicated network health monitoring, actively monitor the scan results and analyzing them
  • Doing the queries over the metrics data —> contacting the relays & improving the network in this way
  • More in-depth dev work
    • Load balancing
    • SPWS improvements
  • Research horizon
    • Adding research programmers (would require a dedicated new developers)

What could third parties do to help this project?

  • Brave could help us understand what their users performance looks like on Tor. They may have their own user studies that can help tell us more about who/why/etc uses the Tor function.
  • Bitcoin people? As China works towards censoring bitcoin, etc…
Last modified 5 months ago Last modified on Jul 19, 2019, 7:25:13 PM