The number of protocols and protocol mechanisms that will fail in the face of a zero RTT is too large to report here; we are truly heading towards something close to an Internet meltdown. We can only provide some guidance to those who hunt for the Quantum Bug, by discussing examples of specification mistakes that will need to be fixed.
The Low Extra Delay Background Transfer (LEDBAT) congestion control mechanism [RFC 6817
] is a very interesting failure case: designed to "get out of the way" of other traffic; it will end up sending as fast as possible. Specifically, when the algorithm described in Section 2.4.2
of RFC 6817
obtains a delay sample, it updates a list of base delays that will all become 0 and current delays that will also all become 0. It calculates a queuing delay as the difference between the current delay and the base delay (resulting in 0) and keeps increasing the Congestion Window (cwnd) until the queuing delay reaches a predefined parameter value TARGET (100 milliseconds or less).
A TARGET value of 100 milliseconds will never be reached, because the queuing delay does not grow when the sender increases its cwnd; this means that LEDBAT would endlessly increase its cwnd, limited only by the number of bits that are used to represent cwnd. However, given that TARGET=0 is also allowed, this parameter choice may seem to be a way out. Always staying at the target means that the sender would maintain its initial cwnd, which should be set to 2. This may seem like a small number, but remember that cwnd is the number of bytes that can be transmitted per RTT (which is 0). Thus, irrespective of the TARGET value, the sender will send data as fast as it can.
The coupled congestion control mechanism proposed for MPTCP in [RFC 6356
] requires calculating a value called "alpha". Equation 2 in [RFC 6356
] contains a term where a value called "cwnd_i" is divided by the square of the RTT, and another term where this value is divided by the RTT. Enough said.
The RTP Circuit Breakers [RFC 8083
] require calculation of a well-known equation which yields the throughput of a TCP connection:
X = -------------------------------------------------------------
Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p)))
where Tr is the RTT and t_RTO is the retransmission timeout of TCP (we don't need to care about the other variables). As we will discuss in Section 3
, t_RTO is lower-bounded with 1 second; therefore, it saves us from a division by zero. However, there is also a simplified version of this equation:
X = ----------------
Unfortunately, [RFC 8083
] states: "It is RECOMMENDED that this simplified throughput equation be used since the reduction in accuracy is small, and it is much simpler to calculate than the full equation." Due to this simplification, many multimedia applications will crash.