|
|
# PLANS FOR 2021
|
|
|
|
|
|
## Q4
|
|
|
|
|
|
### Retrospective Q3
|
|
|
|
|
|
#### Review Q3 - what did we do?
|
|
|
|
|
|
- prop 328 : Expose overload metrics on the MetricsPort
|
|
|
- conflux proposal
|
|
|
- arti progress: guards (incomplete), circuit timeout inference, resolve support, stream isolation, persistent state, tech-debt reduction/prevention, improved documentation, some CI improvements.
|
|
|
- Lots of hacking towards congestion control (S61 prop 324)
|
|
|
- Ntor v3 (proposal 332)
|
|
|
- Work towards Shadow CI setup and establishing baselines
|
|
|
- Rust developer hiring
|
|
|
- Migrated Tor release responsibility to Alex + David
|
|
|
- Support of anti-censorship team (s30/s28)
|
|
|
- Support of network health team
|
|
|
- Moved things that ran on random dev boxes to Gitlab CI (Coverity and documentation generation)
|
|
|
- Hired 2 more people for the team
|
|
|
|
|
|
##### What worked well?
|
|
|
|
|
|
- Thursday meetings continue to have very high value when we have bigger discussion topics.
|
|
|
- Monday meetings are usually pretty snappy now. Good we merged s61 meeting into those to only have one allocated meeting hour for this sync.
|
|
|
- Interactions between NT and NHT works flawlessly (thankd david!)
|
|
|
- Delegations of tor.git related topics to other than Nick
|
|
|
- We have become better at talking about doing things differently (and also doing things differently)
|
|
|
- We have become VERY GOOD at hiring and talking about hiring.
|
|
|
- Handover from asn went smooth.
|
|
|
- Mike has gotten much more incorporated into the team.
|
|
|
- Interactions between Hiro (metrics), NHT, Shadow (Jim), and TPA (for getting hw?) for s61 seems to be going smooth.
|
|
|
- We handled the FlashFlow conversations in a sensible way and the conversations with NRL was fine.
|
|
|
- We got Jim 2 days/week for NT things with help of Isa and Sue.
|
|
|
|
|
|
##### What could work better?
|
|
|
|
|
|
- Lots of things dropped on the floor while ahf was AFK: Windows CI, s28/s30 tickets, peer feedback, but things seemed to move on well any way.
|
|
|
- We are still not doing all the things the new org structure wants: 1:1 in a structured way, etc.
|
|
|
- I think we lost a bit our connection on what is happening with sbws, but NHT took it over.
|
|
|
- We could be better at getting small- or medium-sized design proposals onto our roadmap.
|
|
|
- We need to get more of the team spending more time in Rust.
|
|
|
- Sometimes we postpone activities waiting for publishing infrastructure (dev portal, arti.tpo, ...)
|
|
|
- We should spend more time on longer-term vision and needs/wants, so they can land in funding proposals <---
|
|
|
|
|
|
|
|
|
### MUST HAVE
|
|
|
|
|
|
- Sponsor 30 - ahf (goals: wrap up and move to supporting ACT)
|
|
|
- [2.3.3 - Improve ability for bridgedb/authority to test bridges that only expose a pluggable transport.](https://gitlab.torproject.org/groups/tpo/-/milestones/5)
|
|
|
- [2.4.5 - Increase stability and resilience of bridge authority and bridgeDB by exploring and implementing decentralizations of those services.](https://gitlab.torproject.org/groups/tpo/-/milestones/6)
|
|
|
|
|
|
- [Sponsor 61](https://gitlab.torproject.org/groups/tpo/-/milestones/16)
|
|
|
- O1.1: Optimize user-facing performance by tuning parameters of previously deployed Tor network improvements <--- we need ahf + dgoulet + jim + mike
|
|
|
- [O2: sbws with congestion control](https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40022) (Tor support to pin exits/Sos Rends, or just wait)
|
|
|
- O3.2: Implement promising performance improvements from evaluation in O3.1. <--- mike + dgoulet
|
|
|
- [tuning and stabilizing congestion control in shadow](https://gitlab.torproject.org/tpo/core/tor/-/issues/40405)
|
|
|
- O4.1: Improve and implement network health monitoring and scanning. <--- we need ahf + dgoulet
|
|
|
- https://gitlab.torproject.org/tpo/core/tor/-/issues/40312#note_2727655
|
|
|
- https://gitlab.torproject.org/tpo/core/tor/-/issues/40477
|
|
|
|
|
|
- [Sponsor 96](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/groups/tpo/-/milestones/24 [will need scope on support to TGP & Calyx & OnionShare) <-- estimated 1 eng full time for 9 months (ahf)
|
|
|
- O3.3: Improve automatic censorship detection in OnionShare desktop. - starts in November by OnionShare
|
|
|
- O3.5: Integrate Tor+Snowflake/obfs4 capabilities into mobile applications. - starts in November by TGP & Calyx
|
|
|
- O3.5.1 OnionShare, iOS
|
|
|
- O3.5.2: OnionShare, Android
|
|
|
- O3.5.3: Save (Share-Archive-Verify-Encrypt) by OpenArchive
|
|
|
|
|
|
|
|
|
- [Sponsor 101](https://gitlab.torproject.org/groups/tpo/-/milestones/32) [will need scope when project starts] <--- estimated 1 eng full time for 18 months (nick and jim and eta and ahf)
|
|
|
- O3.2 Enhance Tor to act as a VPN service, rather than an opt-in proxy as it does today. - will kickoff in mid October (more info on this activity in milestone link ^) - needs tickets {nickm makes tickets}
|
|
|
- Identify high risk areas
|
|
|
- Start a design on what needs to be built
|
|
|
- List and write missing design proposals
|
|
|
- Evaluate libraries we can use and stuff we can avoid writing
|
|
|
- Evaluate per-platform capabilities
|
|
|
|
|
|
- Sponsor 119 (zomg arti) (nickm, jim, eta,... and ideally the rest of us)
|
|
|
- 0.0.1 release at end of October <--- we need nick + everybody else
|
|
|
- arti website is deployed
|
|
|
- 0.1.0 work, targetting release at end of Feb <--- we need nick + everybody else + new hire
|
|
|
|
|
|
|
|
|
From OKRs:
|
|
|
- Objective: Define how Tor is going to use Tokens
|
|
|
- Start discussing specification for a token-system that is compatible with Tor’s use-cases. (mike and nick are going to talk with IETF in October)
|
|
|
- Objective: Enhance the Network Performance for Tor users (s61 work is going to move this forward)
|
|
|
- Develop a Shadow-based workflow suitable for evaluating and tuning congestion control changes.
|
|
|
- Have N% of Exits upgrade to congestion control release 1 month after stable release. Mike and Alex working on defining N.
|
|
|
- Average throughput increases proportionally to spare utilization.
|
|
|
- TTFB/Circuit RTT stays the same or improved.
|
|
|
|
|
|
- Objective: Build and Release Arti (s119 falls under this objective)
|
|
|
- Arti 0.0.1 is released, and has no missing features we deem essential for security and privacy.
|
|
|
- Arti 0.1.0 is released, in a form suitable for embedding, with measurable client performance.
|
|
|
- All features originally planned for 0.1.0 and 0.0.1 are built.
|
|
|
- Arti is less than 4 MB to download. {nickm makes ticket arti#172 to track}
|
|
|
- Arti’s client performance is no more than 30% slower than C Tor for onionperf metrics {need to start tracking performance, nickm opens arti#173 to track}
|
|
|
- The tor-client API is stable in a way that we’re willing to support it going forward.
|
|
|
|
|
|
- Objective: The team is spending time in Rust (covered by s119)
|
|
|
- Objective: Continue Shadow Development
|
|
|
- Release Shadow 2.0
|
|
|
- Develop a Shadow-based workflow suitable for evaluating and tuning congestion control changes (in collab with s61)
|
|
|
- Have Shadow network integration test running with Arti clients and C-Tor relays.
|
|
|
|
|
|
- Deprecate v2 onion services.
|
|
|
|
|
|
|
|
|
### NICE TO HAVE
|
|
|
|
|
|
- [middleonly relay](https://gitlab.torproject.org/tpo/core/tor/-/issues/40448) - nick
|
|
|
- look at design alternatives
|
|
|
- communicate with neel about their code
|
|
|
|
|
|
- [review implementation of Prop 327 DoS defense)(https://github.com/jmhrpr/tor-prop-327) (HS PoW over Intro):
|
|
|
- Not urgent rn, but if the onion DoS's start happening again, this is the least intruisive defense
|
|
|
|
|
|
|
|
|
- Objective: Support Other Teams with Tor issues
|
|
|
- We have no open tickets from these other teams (Anti-Censorship, Browser, Network Health) that are marked as "blocking" that are older than 1 month.
|
|
|
- We have a process in place to regularly triage the tickets listed above, with other teams, and coordinate.
|
|
|
|
|
|
- Objective: Organize the Team
|
|
|
- We have a wiki-page of all responsibilities with links to playbook-style documentation.
|
|
|
- For everything that only one person knows how to do, we have a playbook for it.
|
|
|
- All network-team documentation is indexed in one place.
|
|
|
- The entire team (anonymously) lists their work related happiness as at least 7/10.
|
|
|
|
|
|
- Objective: Continue Shadow Development
|
|
|
- Have design and prototype ready for distributed Shadow simulations
|
|
|
|
|
|
|
|
|
## Q3
|
|
|
|
|
|
1. security fixes
|
|
|
2. tor network performance
|
|
|
- shadow experiments
|
|
|
- congestion control
|
|
|
3. arti
|
|
|
- margot things for network health team
|
|
|
- shadow simulations should be possible with arti
|
|
|
4. CI with follow up with sysadmin teams
|
|
|
5. HS v2 deprecation
|
|
|
- Onion Balance for V3: Multi-service support. Possibly to reduce memory consumption to avoid having to run multiple instances.
|
|
|
6. Shadow v2 will come out in this period.
|
|
|
|
|
|
|
|
|
## Q1 & Q2
|
|
|
|
|
|
* [Making the Tor network faster & more reliable for users in Internet-repressive places ](https://gitlab.torproject.org/tpo/core/tor/-/issues/40143)
|
|
|
* Main large things:
|
|
|
* Proposal 325 (packed relay cells) [possibly join with prop319]
|
|
|
* Proposal 324 (congestion control)
|
|
|
* Proposal 329 (conflux)
|
|
|
* Reach item: Re-do floodflow experiment; provide relays way to specify shared machine/link
|
|
|
* Smaller things:
|
|
|
* Proposal 328 (Relay overload reporting)
|
|
|
* Proposal 291 (Two guards - ensuring it works; it seems to in CBT experiments)
|
|
|
* Long tail of bugfixes/likely issues:
|
|
|
* EWMA/KIST
|
|
|
* OOMkiller issues wrt conflux and congestion control
|
|
|
* [Shadow](https://gitlab.torproject.org/tpo/core/shadow/-/wikis/home) vs live network discrepancies
|
|
|
* Refactoring ancient pieces of circuit timeouts? (seems not needed)
|
|
|
* [Arti](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/TODO)
|
|
|
* what do we need to have it ready for replacement of C code? Is that possible?
|
|
|
* more involvement. maybe funding.
|
|
|
* define scope for MVP
|
|
|
* what could be a reasonable timeline?
|
|
|
* by the end of the year have a client (milestones B and C completed)
|
|
|
* MILESTONE B: Secure minimal client
|
|
|
* Guard nodes <--- first thing to work on
|
|
|
* Correct path selection <-- important but current restrictions have issues
|
|
|
* Timeouts
|
|
|
* Circuit timeout logic
|
|
|
* Connection timeout logic.
|
|
|
* What other kinds of timeouts?
|
|
|
* Connection padding <-- not necessary
|
|
|
* Circuit padding (with padding machines)
|
|
|
* Build preemptive circuits <-- very important
|
|
|
* Change behavior depending on network parameters
|
|
|
* CBT logic?
|
|
|
* Pathbias logic <-- it can be dropped
|
|
|
* Figure out where to put a specific async executor and/or TLS implementation in our stack.
|
|
|
* MILESTONE C: Client feature parity
|
|
|
* V3 onion services
|
|
|
* Fairness on circuits/streams?
|
|
|
* Support for using bridges
|
|
|
* Pluggable transport support
|
|
|
* Controller API?
|
|
|
* Dormant mode?
|
|
|
* Transparent proxy mode(s)
|
|
|
* what could be a [timeline for deprecating](./NetworkTeam/DeprecatingTorC) tor C?
|
|
|
* Technical debt
|
|
|
* Tooling: CI
|
|
|
* Transition to arti is the best way to tackle technical debt right now.
|
|
|
* Preparation for future work:
|
|
|
* Proposal 319 (fragmented cells) [may be needed for proof-of-work, will be needed for pq or walking onions]
|
|
|
* Proposal 321 (happy families)
|
|
|
* Walking onions (if funded)
|
|
|
* Authority contact decentralization
|
|
|
* Evaluating potential next-step cryptography (tagging + pq)
|
|
|
* Prototype of Proposal 327 (PoW over intro) |