| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485 |
- 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.
- - 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
- - 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
- - 160: list bandwidth in consensus
- - 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
- - Have authorities report relay and voting status better: make it
- easy to answer, "Why is my server not listed/not Guard/not
- Running/etc"
- - Have consensuses come in multiple "flavours".
- - Weaken the requirements for being a Guard, based on K's
- measurements.
- - Adaptive timeouts for giving up on circuits and streams.
- - Have weight for picking new nodes as guards be less stupid
- - Lagged weight updates in consensuses: don't just move abruptly.
- 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.
|
