tor/doc/TODO.022

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.