The Quantum Bug
University of Oslo
PO Box 1080 Blindern
N-0316
Oslo
Norway
+47 22 85 24 20
michawe@ifi.uio.no
Independent Submission
Teleportation
Entanglement
0-RTT
The age of quantum networking is upon us, and with it comes
"entanglement": a procedure in which a state (i.e., a bit) can be
transferred instantly, with no measurable delay between peers. This will
lead to a perceived round-trip time of zero seconds
on some Internet paths, a capability which was not predicted and so not
included as a possibility in many protocol specifications.
Worse than the millennium bug, this unexpected value is bound to cause
serious Internet failures unless the specifications are fixed in time.
Introduction
discusses faster-than-light
communication, where packets arrive before they are sent.
While it is amusing to entertain the possibility of time travel, we have
to accept the cold facts: time travel will never work (or it would
already have been used). Quantum networking,
however, is an entirely different matter -- commercial products are
already available, and quantum networks will without a doubt become the
prevalent Internet link-layer technology across the globe within the
next five to ten years.
With the help of entanglement, implemented in quantum repeaters,
quantum networks can transfer information faster than ever before: a
state can be transmitted over a long distance instantly, with no delay.
This is so cool that it is also called (and, by some, mistaken
for) teleportation. If a path between a sender and a receiver is fully
quantum-ized, the measured one-way delay (OWD) will be zero. What's
more, assuming that there are blazing fast quantum computers involved on
both ends, the processing time will be well below anything measurable;
hence, even the round-trip time (RTT) will be zero in these
scenarios.
In today's Internet, only very few protocols are prepared for such
"0-RTT" situations (e.g., TCP with "TCP Fast Open" (TFO) , TLS 1.3 , and QUIC ). Many others will fail in interesting ways; we coin
the term "Quantum Bug" for such failures. In the following section, we
will discuss some examples of Quantum Bugs.
Protocols and Protocol Mechanisms That Will Fail
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.
LEDBAT
The Low Extra Delay Background Transfer (LEDBAT) congestion control
mechanism 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 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.
Multipath TCP (MPTCP)
The coupled congestion control mechanism proposed for MPTCP in
requires calculating a value
called "alpha". Equation 2 in
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.
RTP Circuit Breakers
The RTP Circuit Breakers
require calculation of a well-known equation which yields the
throughput of a TCP connection:
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 , 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:
Unfortunately, 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.
What can be done?
Fear not: when everything else fails, TCP will still work.
Its retransmission timeout is lower-bounded by 1 second . Moreover, while its cwnd may grow up to the maximum storable number, data
transmission is limited by the Receiver Window (rwnd). This means that
flow control will save TCP from failing.
From this, we can learn two simple rules: lower-bound any values
calculated from the RTT (and, obviously, do not divide by the RTT), and
use flow control. Specifications will need to be updated by fixing all
RTT-based calculations and introducing flow control everywhere. For example,
UDP will have to be extended with a receiver window, e.g., as a UDP
option .
Conclusion
We are in trouble, and there is only one way out: develop a
comprehensive list of all RFCs containing "0-RTT" mistakes (taking as a guideline), and update all
code. This needs to happen fast, the clock is ticking. Luckily, if we
are too slow, we will still be able to use TCP to access the
specifications. With DNS over TCP , name resolution to find the server containing the
specifications should also work.
IANA Considerations
This document has no IANA actions.
Security Considerations
Flow control must be used on 0-RTT paths, or else an
attacker can completely overwhelm a sender with data
in a denial-of-service (DoS) attack within an instant.
Flow control will need to be added to protocols that do
not currently have it, such as UDP or ICMP.
IPv6 will not save us.
References
Normative References
Informative References