wiki:org/meetings/2018MexicoCity/Notes/TorPerformance

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.

Last modified 2 months ago Last modified on Oct 7, 2018, 4:16:54 AM