Will aim to cover anything that slows Tor down
https://arthuredelstein.net/exits
https://metrics.torproject.org/torperf.html data of individual relays -- collector
https://collector.torproject.org/archive/torperf/ 3 file sizes: fresh download each time plan: download a single file
https://metrics.torproject.org/onionperf-buildtimes.html
Putting metrics into relay code:privcount Buffer DNS failures Could add things to extrainfo
Tor over QUIC as a use case DTLS? Does metadata get leaked? QUIC has pluggable congestion control mechanisms https://www.benthamsgaze.org/2016/09/29/quux-a-quic-un-multiplexing-of-the-tor-relay-transport/ (This architecture considers QUIC hop-to-hop, not end-to-end for Tor)
IPv6 work in Tor
Enabling ECN on relay hosts may reduce head of line blocking on inter-relay connections
Slow relays make the network slower. On slow relays you see large queues.
Early privcount statistic
Changing topology: 100x factor: not every relay can talk to every other relay. Restricted topologies.
Shadow can simulate packet loss and jitter, but only TCP connections.
Experimenting with different protocol stacks is getting easier.
Alternative link protocols would be comparitively easy to switch out.
Sidechannel issues.
Can point-to-point links improve performance? Maybe DTLS?
Different route selection protocols. More direct route crosses fewer jurisdictions. If path selection depends on destination, then it helps adversary reduce number of destinations.
With privcount we might be able to get statistics over every 4 hours.