The Quantum BugUniversity of OsloPO Box 1080 BlindernN-0316OsloNorway+47 22 85 24 20michawe@ifi.uio.noIndependent SubmissionTeleportationEntanglement0-RTTThe 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.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Protocols and Protocol Mechanisms That Will Fail
. LEDBAT
. Multipath TCP (MPTCP)
. RTP Circuit Breakers
. What can be done?
. Conclusion
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Author's Address
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 FailThe 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.
LEDBATThe 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 BreakersThe RTP Circuit Breakers
require calculation of a well-known equation which yields the
throughput of a TCP connection:
s
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 , 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:
s
X = ----------------
Tr*sqrt(2*b*p/3)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 .ConclusionWe 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 ConsiderationsThis document has no IANA actions.Security ConsiderationsFlow 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.ReferencesNormative ReferencesThe Internet and the Millennium Problem (Year 2000)The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.Design Considerations for Faster-Than-Light (FTL) CommunicationWe are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.Informative ReferencesQUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <https://mailarchive.ietf.org/arch/search/?email_list=quic>. Working Group information can be found at <https://github.com/ quicwg>; source code and issues list for this draft can be found at <https://github.com/quicwg/base-drafts/labels/-transport>.Work in ProgressComputing TCP's Retransmission TimerThis document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]Coupled Congestion Control for Multipath Transport ProtocolsOften endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.Low Extra Delay Background Transport (LEDBAT)Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.TCP Fast OpenThis document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.DNS Transport over TCP - Implementation RequirementsThis document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.Multimedia Congestion Control: Circuit Breakers for Unicast RTP SessionsThe Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Transport Options for UDPTransport protocols are extended through the use of transport header options. This document extends UDP by indicating the location, syntax, and semantics for UDP transport layer options.Work in ProgressAuthor's AddressUniversity of OsloPO Box 1080 BlindernN-0316OsloNorway+47 22 85 24 20michawe@ifi.uio.no