1 Nick's initial priorities for Tor 0.2.2:
3 NOTE 1: I'm not looking at fiddly little stuff from TODO.021 yet. We
4 can do a step where we triage the nice-to-have issues.
6 NOTE 2: It's easy to list stuff like this with no time estimates and
7 no target dates. I think we should pick a target date for
8 0.2.2, figure out how long the stuff we want will take, and
9 triage accordingly, or vice versa.
12 - Begin design work for UDP transition; identify areas where we need to
13 make changes or instrument stuff early.
14 [multiple weeks, ongoing. Need to do a draft early.]
16 - Performance, mostly protocol-neutral.
17 - Work with Libevent 2.0's bufferevent interface
18 - Identify any performance stuff we need to push back into
19 libevent to make it as fast as we want.
20 - Get a decent rate-limiting feature into Libevent
21 - Get openssl support into Libevent.
23 - Revise how we do bandwidth limiting and round-robining between
24 circuits on a connection.
26 - Revise how we do bandwidth limiting and round-robining between
29 - Better flow-control to avoid filling buffers on routers.
31 - Split AES across cores if possible.
32 - Split SSL across cores (reach; may require Libevent 2.1).
34 - Figure out good ways to instrument Tor internals so we can tell
35 how well our bandwidth and flow-control stuff is actually working.
36 - What ports eat the bandwidth?
37 - How full do queues get?
38 - How much latency do queues get?
40 - Rate limit at clients:
41 - Give clients an upper bound on how much they're willing to use
42 the network if they're not relaying?
43 - ... or group client circuits by IP at the server and rate-limit
46 - Use if-modified-since to download consensuses
50 - Proposals to implement:
51 - 146: reflect long-term stability in consensuses
52 - 147: Stop using v2 directories to generate v3 votes.
53 - Start pinging as soon as we learn about a relay, not on a
54 22-minute cycle. Prioritize new and volatile relays for
57 - Proposals to improve and implement
58 - 158: microdescriptors
61 o 160: list bandwidth in consensus
63 o and actually set it reasonably
64 o and actually use it.
66 - Proposals to improve and implement if not broken
67 D IPv6 support. (Parts of 117, but figure out how to handle DNS
69 - 140: Directory diffs
70 - Need a decent simple C diff implementation.
71 - Need a decent simple C ed patch implementation.
72 - 149: learn info from netinfo cells.
74 - Revise proposal based on discussion.
75 X 134: handle authority fragmentation (Needs more analysis)
76 - 165: Easy migration for voting authority sets
77 - 163: Detect client-status better
79 - Possibly implement, depending on discussion.
80 - 164: Have authorities report relay and voting status better: make it
81 easy to answer, "Why is my server not listed/not Guard/not
84 - Possibly implement, depending on discussion
85 - 162: Have consensuses come in multiple "flavours".
87 - Possibly implement, depending on discussion.
89 - Needs a proposal, or at least some design
90 - Weaken the requirements for being a Guard, based on K's
92 K - Finish measurements
94 - Adaptive timeouts for giving up on circuits and streams.
95 M - Revise proposal 151
96 - Downweight guards more sensibly: be more forgiving about using
97 Guard nodes as non-first-hop.
99 - Lagged weight updates in consensuses: don't just move abruptly.
101 d Don't kill a circuit on the first failed extend.
104 - Switch to MSI on win32
105 - Use Thandy, perhaps?
108 - Make .exit safe, or make it off-by-default.