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 - Performance, mostly protocol-neutral.
  12
  13   o Revise how we do bandwidth limiting and round-robining between
  14     circuits on a connection.
  15
  16   . Revise how we do bandwidth limiting and round-robining between
  17     connections.
  18
  19   - Better flow-control to avoid filling buffers on routers.
  20
  21   - Figure out good ways to instrument Tor internals so we can tell
  22     how well our bandwidth and flow-control stuff is actually working.
  23     - What ports eat the bandwidth?
  24     - How full do queues get?
  25     - How much latency do queues get?
  26
  27   - Rate limit at clients:
  28     - Give clients an upper bound on how much they're willing to use
  29       the network if they're not relaying?
  30     - ... or group client circuits by IP at the server and rate-limit
  31       like that.
  32
  33   - Use if-modified-since to download consensuses
  34
  35
  36 - Other features
  37   - Proposals to implement:
  38     - 146: reflect long-term stability in consensuses
  39     - 147: Stop using v2 directories to generate v3 votes.
  40       - Start pinging as soon as we learn about a relay, not on a
  41         22-minute cycle.  Prioritize new and volatile relays for
  42         testing.
  43
  44   - Proposals to improve and implement
  45     - 158: microdescriptors
  46       o Revise proposal
  47       - Implement
  48
  49   - Proposals to improve and implement if not broken
  50     D IPv6 support.  (Parts of 117, but figure out how to handle DNS
  51       requests.)
  52     - 140: Directory diffs
  53       - Need a decent simple C diff implementation.
  54       - Need a decent simple C ed patch implementation.
  55     - 149: learn info from netinfo cells.
  56       o Start discussion
  57       - Revise proposal based on discussion.
  58     X 134: handle authority fragmentation (Needs more analysis)
  59     - 165: Easy migration for voting authority sets
  60     - 163: Detect client-status better
  61       o Write proposal
  62       - Possibly implement, depending on discussion.
  63     - 164: Have authorities report relay and voting status better: make it
  64       easy to answer, "Why is my server not listed/not Guard/not
  65       Running/etc"
  66       o Write proposal
  67       - Possibly implement, depending on discussion
  68     - 162: Have consensuses come in multiple "flavours".
  69       o Write proposal
  70       - Possibly implement, depending on discussion.
  71
  72   - Needs a proposal, or at least some design
  73     - Weaken the requirements for being a Guard, based on K's
  74       measurements.
  75 K     - Finish measurements
  76 K?    - Write proposal
  77     - Adaptive timeouts for giving up on circuits and streams.
  78 M     - Revise proposal 151
  79     - Downweight guards more sensibly: be more forgiving about using
  80       Guard nodes as non-first-hop.
  81       - Write proposal.
  82     - Lagged weight updates in consensuses: don't just move abruptly.
  83 M?    - Write proposal
  84     d Don't kill a circuit on the first failed extend.
  85
  86 - Installers
  87   - Switch to MSI on win32
  88   - Use Thandy, perhaps?
  89
  90 o Deprecations
  91   o Make .exit safe, or make it off-by-default.
  92