93 lines
3.2 KiB
Plaintext
93 lines
3.2 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.
|
|
|
|
- Performance, mostly protocol-neutral.
|
|
|
|
o 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.
|
|
|
|
- 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.
|
|
|
|
- Use if-modified-since to download consensuses
|
|
|
|
|
|
- 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
|
|
o Revise proposal
|
|
- Implement
|
|
|
|
- Proposals to improve and implement if not broken
|
|
D IPv6 support. (Parts of 117, but figure out how to handle DNS
|
|
requests.)
|
|
- 140: Directory diffs
|
|
- Need a decent simple C diff implementation.
|
|
- Need a decent simple C ed patch implementation.
|
|
- 149: learn info from netinfo cells.
|
|
o Start discussion
|
|
- Revise proposal based on discussion.
|
|
X 134: handle authority fragmentation (Needs more analysis)
|
|
- 165: Easy migration for voting authority sets
|
|
- 163: Detect client-status better
|
|
o Write proposal
|
|
- Possibly implement, depending on discussion.
|
|
- 164: Have authorities report relay and voting status better: make it
|
|
easy to answer, "Why is my server not listed/not Guard/not
|
|
Running/etc"
|
|
o Write proposal
|
|
- Possibly implement, depending on discussion
|
|
- 162: Have consensuses come in multiple "flavours".
|
|
o Write proposal
|
|
- Possibly implement, depending on discussion.
|
|
|
|
- Needs a proposal, or at least some design
|
|
- 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 - 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?
|
|
|
|
o Deprecations
|
|
o Make .exit safe, or make it off-by-default.
|
|
|