doc/TODO.022

   1 Nick's initial priorities for Tor 0.2.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.
   5
   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.
  10
  11 - Design only
  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.]
  15
  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.
  22
  23   - Revise how we do bandwidth limiting and round-robining between
  24     circuits on a connection.
  25
  26   - Revise how we do bandwidth limiting and round-robining between
  27     connections.
  28
  29   - Better flow-control to avoid filling buffers on routers.
  30
  31   - Split AES across cores if possible.
  32   - Split SSL across cores (reach; may require Libevent 2.1).
  33
  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?
  39
  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
  44       like that.
  45
  46   - Use if-modified-since to download consensuses
  47
  48
  49 - Other features
  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
  55         testing.
  56
  57   - Proposals to improve and implement
  58     - 158: microdescriptors
  59       o Revise proposal
  60       - Implement
  61     o 160: list bandwidth in consensus
  62       o Finish proposal
  63       o and actually set it reasonably
  64       o and actually use it.
  65
  66   - Proposals to improve and implement if not broken
  67     D IPv6 support.  (Parts of 117, but figure out how to handle DNS
  68       requests.)
  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.
  73       o Start discussion
  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
  78       o Write proposal
  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
  82       Running/etc"
  83       o Write proposal
  84       - Possibly implement, depending on discussion
  85     - 162: Have consensuses come in multiple "flavours".
  86       o Write proposal
  87       - Possibly implement, depending on discussion.
  88
  89   - Needs a proposal, or at least some design
  90     - Weaken the requirements for being a Guard, based on K's
  91       measurements.
  92 K     - Finish measurements
  93 K?    - Write proposal
  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.
  98       - Write proposal.
  99     - Lagged weight updates in consensuses: don't just move abruptly.
 100 M?    - Write proposal
 101     d Don't kill a circuit on the first failed extend.
 102
 103 - Installers
 104   - Switch to MSI on win32
 105   - Use Thandy, perhaps?
 106
 107 - Deprecations
 108   - Make .exit safe, or make it off-by-default.
 109