|
|
'''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
|
|
|
1. 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.
|
|
|
1. 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?[[BR]]'''
|
|
|
* 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… |
|
|
\ No newline at end of file |