draft-ietf-quic-applicability-11.txt   draft-ietf-quic-applicability-12.txt 
Network Working Group M. Kuehlewind Network Working Group M. Kuehlewind
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational B. Trammell Intended status: Informational B. Trammell
Expires: 23 October 2021 Google Expires: 1 January 2022 Google
21 April 2021 30 June 2021
Applicability of the QUIC Transport Protocol Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-11 draft-ietf-quic-applicability-12
Abstract Abstract
This document discusses the applicability of the QUIC transport This document discusses the applicability of the QUIC transport
protocol, focusing on caveats impacting application protocol protocol, focusing on caveats impacting application protocol
development and deployment over QUIC. Its intended audience is development and deployment over QUIC. Its intended audience is
designers of application protocol mappings to QUIC, and implementors designers of application protocol mappings to QUIC, and implementors
of these application protocols. of these application protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 October 2021. This Internet-Draft will expire on 1 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 4 3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 4
3.2. Session resumption versus Keep-alive . . . . . . . . . . 5 3.2. Session resumption versus Keep-alive . . . . . . . . . . 5
4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8
4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 9 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 9
4.3. Ordered and Reliable Delivery . . . . . . . . . . . . . . 9 4.3. Ordered and Reliable Delivery . . . . . . . . . . . . . . 9
4.4. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 10 4.4. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 10
4.5. Stream Limit Commitments . . . . . . . . . . . . . . . . 11 4.5. Stream Limit Commitments . . . . . . . . . . . . . . . . 11
5. Packetization and Latency . . . . . . . . . . . . . . . . . . 12 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 12
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13
7. ACK-only packets on constrained links . . . . . . . . . . . . 14 7. Acknowledgment Efficiency . . . . . . . . . . . . . . . . . . 14
8. Port Selection and Application Endpoint Discovery . . . . . . 14 8. Port Selection and Application Endpoint Discovery . . . . . . 14
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 15 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 15
10. Connection Termination . . . . . . . . . . . . . . . . . . . 16 10. Connection Termination . . . . . . . . . . . . . . . . . . . 16
11. Information Exposure and the Connection ID . . . . . . . . . 16 11. Information Exposure and the Connection ID . . . . . . . . . 17
11.1. Server-Generated Connection ID . . . . . . . . . . . . . 17 11.1. Server-Generated Connection ID . . . . . . . . . . . . . 17
11.2. Mitigating Timing Linkability with Connection ID 11.2. Mitigating Timing Linkability with Connection ID
Migration . . . . . . . . . . . . . . . . . . . . . . . 17 Migration . . . . . . . . . . . . . . . . . . . . . . . 18
11.3. Using Server Retry for Redirection . . . . . . . . . . . 18 11.3. Using Server Retry for Redirection . . . . . . . . . . . 18
12. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 18 12. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 19
13. Use of Versions and Cryptographic Handshake . . . . . . . . . 19 13. Use of Versions and Cryptographic Handshake . . . . . . . . . 19
14. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 19 14. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 20
15. Unreliable Datagram Service over QUIC . . . . . . . . . . . . 20 15. Unreliable Datagram Service over QUIC . . . . . . . . . . . . 21
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
17. Security Considerations . . . . . . . . . . . . . . . . . . . 21 17. Security Considerations . . . . . . . . . . . . . . . . . . . 21
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
20.1. Normative References . . . . . . . . . . . . . . . . . . 21 20.1. Normative References . . . . . . . . . . . . . . . . . . 22
20.2. Informative References . . . . . . . . . . . . . . . . . 22 20.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
QUIC [QUIC] is a new transport protocol providing a number of QUIC [QUIC] is a new transport protocol providing a number of
advanced features. While initially designed for the HTTP use case, advanced features. While initially designed for the HTTP use case,
it provides capabilities that can be used with a much wider variety it provides capabilities that can be used with a much wider variety
of applications. QUIC is encapsulated in UDP. QUIC version 1 of applications. QUIC is encapsulated in UDP. QUIC version 1
integrates TLS 1.3 [TLS13] to encrypt all payload data and most integrates TLS 1.3 [TLS13] to encrypt all payload data and most
control information. The version of HTTP that uses QUIC is known as control information. The version of HTTP that uses QUIC is known as
HTTP/3 [QUIC-HTTP]. HTTP/3 [QUIC-HTTP].
skipping to change at page 3, line 37 skipping to change at page 3, line 37
this fallback is TLS over TCP. this fallback is TLS over TCP.
The IETF TAPS specifications [I-D.ietf-taps-arch] describe a system The IETF TAPS specifications [I-D.ietf-taps-arch] describe a system
with a common API for multiple protocols and some of the implications with a common API for multiple protocols and some of the implications
of fallback between these different protocols, specifically of fallback between these different protocols, specifically
precluding fallback to insecure protocols or to weaker versions of precluding fallback to insecure protocols or to weaker versions of
secure protocols. secure protocols.
An application that implements fallback needs to consider the An application that implements fallback needs to consider the
security consequences. A fallback to TCP and TLS exposes control security consequences. A fallback to TCP and TLS exposes control
information to modification and manipulation in the network. Further information to modification and manipulation in the network.
downgrades to older TLS versions than used in QUIC, which is 1.3, Further, downgrades to older TLS versions than 1.3, which is used in
might result in significantly weaker cryptographic protection. For QUIC version 1, might result in significantly weaker cryptographic
example, the results of protocol negotiation [RFC7301] only have protection. For example, the results of protocol negotiation
confidentiality protection if TLS 1.3 is used. [RFC7301] only have confidentiality protection if TLS 1.3 is used.
These applications must operate, perhaps with impaired functionality, These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the in the absence of features provided by QUIC not present in the
fallback protocol. For fallback to TLS over TCP, the most obvious fallback protocol. For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the therefore stream multiplexing would need to be implemented in the
application layer if needed. Further, TCP implementations and application layer if needed. Further, TCP implementations and
network paths often do not support the Fast Open option [RFC7413], network paths often do not support the Fast Open option [RFC7413],
which enables sending of payload data together with the first control which enables sending of payload data together with the first control
packet of a new connection as also provided by 0-RTT session packet of a new connection as also provided by 0-RTT session
skipping to change at page 5, line 29 skipping to change at page 5, line 29
partial or even complete replay protection, which could be used to partial or even complete replay protection, which could be used to
manage replay risk. manage replay risk.
3.2. Session resumption versus Keep-alive 3.2. Session resumption versus Keep-alive
Because QUIC is encapsulated in UDP, applications using QUIC must Because QUIC is encapsulated in UDP, applications using QUIC must
deal with short network idle timeouts. Deployed stateful middleboxes deal with short network idle timeouts. Deployed stateful middleboxes
will generally establish state for UDP flows on the first packet will generally establish state for UDP flows on the first packet
sent, and keep state for much shorter idle periods than for TCP. sent, and keep state for much shorter idle periods than for TCP.
[RFC5382] suggests a TCP idle period of at least 124 minutes, though [RFC5382] suggests a TCP idle period of at least 124 minutes, though
there is not evidence of widespread implementation of this guideline there is no evidence of widespread implementation of this guideline
in the literature. Short network timeout for UDP, however, is well- in the literature. Short network timeout for UDP, however, is well-
documented. According to a 2010 study ([Hatonen10]), UDP documented. According to a 2010 study ([Hatonen10]), UDP
applications can assume that any NAT binding or other state entry can applications can assume that any NAT binding or other state entry can
expire after just thirty seconds of inactivity. Section 3.5 of expire after just thirty seconds of inactivity. Section 3.5 of
[RFC8085] further discusses keep-alive intervals for UDP: it requires [RFC8085] further discusses keep-alive intervals for UDP: it requires
a minimum value of 15 seconds, but recommends larger values, or a minimum value of 15 seconds, but recommends larger values, or
omitting keep-alive entirely. omitting keep-alive entirely.
By using a connection ID, QUIC is designed to be robust to NAT By using a connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout. However, this only helps if one address rebinding after a timeout. However, this only helps if one
skipping to change at page 6, line 46 skipping to change at page 6, line 46
Sending PING frames more frequently than every 30 seconds over long Sending PING frames more frequently than every 30 seconds over long
idle periods may result in excessive unproductive traffic in some idle periods may result in excessive unproductive traffic in some
situations, and to unacceptable power usage for power-constrained situations, and to unacceptable power usage for power-constrained
(mobile) devices. Additionally, timeouts shorter than 30 seconds can (mobile) devices. Additionally, timeouts shorter than 30 seconds can
make it harder to handle transient network interruptions, such as VM make it harder to handle transient network interruptions, such as VM
migration or coverage loss during mobilty. See [RFC8085], especially migration or coverage loss during mobilty. See [RFC8085], especially
Section 3.5. Section 3.5.
Alternatively, the client (but not the server) can use session Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic. In this case, a resumption instead of sending keepalive traffic. In this case, a
client that wants to send data to a server over a connection idle client that wants to send data to a server over a connection that has
longer than the server's idle timeout (available from the been idle longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect. When idle_timeout transport parameter) can simply reconnect. When
possible, this reconnection can use 0-RTT session resumption, possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection. Of reducing the latency involved with restarting the connection. Of
course, this approach is only valid in cases in which 0-RTT data is course, this approach is only valid in cases in which it is safe to
safe, when the client is the restarting peer, and when the data to be use 0-RTT and when the client is the restarting peer. It is also not
sent is idempotent. It is also not applicable when the application applicable when the application binds external state to the
binds external state to the connection, as this state cannot reliably connection, as this state cannot reliably be transferred to a resumed
be transferred to a resumed connection. connection.
The tradeoffs between resumption and keep-alives need to be evaluated The tradeoffs between resumption and keep-alives need to be evaluated
on a per-application basis. In general, applications should use on a per-application basis. In general, applications should use
keep-alives only in circumstances where continued communication is keep-alives only in circumstances where continued communication is
highly likely; [QUIC-HTTP], for instance, recommends using keep- highly likely; [QUIC-HTTP], for instance, recommends using keep-
alives only when a request is outstanding. alives only when a request is outstanding.
4. Use of Streams 4. Use of Streams
QUIC's stream multiplexing feature allows applications to run QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection, without head-of-line multiple streams over a single connection, without head-of-line
blocking between streams, associated at a point in time with a single blocking between streams. Stream data is carried within frames,
five-tuple. Stream data is carried within frames, where one QUIC where one QUIC packet on the wire can carry one or multiple stream
packet on the wire can carry one or multiple stream frames. frames.
Streams can be unidirectional or bidirectional, and a stream may be Streams can be unidirectional or bidirectional, and a stream may be
initiated either by client or server. Only the initiator of a initiated either by client or server. Only the initiator of a
unidirectional stream can send data on it. unidirectional stream can send data on it.
Streams and connections can each carry a maximum of 2^62-1 bytes in Streams and connections can each carry a maximum of 2^62-1 bytes in
each direction, due to encoding limitations on stream offsets and each direction, due to encoding limitations on stream offsets and
connection flow control limits. In the presently unlikely event that connection flow control limits. In the presently unlikely event that
this limit is reached by an application, a new connection would need this limit is reached by an application, a new connection would need
to be established. to be established.
skipping to change at page 8, line 27 skipping to change at page 8, line 27
the stream to expire an unacknowledged message can be used to the stream to expire an unacknowledged message can be used to
emulate partial reliability for that message. emulate partial reliability for that message.
If a QUIC receiver has opened the maximum allowed concurrent streams, If a QUIC receiver has opened the maximum allowed concurrent streams,
and the sender indicates that more streams are needed, it does not and the sender indicates that more streams are needed, it does not
automatically lead to an increase of the maximum number of streams by automatically lead to an increase of the maximum number of streams by
the receiver. Therefore, an application can use the maximum number the receiver. Therefore, an application can use the maximum number
of allowed, currently open, and currently used streams when of allowed, currently open, and currently used streams when
determining how to map data to streams. determining how to map data to streams.
QUIC assigns a numerical identifier to each stream, called the Stream QUIC assigns a numerical identifier to each stream, called the stream
ID. While the relationship between these identifiers and stream ID. While the relationship between these identifiers and stream
types is clearly defined in version 1 of QUIC, future versions might types is clearly defined in version 1 of QUIC, future versions might
change this relationship for various reasons. QUIC implementations change this relationship for various reasons. QUIC implementations
should expose the properties of each stream (which endpoint initiated should expose the properties of each stream (which endpoint initiated
the stream, whether the stream is unidirectional or bidirectional, the stream, whether the stream is unidirectional or bidirectional,
the Stream ID used for the stream); applications should query for the stream ID used for the stream); applications should query for
these properties rather than attempting to infer them from the Stream these properties rather than attempting to infer them from the stream
ID. ID.
The method of allocating stream identifiers to streams opened by the The method of allocating stream identifiers to streams opened by the
application might vary between transport implementations. Therefore, application might vary between transport implementations. Therefore,
an application should not assume a particular stream ID will be an application should not assume a particular stream ID will be
assigned to a stream that has not yet been allocated. For example, assigned to a stream that has not yet been allocated. For example,
HTTP/3 uses Stream IDs to refer to streams that have already been HTTP/3 uses stream IDs to refer to streams that have already been
opened, but makes no assumptions about future Stream IDs or the way opened, but makes no assumptions about future stream IDs or the way
in which they are assigned Section 6 of [QUIC-HTTP]). in which they are assigned Section 6 of [QUIC-HTTP]).
4.1. Stream versus Flow Multiplexing 4.1. Stream versus Flow Multiplexing
Streams are meaningful only to the application; since stream Streams are meaningful only to the application; since stream
information is carried inside QUIC's encryption boundary, no information is carried inside QUIC's encryption boundary, a given
information about the stream(s) whose frames are carried by a given packet exposes no information about which stream(s) are carried
packet is visible to the network. Therefore stream multiplexing is within the packet. Therefore, stream multiplexing is not intended to
not intended to be used for differentiating streams in terms of be used for differentiating streams in terms of network treatment.
network treatment. Application traffic requiring different network Application traffic requiring different network treatment should
treatment should therefore be carried over different five-tuples therefore be carried over different five-tuples (i.e. multiple QUIC
(i.e. multiple QUIC connections). Given QUIC's ability to send connections). Given QUIC's ability to send application data in the
application data in the first RTT of a connection (if a previous first RTT of a connection (if a previous connection to the same host
connection to the same host has been successfully established to has been successfully established to provide the necessary
provide the necessary credentials), the cost of establishing another credentials), the cost of establishing another connection is
connection is extremely low. extremely low.
4.2. Prioritization 4.2. Prioritization
Stream prioritization is not exposed to either the network or the Stream prioritization is not exposed to either the network or the
receiver. Prioritization is managed by the sender, and the QUIC receiver. Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize transport should provide an interface for applications to prioritize
streams [QUIC]. Applications can implement their own prioritization streams [QUIC]. Applications can implement their own prioritization
scheme on top of QUIC: an application protocol that runs on top of scheme on top of QUIC: an application protocol that runs on top of
QUIC can define explicit messages for signaling priority, such as QUIC can define explicit messages for signaling priority, such as
those defined in [I-D.draft-ietf-httpbis-priority] for HTTP; it can those defined in [I-D.draft-ietf-httpbis-priority] for HTTP; it can
define rules that allow an endpoint to determine priority based on define rules that allow an endpoint to determine priority based on
context; or it can provide a higher level interface and leave the context; or it can provide a higher level interface and leave the
determination to the application on top. determination to the application on top.
Priority handling of retransmissions can be implemented by the sender Priority handling of retransmissions can be implemented by the sender
in the transport layer. [QUIC] recommends retransmitting lost data in the transport layer. [QUIC] recommends retransmitting lost data
before new data, unless indicated differently by the application. before new data, unless indicated differently by the application.
Currently, QUIC only provides fully reliable stream transmission, When a QUIC endpoint uses fully reliable streams for transmission,
which means that prioritization of retransmissions will be beneficial prioritization of retransmissions will be beneficial in most cases,
in most cases, by filling in gaps and freeing up the flow control filling in gaps and freeing up the flow control window. For
window. For partially reliable or unreliable streams, priority partially reliable or unreliable streams, priority scheduling of
scheduling of retransmissions over data of higher-priority streams retransmissions over data of higher-priority streams might not be
might not be desirable. For such streams, QUIC could either provide desirable. For such streams, QUIC could either provide an explicit
an explicit interface to control prioritization, or derive the interface to control prioritization, or derive the prioritization
prioritization decision from the reliability level of the stream. decision from the reliability level of the stream.
4.3. Ordered and Reliable Delivery 4.3. Ordered and Reliable Delivery
QUIC streams enable ordered and reliable delivery. Though it is QUIC streams enable ordered and reliable delivery. Though it is
possible for an implementation to provide options that use streams possible for an implementation to provide options that use streams
for partial reliability or out-of-order delivery, most for partial reliability or out-of-order delivery, most
implementations will assume that data is reliably delivered in order. implementations will assume that data is reliably delivered in order.
Under this assumption, an endpoint that receives stream data might Under this assumption, an endpoint that receives stream data might
not make forward progress until data that is contiguous with the not make forward progress until data that is contiguous with the
skipping to change at page 11, line 47 skipping to change at page 12, line 5
of streams they would allow to be opened by their peer. Initial of streams they would allow to be opened by their peer. Initial
limits are advertised using the initial_max_streams_bidi and limits are advertised using the initial_max_streams_bidi and
initial_max_streams_uni transport parameters. As streams are opened initial_max_streams_uni transport parameters. As streams are opened
and closed they are consumed and the cumulative total is incremented. and closed they are consumed and the cumulative total is incremented.
Limits can be increased using the MAX_STREAMS frame but there is no Limits can be increased using the MAX_STREAMS frame but there is no
mechanism to reduce limits. Once stream limits are reached, no more mechanism to reduce limits. Once stream limits are reached, no more
streams can be opened, which prevents applications using QUIC from streams can be opened, which prevents applications using QUIC from
making further progress. At this stage connections can be terminated making further progress. At this stage connections can be terminated
via idle timeout or explicit close; see Section 10). via idle timeout or explicit close; see Section 10).
An application that uses QUIC might communicate a cumulative stream An application that uses QUIC and communicated a cumulative stream
limit but require the connection to be closed before the limit is limit might require the connection to be closed before the limit is
reached. For example, to stop the server to perform scheduled reached. For example, to stop the server to perform scheduled
maintenance. Immediate connection close causes abrupt closure of maintenance. Immediate connection close causes abrupt closure of
actively used streams. Depending on how an application uses QUIC actively used streams. Depending on how an application uses QUIC
streams, this could be undesirable or detrimental to behavior or streams, this could be undesirable or detrimental to behavior or
performance. A more graceful closure technique is to stop sending performance.
increases to stream limits and allow the connection to naturally
terminate once remaining streams are consumed. However, the period
of time it takes to do so is dependent on the client and an
unpredictable closing period might not fit application or operational
needs. Applications using QUIC can be conservative with open stream
limits in order to reduce the commitment and indeterminism. However,
being overly conservative with stream limits affects stream
concurrency. Balancing these aspects can be specific to applications
and their deployments. Instead of relying on stream limits to avoid
abrupt closure, an application-layer graceful close mechanism can be
used to communicate the intention to explicitly close the connection
at some future point.
HTTP/3 provides such a mechanism using the GOWAWAY frame. In HTTP/3, A more graceful closure technique is to stop sending increases to
when the GOAWAY frame is received by a client, it stops opening new stream limits and allow the connection to naturally terminate once
streams even if the cumulative stream limit would allow. Instead the remaining streams are consumed. However, the period of time it takes
client would create a new connection on which to open further to do so is dependent on the peer and an unpredictable closing period
streams. Once all streams are closed on the old connection, it can might not fit application or operational needs. Applications using
be terminated safely by a connection close or after expiration of the QUIC can be conservative with open stream limits in order to reduce
idle time out (see also Section 10). the commitment and indeterminism. However, being overly conservative
with stream limits affects stream concurrency. Balancing these
aspects can be specific to applications and their deployments.
Instead of relying on stream limits to avoid abrupt closure, an
application-layer graceful close mechanism can be used to communicate
the intention to explicitly close the connection at some future
point. HTTP/3 provides such a mechanism using the GOAWAY frame. In
HTTP/3, when the GOAWAY frame is received by a client, it stops
opening new streams even if the cumulative stream limit would allow.
Instead, the client would create a new connection on which to open
further streams. Once all streams are closed on the old connection,
it can be terminated safely by a connection close or after expiration
of the idle time out (see also Section 10).
5. Packetization and Latency 5. Packetization and Latency
QUIC exposes an interface that provides multiple streams to the QUIC exposes an interface that provides multiple streams to the
application; however, the application usually cannot control how data application; however, the application usually cannot control how data
transmitted over those streams is mapped into frames or how those transmitted over those streams is mapped into frames or how those
frames are bundled into packets. frames are bundled into packets.
By default, many implementations will try to maximally pack QUIC By default, many implementations will try to maximally pack QUIC
packets DATA frames from one or more streams to minimize bandwidth packets DATA frames from one or more streams to minimize bandwidth
consumption and computational costs (see Section 13 of [QUIC]). If consumption and computational costs (see Section 13 of [QUIC]). If
there is not enough data available to fill a packet, an there is not enough data available to fill a packet, an
implementation might wait for a short time, to optimize bandwidth implementation might wait for a short time, to optimize bandwidth
efficiency instead of latency. This delay can either be pre- efficiency instead of latency. This delay can either be pre-
configured or dynamically adjusted based on the observed sending configured or dynamically adjusted based on the observed sending
pattern of the application. pattern of the application.
If the application requires low latency, with only small chunks of If the application requires low latency, with only small chunks of
data to send, it may be valuable to indicate to QUIC that all data data to send, it may be valuable to indicate to QUIC that all data
should be send out immediately. Alternatively, if the application should be sent out immediately. Alternatively, if the application
expects to use a specific sending pattern, it can also provide a expects to use a specific sending pattern, it can also provide a
suggested delay to QUIC for how long to wait before bundle frames suggested delay to QUIC for how long to wait before bundle frames
into a packet. into a packet.
Similarly, an application has usually no control about the length of Similarly, an application has usually no control about the length of
a QUIC packet on the wire. QUIC provides the ability to add a a QUIC packet on the wire. QUIC provides the ability to add a
PADDING frame to arbitrarily increase the size of packets. Padding PADDING frame to arbitrarily increase the size of packets. Padding
is used by QUIC to ensure that the path is capable of transferring is used by QUIC to ensure that the path is capable of transferring
datagrams of at least a certain size, during the handshake (see datagrams of at least a certain size, during the handshake (see
Sections 8.1 and 14.1 of [QUIC]) and for path validation after Sections 8.1 and 14.1 of [QUIC]) and for path validation after
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Connection errors lead to connection termination. They are signaled Connection errors lead to connection termination. They are signaled
using a CONNECTION_CLOSE frame, which contains an error code and a using a CONNECTION_CLOSE frame, which contains an error code and a
reason field that can be zero length. Different types of reason field that can be zero length. Different types of
CONNECTION_CLOSE frame are used to signal transport and application CONNECTION_CLOSE frame are used to signal transport and application
errors. errors.
Stream errors lead to stream termination. The are signaled using Stream errors lead to stream termination. The are signaled using
STOP_SENDING or RESET_STREAM frames, which contain only an error STOP_SENDING or RESET_STREAM frames, which contain only an error
code. code.
7. ACK-only packets on constrained links 7. Acknowledgment Efficiency
The cost of sending acknowledgments - in processing cost or link QUIC version 1 without extensions uses an acknowledgment strategy
utilization - could be a significant proportion of available adopted from TCP. That is, every other packet is acknowledged.
resources if these resources are constrained. Reducing the rate at However, generating and processing QUIC acknowledgments can consume
which acknowledgments are generated can preserve these resources and significant resources, both in terms of processing costs and link
improve overall performance, for both network processing as well as utilization, especially on constraint networks. Some applications
application-relevant metrics. might be able to improve overall performance by using alternative
strategies that reduce the rate of acknowledgments.
8. Port Selection and Application Endpoint Discovery 8. Port Selection and Application Endpoint Discovery
In general, port numbers serve two purposes: "first, they provide a In general, port numbers serve two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes application protocol and associated service to which processes
connect" [RFC6335]. The assumption that an application can be connect" [RFC6335]. The assumption that an application can be
identified in the network based on the port number is less true today identified in the network based on the port number is less true today
due to encapsulation, mechanisms for dynamic port assignments, and due to encapsulation, mechanisms for dynamic port assignments, and
skipping to change at page 14, line 34 skipping to change at page 14, line 35
As QUIC is a general-purpose transport protocol, there are no As QUIC is a general-purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC. For requirements that servers use a particular UDP port for QUIC. For
applications with a fallback to TCP that do not already have an applications with a fallback to TCP that do not already have an
alternate mapping to UDP, usually the registration (if necessary) and alternate mapping to UDP, usually the registration (if necessary) and
use of the UDP port number corresponding to the TCP port already use of the UDP port number corresponding to the TCP port already
registered for the application is appropriate. For example, the registered for the application is appropriate. For example, the
default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to
HTTP/1.1 or HTTP/2 over TLS over TCP. HTTP/1.1 or HTTP/2 over TLS over TCP.
Additionally, Application-Layer Version Negotiation [RFC7301] permits
the client and server to negotiate which of several protocols will be
used on a given connection. Therefore, multiple applications might
be supported on a single UDP port based on the ALPN token offered.
Applications using QUIC should register an ALPN token for use in the
TLS handshake.
Applications could define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default. For example,
HTTP/3 (Sections 3.2 and 3.3 of [QUIC-HTTP]) specifies the use of
HTTP Alternative Services for an HTTP origin to advertise the
availability of an equivalent HTTP/3 endpoint on a certain UDP port
by using the "h3" ALPN token. Note that HTTP/3's ALPN token ("h3")
identifies not only the version of the application protocol, but also
the version of QUIC itself; this approach allows unambiguous
agreement between the endpoints on the protocol stack in use.
Given the prevalence of the assumption in network management practice Given the prevalence of the assumption in network management practice
that a port number maps unambiguously to an application, the use of that a port number maps unambiguously to an application, the use of
ports that cannot easily be mapped to a registered service name might ports that cannot easily be mapped to a registered service name might
lead to blocking or other changes to the forwarding behavior by lead to blocking or other changes to the forwarding behavior by
network elements such as firewalls that use the port number for network elements such as firewalls that use the port number for
application identification. application identification.
Applications could define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default. For example,
HTTP/3 (Sections 3.2 and 3.3 of [QUIC-HTTP]) specifies the use of
HTTP Alternative Services [RFC7838] for an HTTP origin to advertise
the availability of an equivalent HTTP/3 endpoint on a certain UDP
port by using the "h3" Application-Layer Protocol Negotiation (ALPN)
[RFC7301] token.
ALPN permits the client and server to negotiate which of several
protocols will be used on a given connection. Therefore, multiple
applications might be supported on a single UDP port based on the
ALPN token offered. Applications using QUIC are required to register
an ALPN token for use in the TLS handshake.
As QUIC version 1 deferred defining a complete version negotiation
mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token
("h3") to only apply to that version. So far no single approach has
been selected for managing the use of different QUIC versions,
neither in HTTP/3 nor in general. Application protocols that use
QUIC need to consider how the protocol will manage different QUIC
versions. Decisions for those protocols might be informed by choices
made by other protocols, like HTTP/3.
9. Connection Migration 9. Connection Migration
QUIC supports connection migration by the client. If an IP address QUIC supports connection migration by the client. If an IP address
changes, a QUIC endpoint can still associate packets with an existing changes, a QUIC endpoint can still associate packets with an existing
transport connection using the destination connection ID field (see transport connection using the Destination Connection ID field (see
also Section 11) in the QUIC header, unless a zero-length value is also Section 11) in the QUIC header. This supports cases where
used. This supports cases where address information changes, such as address information changes, such as NAT rebinding, intentional
NAT rebinding, intentional change of the local interface, or based on change of the local interface, or based on an indication in the
an indication in the handshake of the server for a preferred address handshake of the server for a preferred address to be used.
to be used.
Use of a non-zero-length connection ID for the server is strongly Use of a non-zero-length connection ID for the server is strongly
recommended if any clients are behind a NAT or could be. A non-zero- recommended if any clients are behind a NAT or could be. A non-zero-
length connection ID is also strongly recommended when migration is length connection ID is also strongly recommended when migration is
supported. supported.
Currently QUIC only supports failover cases. Only one "path" can be The base specification of QUIC version 1 only supports the use of a
used at a time; and only when the new path is validated, all traffic single network path at a time, which enables failover use cases.
can be switched over to that new path. Path validation means that Path validation is required so that endpoints validate paths before
the remote endpoint is required to validate the new path before use use to avoid address spoofing attacks. Path validation takes at
in order to avoid address spoofing attacks. Path validation takes at
least one RTT and congestion control will also be reset after path least one RTT and congestion control will also be reset after path
migration. Therefore migration usually has a performance impact. migration. Therefore, migration usually has a performance impact.
QUIC probing packets, which can be sent on multiple paths at once, QUIC probing packets, which can be sent on multiple paths at once,
are used to perform address validation as well as measure path are used to perform address validation as well as measure path
characteristics as input for the switching decision. Probing packets characteristics. Probing packets cannot carry application data but
cannot carry application data but may contain padding frames. likely contain padding frames. Endpoints can use information about
Endpoints can use information about their receipt as input to their receipt as input to congestion control for that path.
congestion control for that path. Applications could use information Applications could use information learned from probing to inform a
learned from probing to inform a decisions to switch paths. decision to switch paths.
Only the client can actively migrate in version 1 of QUIC. However, Only the client can actively migrate in version 1 of QUIC. However,
servers can indicate during the handshake that they prefer to servers can indicate during the handshake that they prefer to
transfer the connection to a different address after the handshake. transfer the connection to a different address after the handshake.
For instance, this could be used to move from an address that is For instance, this could be used to move from an address that is
shared by multiple servers to an address that is unique to the server shared by multiple servers to an address that is unique to the server
instance. The server can provide an IPv4 and an IPv6 address in a instance. The server can provide an IPv4 and an IPv6 address in a
transport parameter during the TLS handshake and the client can transport parameter during the TLS handshake and the client can
select between the two if both are provided. See also Section 9.6 of select between the two if both are provided. See also Section 9.6 of
[QUIC]. [QUIC].
10. Connection Termination 10. Connection Termination
QUIC connections are terminated in one of three ways: implicit idle QUIC connections are terminated in one of three ways: implicit idle
skipping to change at page 16, line 46 skipping to change at page 17, line 9
A stateless reset is an option of last resort for an endpoint that A stateless reset is an option of last resort for an endpoint that
does not have access to connection state. Receiving a stateless does not have access to connection state. Receiving a stateless
reset is an indication of an unrecoverable error distinct from reset is an indication of an unrecoverable error distinct from
connection errors in that there is no application-layer information connection errors in that there is no application-layer information
provided. provided.
11. Information Exposure and the Connection ID 11. Information Exposure and the Connection ID
QUIC exposes some information to the network in the unencrypted part QUIC exposes some information to the network in the unencrypted part
of the header, either before the encryption context is established or of the header, either before the encryption context is established or
because the information is intended to be used by the network. QUIC because the information is intended to be used by the network. For
has a long header that exposes some additional information (the more information on manageability of QUIC see also
version and the source connection ID), while the short header exposes [I-D.ietf-quic-manageability]. QUIC has a long header that exposes
only the destination connection ID. In QUIC version 1, the long some additional information (the version and the source connection
header is used during connection establishment, while the short ID), while the short header exposes only the destination connection
header is used for data transmission in an established connection. ID. In QUIC version 1, the long header is used during connection
establishment, while the short header is used for data transmission
in an established connection.
The connection ID can be zero length. Zero length connection IDs can The connection ID can be zero length. Zero length connection IDs can
be chosen on each endpoint individually, on any packet except the be chosen on each endpoint individually, on any packet except the
first packets sent by clients during connection establishment. first packets sent by clients during connection establishment.
An endpoint that selects a zero-length connection ID will receive An endpoint that selects a zero-length connection ID will receive
packets with a zero-length destination connection ID. The endpoint packets with a zero-length destination connection ID. The endpoint
needs to use other information, such as the source and destination IP needs to use other information, such as the source and destination IP
address and port number to identify which connection is referred to. address and port number to identify which connection is referred to.
This could mean that the endpoint is unable to match datagrams to This could mean that the endpoint is unable to match datagrams to
skipping to change at page 18, line 14 skipping to change at page 18, line 32
The most efficient mitigations for these attacks are through network The most efficient mitigations for these attacks are through network
design and/or operational practice, by using a load balancing design and/or operational practice, by using a load balancing
architecture that loads more flows onto a single server-side address, architecture that loads more flows onto a single server-side address,
by coordinating the timing of migrations in an attempt to increase by coordinating the timing of migrations in an attempt to increase
the number of simultaneous migrations at a given time, or through the number of simultaneous migrations at a given time, or through
other means. other means.
11.3. Using Server Retry for Redirection 11.3. Using Server Retry for Redirection
QUIC provides a Server Retry packet that can be sent by a server in QUIC provides a Retry packet that can be sent by a server in response
response to the Client Initial packet. The server may choose a new to the client Initial packet. The server may choose a new connection
connection ID in that packet and the client will retry by sending ID in that packet and the client will retry by sending another client
another Client Initial packet with the server-selected connection ID. Initial packet with the server-selected connection ID. This
This mechanism can be used to redirect a connection to a different mechanism can be used to redirect a connection to a different server,
server, e.g. due to performance reasons or when servers in a server e.g., due to performance reasons or when servers in a server pool are
pool are upgraded gradually, and therefore may support different upgraded gradually, and therefore may support different versions of
versions of QUIC. In this case, it is assumed that all servers QUIC.
belonging to a certain pool are served in cooperation with load
balancers that forward the traffic based on the connection ID. A In this case, it is assumed that all servers belonging to a certain
server can choose the connection ID in the Server Retry packet such pool are served in cooperation with load balancers that forward the
that the load balancer will redirect the next Client Initial packet traffic based on the connection ID. A server can choose the
to a different server in that pool. Alternatively the load balancer connection ID in the Retry packet such that the load balancer will
can directly offer a Retry service as further described in [QUIC-LB]. redirect the next Initial packet to a different server in that pool.
Alternatively the load balancer can directly offer a Retry service as
further described in [QUIC-LB].
Section 4 of [RFC5077] describes an example approach for constructing Section 4 of [RFC5077] describes an example approach for constructing
TLS resumption tickets that can be also applied for validation TLS resumption tickets that can be also applied for validation
tokens, however, the use of more modern cryptographic algorithms is tokens, however, the use of more modern cryptographic algorithms is
highly recommended. highly recommended.
12. Quality of Service (QoS) and DSCP 12. Quality of Service (QoS) and DSCP
QUIC assumes that all packets of a QUIC connection, or at least with QUIC, as defined in [RFC9000], has a single congestion controller and
the same 5-tuple {dest addr, source addr, protocol, dest port, source recovery handler. This design assumes that all packets of a QUIC
port}, will receive similar network treatment since feedback about connection, or at least with the same 5-tuple {dest addr, source
loss or delay of each packet is used as input to the congestion addr, protocol, dest port, source port} that same the same DiffServ
controller. Therefore it is not recommended to use different Code Point (DSCP) [RFC2475], will receive similar network treatment
DiffServ Code Points (DSCPs) [RFC2475] for packets belonging to the since feedback about loss or delay of each packet is used as input to
same connection. If differential network treatment, e.g. by the use the congestion controller. Therefore, packets belonging to the same
of different DSCPs, is desired, multiple QUIC connections to the same connection should use a single DSCP. Section 5.1 of [RFC7657]
server may be used. However, in general it is recommended to provides a discussion of DiffServ interactions with datagram
minimize the number of QUIC connections to the same server, to avoid transport protocols [RFC7657] (in this respect the interactions with
increased overheads and, more importantly, competing congestion QUIC resemble those of SCTP).
control.
When multiplexing multiple flows over a single QUIC connection, the
selected DSCP value should be the one associated with the highest
priority requested for all multiplexed flows.
If differential network treatment is desired, e.g., by the use of
different DSCPs, multiple QUIC connections to the same server may be
used. However, in general it is recommended to minimize the number
of QUIC connections to the same server, to avoid increased overhead
and, more importantly, competing congestion control.
As in other uses of DiffServ, when a packet enters a network segment
that does not support the DSCP value, this could result in the
connection not receiving the network treatment it expects. The DSCP
value in this packet could also be remarked as the packet travels
along the network path, changing the requested treatment.
13. Use of Versions and Cryptographic Handshake 13. Use of Versions and Cryptographic Handshake
Versioning in QUIC may change the protocol's behavior completely, Versioning in QUIC may change the protocol's behavior completely,
except for the meaning of a few header fields that have been declared except for the meaning of a few header fields that have been declared
to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher to be invariant [QUIC-INVARIANTS]. A version of QUIC with a higher
version number will not necessarily provide a better service, but version number will not necessarily provide a better service, but
might simply provide a different feature set. As such, an might simply provide a different feature set. As such, an
application needs to be able to select which versions of QUIC it application needs to be able to select which versions of QUIC it
wants to use. wants to use.
skipping to change at page 20, line 6 skipping to change at page 20, line 39
enabled. enabled.
During the initial deployment, some clients will have received During the initial deployment, some clients will have received
Version Negotiation packets that indicate that the server does not Version Negotiation packets that indicate that the server does not
support the new version. Other clients might have successfully support the new version. Other clients might have successfully
connected with the new version and so will believe that the server connected with the new version and so will believe that the server
supports the new version. Therefore, servers need to allow for this supports the new version. Therefore, servers need to allow for this
ambiguity when validating the negotiated version. ambiguity when validating the negotiated version.
The second stage of deployment commences once all server instances The second stage of deployment commences once all server instances
are able accept new connections with the new version. At this point, are able to accept new connections with the new version. At this
all servers can start sending the new version in Version Negotiation point, all servers can start sending the new version in Version
packets. Negotiation packets.
During the second stage, the server still allows for the possibility During the second stage, the server still allows for the possibility
that some clients believe the new version to be available and some do that some clients believe the new version to be available and some do
not. This state will persist only for as long as any Version not. This state will persist only for as long as any Version
Negotiation packets take to be transmitted and responded to. So the Negotiation packets take to be transmitted and responded to. So the
third stage can follow after a relatively short delay. third stage can follow after a relatively short delay.
The third stage completes the process by enabling authentication of The third stage completes the process by enabling authentication of
the negotiated version with the assumption that the new version is the negotiated version with the assumption that the new version is
fully available. fully available.
skipping to change at page 20, line 38 skipping to change at page 21, line 23
[I-D.ietf-quic-datagram] specifies a QUIC extension to enable sending [I-D.ietf-quic-datagram] specifies a QUIC extension to enable sending
and receiving unreliable datagrams over QUIC. Unlike operating and receiving unreliable datagrams over QUIC. Unlike operating
directly over UDP, applications that use the QUIC datagram service do directly over UDP, applications that use the QUIC datagram service do
not need to implement their own congestion control, per [RFC8085], as not need to implement their own congestion control, per [RFC8085], as
QUIC datagrams are congestion controlled. QUIC datagrams are congestion controlled.
QUIC datagrams are not flow-controlled, and as such data chunks may QUIC datagrams are not flow-controlled, and as such data chunks may
be dropped if the receiver is overloaded. While the reliable be dropped if the receiver is overloaded. While the reliable
transmission service of QUIC provides a stream-based interface to transmission service of QUIC provides a stream-based interface to
send and receive data in order over multiple QUIC streams, the send and receive data in order over multiple QUIC streams, the
datagram service has a unordered message-based interface. If needed, datagram service has an unordered message-based interface. If
an application layer framing can be used on top to allow separate needed, an application layer framing can be used on top to allow
flows of unreliable datagrams to be multiplexed on one QUIC separate flows of unreliable datagrams to be multiplexed on one QUIC
connection. connection.
16. IANA Considerations 16. IANA Considerations
This document has no actions for IANA; however, note that Section 8 This document has no actions for IANA; however, note that Section 8
recommends that application bindings to QUIC for applications using recommends that application bindings to QUIC for applications using
TCP register UDP ports analogous to their existing TCP registrations. TCP register UDP ports analogous to their existing TCP registrations.
17. Security Considerations 17. Security Considerations
skipping to change at page 22, line 8 skipping to change at page 22, line 37
for Education, Research, and Innovation under contract no. 15.0268. for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement. This support does not imply endorsement.
20. References 20. References
20.1. Normative References 20.1. Normative References
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021, draft-ietf-quic-transport-34, 14 January 2021,
<https://tools.ietf.org/html/draft-ietf-quic-transport- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
34>. transport-34>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-13, 14 January 2021, invariants-13, 14 January 2021,
<https://tools.ietf.org/html/draft-ietf-quic-invariants- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
13>. invariants-13>.
[QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, Work in Progress, Internet-Draft, draft-ietf-quic-tls-34,
14 January 2021, 14 January 2021, <https://datatracker.ietf.org/doc/html/
<https://tools.ietf.org/html/draft-ietf-quic-tls-34>. draft-ietf-quic-tls-34>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/rfc/rfc6335>. <https://www.rfc-editor.org/rfc/rfc6335>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
20.2. Informative References 20.2. Informative References
[Edeline16] [Edeline16]
Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and
B. Donnet, "Using UDP for Internet Transport Evolution B. Donnet, "Using UDP for Internet Transport Evolution
(arXiv preprint 1612.07816)", 22 December 2016, (arXiv preprint 1612.07816)", 22 December 2016,
skipping to change at page 23, line 9 skipping to change at page 23, line 44
[HTTP-REPLAY] [HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>. 2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[I-D.draft-ietf-httpbis-priority] [I-D.draft-ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-03, 11 January 2021, httpbis-priority-03, 11 January 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-priority- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
03>. priority-03>.
[I-D.draft-ietf-quic-version-negotiation] [I-D.draft-ietf-quic-version-negotiation]
Schinazi, D. and E. Rescorla, "Compatible Version Schinazi, D. and E. Rescorla, "Compatible Version
Negotiation for QUIC", Work in Progress, Internet-Draft, Negotiation for QUIC", Work in Progress, Internet-Draft,
draft-ietf-quic-version-negotiation-03, 4 February 2021, draft-ietf-quic-version-negotiation-04, 26 May 2021,
<https://tools.ietf.org/html/draft-ietf-quic-version- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
negotiation-03>. version-negotiation-04>.
[I-D.ietf-quic-datagram] [I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet- Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-02, 16 February 2021, Draft, draft-ietf-quic-datagram-02, 16 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-datagram-02>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-02>.
[I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-11, 21 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-11>.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P. S., and C. A. Wood, "An Perkins, C., Tiesel, P. S., and C. A. Wood, "An
Architecture for Transport Services", Work in Progress, Architecture for Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-arch-09, 2 November 2020, Internet-Draft, draft-ietf-taps-arch-10, 30 April 2021,
<https://tools.ietf.org/html/draft-ietf-taps-arch-09>. <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
arch-10>.
[PaaschNanog] [PaaschNanog]
Paasch, C., "Network Support for TCP Fast Open (NANOG 67 Paasch, C., "Network Support for TCP Fast Open (NANOG 67
presentation)", 13 June 2016, presentation)", 13 June 2016,
<https://www.nanog.org/sites/default/files/ <https://www.nanog.org/sites/default/files/
Paasch_Network_Support.pdf>. Paasch_Network_Support.pdf>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-http-34>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
[QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft- Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-06, 4 February 2021, ietf-quic-load-balancers-06, 4 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-load- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
balancers-06>. load-balancers-06>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>. <https://www.rfc-editor.org/rfc/rfc2475>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/rfc/rfc5077>.
skipping to change at page 24, line 29 skipping to change at page 25, line 24
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/rfc/rfc7413>. <https://www.rfc-editor.org/rfc/rfc7413>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/rfc/rfc7657>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>. March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96
QUIC BoF presentation)", 20 July 2016, QUIC BoF presentation)", 20 July 2016,
<https://www.ietf.org/proceedings/96/slides/slides-96- <https://www.ietf.org/proceedings/96/slides/slides-96-
quic-3.pdf>. quic-3.pdf>.
[Trammell16] [Trammell16]
 End of changes. 48 change blocks. 
176 lines changed or deleted 226 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/