[quicwg/base-drafts] Eliminating the fixed minimum RTO (#1017)

[janaiyengar <[e-mail]>]

TL;DR: QUIC currently uses a minimum RTO of 200ms. Given that (i) the cost of a spurious RTO is substantially reduced in QUIC, (ii) we have the ability to track the receiver's delayed ack timeout as discussed in #981, and (iii) QUIC is strongly leaning towards being latency-sensitive, we should consider eliminating the fixed minimum RTO for QUIC in its RTO computations. Argument follows.

[RFC 6298](https://tools.ietf.org/html/rfc6298) for TCP conservatively uses a 1 second minimum RTO, and the QUIC recovery draft uses 200 ms since that's what Linux TCP does. A fixed minimum RTO is used in TCP (and by inheritance, in QUIC) to protect a sender from the cost of spurious RTOs. See [RFC 6298, rule 2.4 in section 2](https://tools.ietf.org/html/rfc6298#section-2): "Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]".

Spurious RTOs can occur due to several reasons, for instance (i) delayed ack timeout at the receiver is not always sampled in the RTT measurements, so minRTO provides protection at the sender, or (ii) the RTO computation uses EWMAs, which always lag, causing spurious RTOs when the underlying network RTT increases. 

AIUI, the primary reason to avoid spurious RTOs in RFC 6298 is the cost of an RTO firing, which hurts sender performance  by reducing the congestion window to 1 MSS. (There are secondary costs of additional load on the network, but that's not debilitating, since TLP demonstrates that this load is manageable.) 

QUIC's loss recovery does not suffer this problem because the sender handles spurious RTO detection as part of its loss recovery logic. Specifically, QUIC does not reduce the congestion window to 1 on an RTO, but reduces it if the RTO is verified to be real, when an ACK is received for the retransmission but not the transmission. Alternatively, if an ACK for an earlier packet is received after an RTO fires, the RTO is considered spurious and does not cause the sender to reduce its congestion window. See [Section 3.3.2 of the draft-ietf-quic-recovery]((https://quicwg.github.io/base-drafts/draft-ietf-quic-recovery.html#rfc.section.3.3.2)).

A minimum RTO potentially imposes a fixed latency cost on loss recovery and on detecting path failures. Additionally, a minimum RTO imposes a fixed wait time independent of the underlying network, which causes performance issues on networks with smaller RTTs (see the [MAD proposal for TCP](https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt))

Given that (i) the cost of a spurious RTO is substantially reduced in QUIC, (ii) we have the ability to track the receiver's delayed ack timeout as discussed in #981, and (iii) QUIC is strongly leaning towards being latency-sensitive, I propose that we consider removing the fixed minimum RTO for QUIC in its RTO computations.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1017