[tor-dev] The case for Tor-over-QUIC

[Mike Perry]

Mike Perry:
> In Rome, I held a session about network protocol upgrades. My intent was
> to cover the switch to two guards, conflux, datagram transports, and
> QUIC. We ended up touching only briefly on everything but QUIC, but we
> went into enough depth on QUIC itself that it was a worthwhile and very
> productive session.
> 
> Our notes are here:
> https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/FutureTorNetworkProtocolUpgrades
> 

> # QUIC Research Questions
> 
> A couple areas of open research into how QUIC will behave in a Tor
> deployment remain. It is my belief that while these areas are worth
> further study, they do not represent blockers to QUIC, as a naive
> deployment of QUIC will substantially outperform our current (lack of)
> congestion and poor flow control.
> 
> ## End-to-end Congestion Control Study
> 
> Unfortunately, it appears that the Quux QUIC paper studied QUIC at the
> wrong position - between relays, and the QuTor implementation is
> unclear. This means that it may still be an open question as to if
> QUIC's congestion control algorithms will behave optimally in a Tor-like
> network under heavy load.
> 
> However, Google has conducted extensive internet-scale research into the
> congestion control algorithm, which very likely covers enough networks
> with Tor-like latency and drop characteristics. Because of this, I do
> not expect us to have to do a lot of tuning of their congestion control
> here, but it is worth investigating.
> 
> ## Queue Management
> 
> Fairness among flows in drop-based congestion control is heavily
> influenced by how the queue is managed, and particularly by the decision
> of which packet to drop when the queue is full. Modern favored
> algorithms involve probabilistic early dropping from the middle of the
> queue. The most popular approaches are the adaptive variants of RED and
> Blue:
> https://en.wikipedia.org/wiki/Random_early_detection
> https://en.wikipedia.org/wiki/Blue_(queue_management_algorithm)

An IETFer mailed me and pointed out that the IETF now recommends
PIE or FQ-CoDel over RED/BLUE, since they explicitly control
queue latency:
https://tools.ietf.org/html/rfc8033
https://tools.ietf.org/html/rfc8290

FQ-CoDel is appealing for us because it breaks the queue into separate
per-flow queues, and has mechanisms to favor quieter flows over busy
ones when deciding which packets to send first, and which to drop. It
sounds quite promising for getting similar properties out of a QUIC-Tor
as we have with Circuit EWMA scheduling.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180402/a831711b/attachment.sig>