|
|
- QUIC basically acts as a replacement for the circuit and
|
|
|
stream layers
|
|
|
- Stack:
|
|
|
```
|
|
|
STREAM
|
|
|
QUIC
|
|
|
ONION
|
|
|
DTLS (or something else?)
|
|
|
```
|
|
|
- QUIC connection between client and exit
|
|
|
- Hop-by-hop QUIC doesn't help congestion control to limit queue
|
|
|
size
|
|
|
- Still needs link crypto (DTLS?), to conceal individual circuits
|
|
|
- Still needs per-hop onion crypto (DTLS?)
|
|
|
- Easier to send onionskin extends over normal TLS because
|
|
|
then we don't need a reliability mechanism for them
|
|
|
- QUIC connection id is sent in the clear
|
|
|
- Packet number sent in the clear, but this may be encrypted in
|
|
|
future revs
|
|
|
- Tor's current circuit layer needs more than just circuit ids in
|
|
|
the clear
|
|
|
- Fixed length global queue, per relay, for all circuits through that really
|
|
|
- EWMA or other fairness algorithms done by peaking into the queue
|
|
|
- Fixed length queue bounds latency and eliminates out-of-memory
|
|
|
conditions from queuing
|
|
|
- "On the internet, core is fast and edge is slow; Tor is different"
|
|
|
- QUIC congestion control is drop-based; find shared bottleneck
|
|
|
- LEDBAT/utp/latency congestion mechanisms fail because they
|
|
|
expect the congestion to be at the edges
|
|
|
- QUIC's packet size != frame size, worth paying attention to wrt to
|
|
|
constant sized cells
|
|
|
- Implementations ([list](https://github.com/quicwg/base-drafts/wiki/Implementations))
|
|
|
- mozquic, ngtcp2, facebook
|
|
|
- UDP stacks may not be performant on all operating systems
|
|
|
- Adoption rates/Google experiments?
|
|
|
- Trend line is down. Under 5%.
|
|
|
- BOFHs blocking UDP
|
|
|
- Exit queues? No. Exits can do back pressure by reading
|
|
|
- Censorship? Already bad
|
|
|
- We can do incremental upgrades
|
|
|
- Experiments/requirements up front for deployment plz
|
|
|
- Test performance of bottleneck at different hop positions
|
|
|
- Mobile clients?
|
|
|
- Deployment path: Flag day, incremental upgrades
|
|
|
- Do we want DTLS or some other link crypto?
|
|
|
- Google Quic supports unreliable streams; IETF does not
|
|
|
- Tor's congestion control requires killing circuits
|
|
|
- Anonymity/attacks
|
|
|
- Middle nodes can drop packets and see how long it takes
|
|
|
to retransmit
|
|
|
- but the sendme timing can infer this
|
|
|
- Can add a 4th hop so you don't know what middle you are
|
|
|
- Lower variance overall will make distance to client more
|
|
|
measurable
|
|
|
- Can always add latency...
|
|
|
- However, all distributions of added latency have a minimum
|
|
|
- But Tor latency will also have a minimum
|
|
|
- QUIC is resilient to reset attacks |