rfc9308v1.txt   rfc9308.txt 
Internet Engineering Task Force (IETF) M. Kühlewind Internet Engineering Task Force (IETF) M. Kühlewind
Request for Comments: 9308 Ericsson Request for Comments: 9308 Ericsson
Category: Informational B. Trammell Category: Informational B. Trammell
ISSN: 2070-1721 Google ISSN: 2070-1721 Google Switzerland GmbH
August 2022 September 2022
Applicability of the QUIC Transport Protocol Applicability of the QUIC Transport Protocol
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.
skipping to change at line 82 skipping to change at line 82
11.3. Using Server Retry for Redirection 11.3. Using Server Retry for Redirection
12. Quality of Service (QoS) and Diffserv Code Point (DSCP) 12. Quality of Service (QoS) and Diffserv Code Point (DSCP)
13. Use of Versions and Cryptographic Handshake 13. Use of Versions and Cryptographic Handshake
14. Enabling Deployment of New Versions 14. Enabling Deployment of New Versions
15. Unreliable Datagram Service over QUIC 15. Unreliable Datagram Service over QUIC
16. IANA Considerations 16. IANA Considerations
17. Security Considerations 17. Security Considerations
18. References 18. References
18.1. Normative References 18.1. Normative References
18.2. Informative References 18.2. Informative References
Contributors
Acknowledgments Acknowledgments
Contributors
Authors' Addresses Authors' Addresses
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
skipping to change at line 193 skipping to change at line 193
data. data.
Application data sent by the client in 0-RTT packets could be Application data sent by the client in 0-RTT packets could be
processed more than once if it is replayed. Applications need to be processed more than once if it is replayed. Applications need to be
aware of what is safe to send in 0-RTT. Application protocols that aware of what is safe to send in 0-RTT. Application protocols that
seek to enable the use of 0-RTT need a careful analysis and a seek to enable the use of 0-RTT need a careful analysis and a
description of what can be sent in 0-RTT; see Section 5.6 of description of what can be sent in 0-RTT; see Section 5.6 of
[QUIC-TLS]. [QUIC-TLS].
In some cases, it might be sufficient to limit application data sent In some cases, it might be sufficient to limit application data sent
in 0-RTT to that which only causes actions at a server that are known in 0-RTT to data that does not cause actions with lasting effects at
to be free of lasting effect. Initiating data retrieval or a server. Initiating data retrieval or establishing configuration
establishing configuration are examples of actions that could be are examples of actions that could be safe. Idempotent operations --
safe. Idempotent operations -- those for which repetition has the those for which repetition has the same net effect as a single
same net effect as a single operation -- might be safe. However, it operation -- might be safe. However, it is also possible to combine
is also possible to combine individually idempotent operations into a individually idempotent operations into a non-idempotent sequence of
non-idempotent sequence of operations. operations.
Once a server accepts 0-RTT data, there is no means of selectively Once a server accepts 0-RTT data, there is no means of selectively
discarding data that is received. However, protocols can define ways discarding data that is received. However, protocols can define ways
to reject individual actions that might be unsafe if replayed. to reject individual actions that might be unsafe if replayed.
Some TLS implementations and deployments might be able to provide Some TLS implementations and deployments might be able to provide
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
skipping to change at line 226 skipping to change at line 226
no evidence of widespread implementation of this guideline in the no evidence of widespread implementation of this guideline in the
literature. However, short network timeout for UDP is well- literature. However, short network timeout for UDP 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
that there is a minimum value of 15 seconds, but recommends larger that there is a minimum value of 15 seconds, but recommends larger
values, or that keep-alive is omitted entirely. values, or that keep-alive is omitted 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 rebinding after a timeout. However, this only helps if one endpoint
endpoint maintains availability at the address its peer uses and the maintains availability at the address its peer uses and the peer is
peer is the one to send after the timeout occurs. the one to send after the timeout occurs.
Some QUIC connections might not be robust to NAT rebinding because Some QUIC connections might not be robust to NAT rebinding because
the routing infrastructure (in particular, load balancers) uses the the routing infrastructure (in particular, load balancers) uses the
address/port 4-tuple to direct traffic. Furthermore, middleboxes address/port 4-tuple to direct traffic. Furthermore, middleboxes
with functions other than address translation could still affect the with functions other than address translation could still affect the
path. In particular, some firewalls do not admit server traffic for path. In particular, some firewalls do not admit server traffic for
which the firewall has no recent state for a corresponding packet which the firewall has no recent state for a corresponding packet
sent from the client. sent from the client.
QUIC applications can adjust idle periods to manage the risk of QUIC applications can adjust idle periods to manage the risk of
timeout. Idle periods and the network idle timeout are distinct from timeout. Idle periods and the network idle timeout are distinct from
the connection idle timeout, which is defined as the minimum of the connection idle timeout, which is defined as the minimum of
either endpoint's idle timeout parameter; see Section 10.1 of either endpoint's idle timeout parameter; see Section 10.1 of [QUIC].
[QUIC]). There are three options: There are three options:
* Ignore the issue if the application-layer protocol consists only * Ignore the issue if the application-layer protocol consists only
of interactions with no or very short idle periods or if the of interactions with no or very short idle periods or if the
protocol's resistance to NAT rebinding is sufficient. protocol's resistance to NAT rebinding is sufficient.
* Ensure there are no long idle periods. * Ensure there are no long idle periods.
* Resume the session after a long idle period, using 0-RTT * Resume the session after a long idle period, using 0-RTT
resumption when appropriate. resumption when appropriate.
skipping to change at line 444 skipping to change at line 444
endpoints or in transit on the network. However, there are several endpoints or in transit on the network. However, there are several
ways in which limits can produce conditions that can cause a ways in which limits can produce conditions that can cause a
connection to either perform suboptimally or become deadlocked. connection to either perform suboptimally or become deadlocked.
Deadlocks in flow control are possible for any protocol that uses Deadlocks in flow control are possible for any protocol that uses
QUIC, though whether they become a problem depends on how QUIC, though whether they become a problem depends on how
implementations consume data and provide flow control credit. implementations consume data and provide flow control credit.
Understanding what causes deadlocking might help implementations Understanding what causes deadlocking might help implementations
avoid deadlocks. avoid deadlocks.
The size and rate of transport flow control credit updates can affect The size and rate of updates to flow control credit can affect
performance. Applications that use QUIC often have a data consumer performance. Applications that use QUIC often have a data consumer
that reads data from transport buffers. Some implementations might that reads data from transport buffers. Some implementations might
have independent transport-layer and application-layer receive have independent receive buffers at the transport layer and
buffers. Consuming data does not always imply it is immediately application layer. Consuming data does not always imply it is
processed. However, a common flow control implementation technique immediately processed. However, a common implementation technique is
is to extend credit to the sender by emitting MAX_DATA and/or to extend flow control credit to the sender by emitting MAX_DATA and/
MAX_STREAM_DATA frames as data is consumed. Delivery of these frames or MAX_STREAM_DATA frames as data is consumed. Delivery of these
is affected by the latency of the back channel from the receiver to frames is affected by the latency of the back channel from the
the data sender. If credit is not extended in a timely manner, the receiver to the data sender. If credit is not extended in a timely
sending application can be blocked, effectively throttling the manner, the sending application can be blocked, effectively
sender. throttling the sender.
Large application messages can produce deadlocking if the recipient Large application messages can produce deadlocking if the recipient
does not read data from the transport incrementally. If the message does not read data from the transport incrementally. If the message
is larger than the flow control credit available and the recipient is larger than the flow control credit available and the recipient
does not release additional flow control credit until the entire does not release additional flow control credit until the entire
message is received and delivered, a deadlock can occur. This is message is received and delivered, a deadlock can occur. This is
possible even where stream flow control limits are not reached possible even where stream flow control limits are not reached
because connection flow control limits can be consumed by other because connection flow control limits can be consumed by other
streams. streams.
skipping to change at line 510 skipping to change at line 510
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 and closed, they are consumed, and the cumulative total is
incremented. Limits can be increased using the MAX_STREAMS frame, incremented. Limits can be increased using the MAX_STREAMS frame,
but there is no mechanism to reduce limits. Once stream limits are but there is no mechanism to reduce limits. Once stream limits are
reached, no more streams can be opened, which prevents applications reached, no more streams can be opened, which prevents applications
using QUIC from making further progress. At this stage, connections using QUIC from making further progress. At this stage, connections
can be terminated via idle timeout or explicit close; see Section 10. can be terminated via idle timeout or explicit close; see Section 10.
An application that uses QUIC and communicates a cumulative stream An application that uses QUIC and communicates a cumulative stream
limit might require the connection to be closed before the limit is limit might require the connection to be closed before the limit is
reached, e.g., to stop the server to perform scheduled maintenance. reached, e.g., to stop the server in order to perform scheduled
Immediate connection close causes abrupt closure of actively used maintenance. Immediate connection close causes abrupt closure of
streams. Depending on how an application uses QUIC streams, this actively used streams. Depending on how an application uses QUIC
could be undesirable or detrimental to behavior or performance. streams, this could be undesirable or detrimental to behavior or
performance.
A more graceful closure technique is to stop sending increases to A more graceful closure technique is to stop sending increases to
stream limits and allow the connection to naturally terminate once stream limits and allow the connection to naturally terminate once
remaining streams are consumed. However, the period of time it takes remaining streams are consumed. However, the period of time it takes
to do so is dependent on the peer, and an unpredictable closing to do so is dependent on the peer, and an unpredictable closing
period might not fit application or operational needs. Applications period might not fit application or operational needs. Applications
using QUIC can be conservative with open stream limits in order to using QUIC can be conservative with open stream limits in order to
reduce the commitment and indeterminism. However, being overly reduce the commitment and indeterminism. However, being overly
conservative with stream limits affects stream concurrency. conservative with stream limits affects stream concurrency.
Balancing these aspects can be specific to applications and their Balancing these aspects can be specific to applications and their
skipping to change at line 544 skipping to change at line 545
connection, it can be terminated safely by a connection close or connection, it can be terminated safely by a connection close or
after expiration of the idle timeout (see Section 10). after expiration of the idle timeout (see 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 pack STREAM frames from
packets DATA frames from one or more streams to minimize bandwidth one or more streams into each QUIC packet, in order to minimize
consumption and computational costs (see Section 13 of [QUIC]). If bandwidth consumption and computational costs (see Section 13 of
there is not enough data available to fill a packet, an [QUIC]). If 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 efficiency instead of latency. This delay can either be
preconfigured or dynamically adjusted based on the observed sending preconfigured 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 sent 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 bundling frames suggested delay to QUIC for how long to wait before bundling frames
skipping to change at line 630 skipping to change at line 631
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" (Section 3 of [RFC6335]). The assumption that an connect" (Section 3 of [RFC6335]). The assumption that an
application can be identified in the network based on the port number application can be identified in the network based on the port number
is less true today due to encapsulation and mechanisms for dynamic is less true today due to encapsulation and mechanisms for dynamic
port assignments, as noted in [RFC6335]. port assignments, as noted in [RFC6335].
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 an
applications with a fallback to TCP that do not already have an application with a fallback to TCP that does not already have an
alternate mapping to UDP, usually the registration (if necessary) and alternate mapping to UDP, it is usually appropriate to register (if
use of the UDP port number corresponding to the TCP port already necessary) and use the UDP port number corresponding to the TCP port
registered for the application is appropriate. For example, the already registered for the application. For example, the default
default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to HTTP/1.1 or
HTTP/1.1 or HTTP/2 over TLS over TCP. HTTP/2 over TLS over TCP.
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 Applications could define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default. For example, to allow the usage of ports other than the default. For example,
skipping to change at line 684 skipping to change at line 685
to server misconfiguration: to server misconfiguration:
* port 53 - DNS [RFC1034] * port 53 - DNS [RFC1034]
* port 123 - NTP [RFC5905] * port 123 - NTP [RFC5905]
* port 1900 - SSDP [SSDP] * port 1900 - SSDP [SSDP]
* port 5353 - mDNS [RFC6762] * port 5353 - mDNS [RFC6762]
* port 11211 - memcached * port 11211 - memcache
Services might block source ports associated with protocols known to Services might block source ports associated with protocols known to
be vulnerable to reflection attacks to avoid the overhead of be vulnerable to reflection attacks to avoid the overhead of
processing large numbers of packets. However, this practice has processing large numbers of packets. However, this practice has
negative effects on clients -- not only does it require establishment negative effects on clients -- not only does it require establishment
of a new connection but in some instances might cause the client to of a new connection but in some instances might cause the client to
avoid using QUIC for that service for a period of time and downgrade avoid using QUIC for that service for a period of time and downgrade
to a non-UDP protocol (see Section 2). to a non-UDP protocol (see Section 2).
As a result, client implementations are encouraged to avoid using As a result, client implementations are encouraged to avoid using
skipping to change at line 841 skipping to change at line 842
the connection ID. the connection ID.
While sufficiently robust connection ID generation schemes will While sufficiently robust connection ID generation schemes will
mitigate linkability issues, they do not provide full protection. mitigate linkability issues, they do not provide full protection.
Analysis of the lifetimes of 6-tuples (source and destination Analysis of the lifetimes of 6-tuples (source and destination
addresses as well as the migrated Connection ID) may expose these addresses as well as the migrated Connection ID) may expose these
links anyway. links anyway.
In the case where connection migration in a server pool is rare, it In the case where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs. is trivial for an observer to associate two connection IDs.
Conversely, in the opposite limit where every server handles multiple Conversely, where every server handles multiple simultaneous
simultaneous migrations, even an exposed server mapping may be migrations, even an exposed server mapping may be insufficient
insufficient information. information.
The most efficient mitigations for these attacks are through network The most efficient mitigations for these attacks are through network
design and/or operational practices, by using a load-balancing design and/or operational practices, 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 by using the number of simultaneous migrations at a given time, or by using
other means. other means.
11.3. Using Server Retry for Redirection 11.3. Using Server Retry for Redirection
skipping to change at line 871 skipping to change at line 872
QUIC. QUIC.
In this case, it is assumed that all servers belonging to a certain In this case, it is assumed that all servers belonging to a certain
pool are served in cooperation with load balancers that forward the pool are served in cooperation with load balancers that forward the
traffic based on the connection ID. A server can choose the traffic based on the connection ID. A server can choose the
connection ID in the Retry packet such that the load balancer will connection ID in the Retry packet such that the load balancer will
redirect the next Initial packet to a different server in that pool. redirect the next Initial packet to a different server in that pool.
Alternatively, the load balancer can directly offer a Retry offload Alternatively, the load balancer can directly offer a Retry offload
as further described in [QUIC-RETRY]. as further described in [QUIC-RETRY].
Section 4 of [RFC5077] describes an example approach for constructing The approach described in Section 4 of [RFC5077] for constructing TLS
TLS resumption tickets that can be also applied for validation resumption tickets provides an example that can be also applied to
tokens; however, the use of more modern cryptographic algorithms is validation tokens. However, the use of more modern cryptographic
highly recommended. algorithms is highly recommended.
12. Quality of Service (QoS) and Diffserv Code Point (DSCP) 12. Quality of Service (QoS) and Diffserv Code Point (DSCP)
QUIC, as defined in [QUIC], has a single congestion controller and QUIC, as defined in [QUIC], has a single congestion controller and
recovery handler. This design assumes that all packets of a QUIC recovery handler. This design assumes that all packets of a QUIC
connection, or at least with the same 5-tuple {dest addr, source connection, or at least with the same 5-tuple {dest addr, source
addr, protocol, dest port, source port}, that have the same Diffserv addr, protocol, dest port, source port}, that have the same Diffserv
Code Point (DSCP) [RFC2475] will receive similar network treatment Code Point (DSCP) [RFC2475] will receive similar network treatment
since feedback about loss or delay of each packet is used as input to since feedback about loss or delay of each packet is used as input to
the congestion controller. Therefore, packets belonging to the same the congestion controller. Therefore, packets belonging to the same
skipping to change at line 964 skipping to change at line 965
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 an unordered message-based interface. If datagram service has an unordered message-based interface. If
needed, an application-layer framing can be used on top to allow needed, an application-layer framing can be used on top to allow
separate 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 an application that has already registered a TCP port
TCP register UDP ports analogous to their existing TCP registrations. but wants to specify QUIC as a transport should register a UDP port
analogous to their existing TCP registration.
17. Security Considerations 17. Security Considerations
See the security considerations in [QUIC] and [QUIC-TLS]; the See the security considerations in [QUIC] and [QUIC-TLS]; the
security considerations for the underlying transport protocol are security considerations for the underlying transport protocol are
relevant for applications using QUIC. Considerations on linkability, relevant for applications using QUIC. Considerations on linkability,
replay attacks, and randomness discussed in [QUIC-TLS] should be replay attacks, and randomness discussed in [QUIC-TLS] should be
taken into account when deploying and using QUIC. taken into account when deploying and using QUIC.
Further, migration to a new address exposes a linkage between client Further, migration to a new address exposes a linkage between client
skipping to change at line 1013 skipping to change at line 1015
RFC 8999, DOI 10.17487/RFC8999, May 2021, RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>. <https://www.rfc-editor.org/info/rfc8999>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
18.2. Informative References 18.2. Informative References
[Edeline16] [Edeline16]
Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B.
B. Donnet, "Using UDP for Internet Transport Evolution", Donnet, "Using UDP for Internet Transport Evolution",
DOI 10.48550/arXiv.1612.07816, 22 December 2016, DOI 10.48550/arXiv.1612.07816, 22 December 2016,
<https://arxiv.org/abs/1612.07816>. <https://arxiv.org/abs/1612.07816>.
[Hatonen10] [Hatonen10]
Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An Experimental Study of Home Sarolahti, P., and M. Kojo, "An Experimental Study of Home
Gateway Characteristics", Proc. ACM IMC 2010, November Gateway Characteristics", Proc. ACM IMC 2010, November
2010, <https://conferences.sigcomm.org/imc/2010/papers/ 2010, <https://conferences.sigcomm.org/imc/2010/papers/
p260.pdf>. p260.pdf>.
skipping to change at line 1054 skipping to change at line 1056
Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating [QUIC-LB] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating
Routable QUIC Connection IDs", Work in Progress, Internet- Routable QUIC Connection IDs", Work in Progress, Internet-
Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, Draft, draft-ietf-quic-load-balancers-14, 11 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
load-balancers-14>. load-balancers-14>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
draft-ietf-quic-manageability-18, 15 July 2022, September 2022, <https://www.rfc-editor.org/info/rfc9312>.
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-18>.
[QUIC-RETRY] [QUIC-RETRY]
Duke, M. and N. Banks, "QUIC Retry Offload", Work in Duke, M. and N. Banks, "QUIC Retry Offload", Work in
Progress, Internet-Draft, draft-ietf-quic-retry-offload- Progress, Internet-Draft, draft-ietf-quic-retry-offload-
00, 25 May 2022, <https://datatracker.ietf.org/doc/html/ 00, 25 May 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-quic-retry-offload-00>. draft-ietf-quic-retry-offload-00>.
[QUIC-VERSION-NEGOTIATION] [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,
skipping to change at line 1173 skipping to change at line 1173
[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/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[Trammell16] [Trammell16]
Trammell, B. and M. Kühlewind, "Internet Path Transparency Trammell, B. and M. Kühlewind, "Internet Path Transparency
Measurements using RIPE Atlas", RIPE 72 MAT Presentation, Measurements using RIPE Atlas", RIPE 72 MAT Presentation,
25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/ 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/
presentations/86-atlas-udpdiff.pdf>. presentations/86-atlas-udpdiff.pdf>.
Contributors Acknowledgments
The following people have contributed significant text to or feedback Special thanks to Last Call reviewers Chris Lonvick and Ines Robles.
on this document:
* Gorry Fairhurst This work was partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI) and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement.
* Ian Swett Contributors
* Igor Lubashev The following people have contributed significant text to or feedback
on this document:
* Lucas Pardue Gorry Fairhurst
* Mike Bishop Ian Swett
* Mark Nottingham Igor Lubashev
* Martin Duke Lucas Pardue
* Martin Thomson Mike Bishop
* Sean Turner Mark Nottingham
* Tommy Pauly Martin Duke
Acknowledgments Martin Thomson
Special thanks to Last Call reviewers Chris Lonvick and Ines Robles. Sean Turner
This work was partially supported by the European Commission under Tommy Pauly
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI) and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement.
Authors' Addresses Authors' Addresses
Mirja Kühlewind Mirja Kühlewind
Ericsson Ericsson
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
Brian Trammell Brian Trammell
Google Google Switzerland GmbH
Gustav-Gull-Platz 1 Gustav-Gull-Platz 1
CH-8004 Zurich CH-8004 Zurich
Switzerland Switzerland
Email: ietf@trammell.ch Email: ietf@trammell.ch
 End of changes. 33 change blocks. 
78 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.48.