Terminology:
- connections
- circuits
- streams
- cells

Performance topics:

Scheduling:
- circuit-level scheduling
  - EWMA to decide what circuit on that connection to pick next
* - picking the optimal circuit globally
    - shorter kernel outbufs
- connection-level scheduling
  - prefer reading/writing to larger relays?
  - prefer reading from relays that recently gave us high-priority cells
* - torchestra
  - Tradeoffs of sending fewer/more cells?
    - consider overhead from tls records, ip/tcp headers
    - falling back into slow start?
    - consider overhead from resent packets / tcp control packets
- refill token buckets more often

Congestion control / alternate transport:
- Change transport to do end-to-end retransmission?
- Or alternate e2e transport that e.g. backs off by latency
[- link to Steven Murdoch's tech report]
- Change link transport to avoid head-of-line blocking
- Bryan Ford's "unordered TLS / TCP" patches
- circuit window defaults wrong?
- N23 for link-by-link flow control
  - Still needs end-to-end flow control for streams
- Is our current approach especially bad for slow/flaky first hops?

Alternate routing
- circuit-build-timeout drops 20% worst circuits
- congestion-aware routing tests circuit during use
  - what are the anonymity attacks?
* conflux builds two paths for one circuit and then load balances

Load balancing:
- Relays self-measure capacity
- "bandwidth authorities" actively measure and adjust weights
- Adjust weights by position in path based on proportion of capacity
- Need to recognize other issues like CPU load / socket limit
  - Relays should self-report exhaustion or near-exhaustion, perhaps in
    a quicker way than putting it in descriptors?
- Give the Guard flag to more relays?
- Bridges aren't load balanced

Throttling:
* static throttling
  - plus maybe detect and target bulk transfers?
- adaptive throttling

Make the network better:
- More bandwidth leads to better performance (with what relationship?)
- Better crypto algorithms / implementations
- Raise min bandwidth for Fast flag
- Auto-promote clients to be relays
  - Work better as a relay on Windows
  - Better NAT piercing / allow exits behind firewalls
- Incentives to be a relay

Round-trip / application-level improvements:
- Optimistic data in begin cells
* spdy / caching at exits
- adblock to not fetch so much
- better stream timeouts?




Extra questions:

- Erik trying to make deterlab tor experiment match shadow / experimentor
  results
- What is the prevalance of head-of-line blocking for Tor relays?
- Ethics / legal issues with Steve's pcaps?
- How many cells go into a TLS record in practice?
- How close to out of file descriptors are the fast relays?
- Is Tor's circuit-build-timeout just guaranteeing we'll ignore tiny
  relays because they won't have a TLS connection open already?
- How do the TCP flows combine ("smooth")?
- Research question: give an offset to each relay per second so the
  100ms phases don't synchronize. Improvement?

Chris et al are working on tracking how long a cell takes, from beginning
to end, including both the in-Tor part and also the in-kernel part.

Rob has a branch for relays in Shadow, to collect more stats about how
the relay thinks it's operating.

Steve is going to compute some TCP statistics for the traffic flows he's
recorded, and plan to redo his experiments, this time stopping after
7 days so he hasn't gotten the Guard flag yet. (He'll also leave his
DirPort off.)