1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
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.
|