<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Sections 3 and 6 of the Quux paper have some relevant discussion [1]<br></div><div><br></div><div>> Unfortunately, it appears that the Quux QUIC paper studied QUIC at the<br></div><div>> wrong position - between relays, and the QuTor implementation is<br></div><div>> unclear. This means that it may still be an open question as to if<br></div><div>> QUIC's congestion control algorithms will behave optimally in a<br></div><div>> Tor-like network under heavy load.<br></div><div><br></div><div>  As Reardon and Goldberg noted in concluding remarks, approaches other<br></div><div>  than hop-by-hop will incur an extra cost for retransmissions, since<br></div><div>  these must be rerouted through a larger part of the network [RG09].<br></div><div> <br></div><div>  As Tschorsch and Scheuermann discuss [TS12], due to the longer RTT of<br></div><div>  TCP connections, end-to-end approaches will also take longer to “ramp<br></div><div>  up” through slow start and up to a steady state.<br></div><div> <br></div><div>  Both of these factors (not to mention increased security risk of<br></div><div>  information leakage [DM09]) suggest that hop-by-hop designs are likely<br></div><div>  to yield beer results. In fact, the hop-by-hop approach may be viewed as<br></div><div>  an instance of the Split TCP Performance-Enhancing Proxy design, whereby<br></div><div>  arbitrary TCP connections are split in two to negate the issues noted<br></div><div>  above.<br></div><div><br></div><div>> Unfortunately, the Quux implementation appears to use QUIC at a<br></div><div>> suboptimal position -- they replace Tor's TLS connections with QUIC,<br></div><div>> and use QUIC streams in place of Tor's circuit ID -- but only between<br></div><div>> relays. This means that it does not benefit from QUIC's end-to-end<br></div><div>> congestion control for the entire path of the circuit. Such a design<br></div><div>> will not solve the queuing and associated OOM problems at Tor relays,<br></div><div>> since relays would be unable to drop cells to signal backpressure to<br></div><div>> endpoints. Drops will instead block every circuit on a connection<br></div><div>> between relays, and even then, due to end-to-end reliability, relays<br></div><div>> will still need to queue without bound, subject to Tor's current (and<br></div><div>> inadequate) flow control.<br></div><div><br></div><div>  A fully QUIC relay path (with slight modication to fix a limit on<br></div><div>  internal buffer sizes) would allow end-to-end backpressure to be used<br></div><div>  from the client application TCP stream up to the exit TCP stream.<br></div><div>  Leaving aside Tor’s inbound rate limit mechanism but retaining the<br></div><div>  global outbound limit, this design would allow max-min fairness to be<br></div><div>  achieved in the network, as outlined by Tschorsch and Scheuermann<br></div><div>  [TS11].<br></div><div><br></div><div>  ...<br></div><div><br></div><div>  Once implemented however, backpressure would allow Tor to adopt a<br></div><div>  signicantly improved internal design. In such a design, a Tor relay<br></div><div>  could read a single cell from one QUIC stream’s read buffer, onion crypt<br></div><div>  it, and immediately place it onto the write buffer of the next stream in<br></div><div>  the circuit. This process would be able to operate at the granularity of<br></div><div>  a single cell because the read and write operations for QUIC are very<br></div><div>  cheap user-space function calls and not syscalls as for host TCP.<br></div><div><br></div><div>  The schedule of this action would be governed by the existing EWMA<br></div><div>  scheduler for circuits that have both a readable stream and a writeable<br></div><div>  stream (and as allowed by a global outgoing token bucket), allowing<br></div><div>  optimal quality of service for circuits.<br></div><div><br></div><div>  It’s expected that backpressure implemented in this way will yield<br></div><div>  signicant performance and fairness gains on top of the performance<br></div><div>  improvement found in this thesis.<br></div><div><br></div><div>One issue for Quux was that it used the Chromium demo QUIC server code as the<br></div><div>basis for its implementation, which was fine for performance research but not<br></div><div>such a good choice for Tor's networking stack.<br></div><div><br></div><div>Several Rust implementations have been released with server-side (not just<br></div><div>client-side) usage, so I expect that to be much less of an issue today.<br></div><div><br></div><div>io_uring is also a significant development since Quux was developed, as<br></div><div>it can reduce the performance hit for host-TCP syscalls, or for using<br></div><div>recvmsg instead of recvmmsg with QUIC if the implementation makes<br></div><div>it difficult to use recvmmsg on the listener side.<br></div><div><br></div><div>[1] <a href="https://www.benthamsgaze.org/wp-content/uploads/2016/09/393617_Alastair_Clark_aclark_2360661_860598830.pdf">https://www.benthamsgaze.org/wp-content/uploads/2016/09/393617_Alastair_Clark_aclark_2360661_860598830.pdf</a><br></div><div><br></div><div>The following paper has in-depth discussion, but I don't have a copy to<br></div><div>hand unfortunately:<br></div><div><br></div><div>Ali Clark. Tor network performance — transport and flow control.  Technical report, University College London, April 2016<br></div><div><br></div></body></html>