| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192 |
- 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.
|
