mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 12:23:32 +01:00
99 lines
3.3 KiB
Plaintext
99 lines
3.3 KiB
Plaintext
Nick's initial priorities for Tor 0.2.2:
|
|
|
|
NOTE 1: I'm not looking at fiddly little stuff from TODO.021 yet. We
|
|
can do a step where we triage the nice-to-have issues.
|
|
|
|
NOTE 2: It's easy to list stuff like this with no time estimates and
|
|
no target dates. I think we should pick a target date for
|
|
0.2.2, figure out how long the stuff we want will take, and
|
|
triage accordingly, or vice versa.
|
|
|
|
- Design only
|
|
- Begin design work for UDP transition; identify areas where we need to
|
|
make changes or instrument stuff early.
|
|
|
|
[multiple weeks, ongoing. Need to do a draft early.]
|
|
|
|
- Performance, mostly protocol-neutral.
|
|
- Work with Libevent 2.0's bufferevent interface
|
|
- Identify any performance stuff we need to push back into
|
|
libevent to make it as fast as we want.
|
|
|
|
- Revise how we do bandwidth limiting and round-robining between
|
|
circuits on a connection.
|
|
|
|
- Revise how we do bandwidth limiting and round-robining between
|
|
connections.
|
|
|
|
- Better flow-control to avoid filling buffers on routers.
|
|
|
|
- Split AES across cores if possible.
|
|
- Split SSL across cores (reach; may require Libevent 2.1).
|
|
|
|
- Figure out good ways to instrument Tor internals so we can tell
|
|
how well our bandwidth and flow-control stuff is actually working.
|
|
- What ports eat the bandwidth?
|
|
- How full do queues get?
|
|
- How much latency do queues get?
|
|
|
|
- Rate limit at clients:
|
|
- Give clients an upper bound on how much they're willing to use
|
|
the network if they're not relaying?
|
|
- ... or group client circuits by IP at the server and rate-limit
|
|
like that.
|
|
|
|
|
|
|
|
- Other features
|
|
- Proposals to implement:
|
|
- 146: reflect long-term stability in consensuses
|
|
- 147: Stop using v2 directories to generate v3 votes.
|
|
- Start pinging as soon as we learn about a relay, not on a
|
|
22-minute cycle. Prioritize new and volatile relays for
|
|
testing.
|
|
|
|
- Proposals to improve and implement
|
|
- 158: microdescriptors
|
|
N - Revise proposal
|
|
- 160: list bandwidth in consensus
|
|
RNM? - Finish proposal
|
|
- and actually set it reasonably
|
|
- and actually use it.
|
|
|
|
- Proposals to improve and implement if not broken
|
|
- IPv6 support. (Parts of 117, but figure out how to handle DNS
|
|
requests.)
|
|
- 140: Directory diffs
|
|
- 149: learn info from netinfo cells.
|
|
- 134: handle authority fragmentation (Needs more analysis)
|
|
|
|
- Needs a proposal, or at least some design
|
|
- Detect client-status better
|
|
N - Write proposal
|
|
- Have authorities report relay and voting status better: make it
|
|
easy to answer, "Why is my server not listed/not Guard/not
|
|
Running/etc"
|
|
N - Write proposal
|
|
- Have consensuses come in multiple "flavours".
|
|
N - Write proposal
|
|
- Weaken the requirements for being a Guard, based on K's
|
|
measurements.
|
|
K - Finish measurements
|
|
K? - Write proposal
|
|
- Adaptive timeouts for giving up on circuits and streams.
|
|
M/N - Revise proposal 151
|
|
- Downweight guards more sensibly: be more forgiving about using
|
|
Guard nodes as non-first-hop.
|
|
- Write proposal.
|
|
- Lagged weight updates in consensuses: don't just move abruptly.
|
|
M? - Write proposal
|
|
d Don't kill a circuit on the first failed extend.
|
|
|
|
- Installers
|
|
- Switch to MSI on win32
|
|
- Use Thandy, perhaps?
|
|
|
|
- Deprecations
|
|
- Make .exit safe, or make it off-by-default.
|
|
|