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.

- Design only
  - Begin design work for UDP transition; identify areas where we need to
    make changes or instrument stuff early.

    [multiple weeks, ongoing.  Need to do a draft 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 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
N     - Revise proposal
    - 160: list bandwidth in consensus
RNM?  - Finish proposal
      - 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
N     - Write proposal
    - Have authorities report relay and voting status better: make it
      easy to answer, "Why is my server not listed/not Guard/not
      Running/etc"
N     - Write proposal
    - Have consensuses come in multiple "flavours".
N     - Write proposal
    - 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/N   - 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?

- Deprecations
  - Make .exit safe, or make it off-by-default.