Draft: draft-ietf-quic-applicability

Commentary: This does n't necessarily cover some changes to acknowledgement / contributor ordering or fixes to references ; all text edits are backported to MD , though . 
 Terminology : We have made the following updates throughout the text . Please let us know if any changes are necessary . a ) The following terms were used inconsistently . We have chosen the latter form : four - tuple / 4 - tuple five - tuple / 5 - tuple six - tuple / 6 - tuple application level / application layer transport level / transport layer Zero RTT / 0 - RTT b ) Although the following term was formatted consistently , we have updated it to match other RFCs : DiffServ / Diffserv ( RFC 7657 ) 
 These replacements are all good IMO . 
 PR merged 
 : Does the following rewording improve the readability of the sentence ? Current : This document has no actions for IANA ; however , note that recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations . Perhaps : This document has no actions for IANA ; however , note that recommends that an application that has already registered a TCP port but wants to specify QUIC as a transport should register a UDP port analogous to their existing TCP registration . 
 Yes , this edit is good . 
 PR merged 
 : RFC 5077 has been obsoleted by RFC 8446 . How may we update the following cross reference ? Original : of describes an example approach for constructing TLS resumption tickets that can be also applied for validation tokens , however , the use of more modern cryptographic algorithms is highly recommended . 
 I believe the right thing to do here is not to update the cross - reference , as we 're pointing out that the TLS session ticket example ( removed from 8446 as far as I can tell ) is useful guidance for building validation tokens . I would suggest some clarifying text here to note that we do , indeed , know that we 're citing an obsolete RFC : NEW : The approach described in of for constructing TLS resumption tickets provides an example that can also be applied to validation tokens . However , the use of more modern cryptographic algorithms than those presented in this example is highly recommended . 
 PR merged 
 : Does removing redundant wording improve the readability of the following ? Current : Conversely , in the opposite limit where every server handles multiple simultaneous migrations , even an exposed server mapping may be insufficient information . Perhaps : Conversely , when every server handles multiple simultaneous migrations , even an exposed server mapping may be insufficient information . 
 This edit seems good to me . 
 : FYI , we replaced the CID acronym , which is not used elsewhere , with " Connection ID " for clarity . Please let us know if there are any objections . Original : Analysis of the lifetimes of six - tuples ( source and destination addresses as well as the migrated CID ) may expose these links anyway . Current : Analysis of the lifetimes of 6 - tuples ( source and destination addresses as well as the migrated Connection ID ) may expose these links anyway . 
 This edit is good . 
 : Would you like to provide a reference for memcached ? Current : For example , these source ports are associated with applications known to be vulnerable to reflection attacks often due to server misconfiguration : port 53 - DNS [ RFC1034 ] port 123 - NTP [ RFC5905 ] port 1900 - SSDP [ SSDP ] port 5353 - mDNS [ RFC6762 ] port - memcached 
 The best reference here seems to be The port assignment is personal . 
 ( So I suppose my suggested guidance to the RFC Editor would be " please add a reference to Memcached Overview pointing to " -- I 'm not sure what the best practices are on reference - a - webpage - informatively ) 
 It 's in the iana registry without a ref ; so I would rather not add a ref . The details of the protocol are not important , only that the number number should be used . However in IANA it 's actually called " memcache " ! 
 Okay , so let 's edit this back to " memcache " ( the service name ) without a ref then . SGTM . 
 : Does rewording the following sentence improve readability ? Current : For applications with a fallback to TCP that do not already have an alternate mapping to UDP , usually the registration ( if necessary ) and use of the UDP port number corresponding to the TCP port already registered for the application is appropriate . Perhaps ( making " application " single , more clearly stating what is usually appropriate ): For an application with a fallback to TCP that does not already have an alternate mapping to UDP , it is usually appropriate to register ( if necessary ) and use of the UDP port number corresponding to the TCP port already registered for the application . 
 The sugggested edit is good IMO 
 Modulo an " of " that needs to be remove : OLD .... it is usually appropriate to register ( if necessary ) and use of the UDP port number ... NEW ... it is usually appropriate to register ( if necessary ) and use the UDP port number ... 
 : We 're having difficulty with the following sentence because we do not see " DATA frames " in RFC 9000 . We do see  and  frames , but discusses STREAM frames . Also , should " packets ... frames " be " packets ' ... frames " ? Please let us know how we may update this sentence . Current : By default , many implementations will try to maximally pack QUIC packets DATA frames from one or more streams to minimize bandwidth consumption and computational costs ( see Section 13 of [ QUIC ] ) . 
 I think we misspelled STREAM here . :) Suggest NEW : By default , many implementations will try to pack STREAM frames from from one or more streams into each QUIC packet , in order to minimize bandwidth consumption and computational costs ( see Section 13 of [ QUIC ] ) . 
 : Are there some words missing in the example given in the following sentence ? Current : An application that uses QUIC and communicates a cumulative stream limit might require the connection to be closed before the limit is reached , e.g. , to stop the server to perform scheduled maintenance . Perhaps ( adding " in order " ): An application that uses QUIC and communicates a cumulative stream limit might require the connection to be closed before the limit is reached , e.g. , to stop the server in order to perform scheduled maintenance . 
 The suggested edit is good , IMO . 
 : We found these sentences in the third paragraph difficult to parse because of the number of noun modifiers . Current : The size and rate of transport flow control credit updates can affect performance .... Some implementations might have independent transport - layer and application - layer receive buffers ... However , a common flow control implementation technique is to extend credit ... Perhaps ( splitting apart the descriptions ): The size and rate of updates to flow control credit can affect performance .... . Some implementations might have independent receive buffers at the transport layer and application layer .... However , a common implementation technique is to extend flow control credit ... 
 Each of the suggested edits in " perhaps " is good , IMO . 
 : This is the one instance of " NAT address rebinding " , whereas the other instances are simply " NAT rebinding " . Please review these occurrences and let us know if / how they may be made consistent . Original : By using a connection ID , QUIC is designed to be robust to NAT address rebinding after a timeout . 
 Suggest cutting " address " , i.e. NEW : By using a connection ID , QUIC is designed to be robust to NAT rebinding after a timeout . 
 : We 're having difficulty parsing the following sentence . Does rewriting the last part of the sentence improve readability ? Current : 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 to be free of lasting effect . Perhaps ( clarifying that the data should not cause lasting effects ): In some cases , it might be sufficient to limit the application data sent in 0 - RTT to data that does not cause actions with lasting effects at a server . 
 The suggested edit is good . 
 : FYI , we have expanded TAPS in the following : Original : The IETF TAPS specifications [ I - D.ietf - taps - arch ] describe a system with a common API for multiple protocols . Current : The IETF Transport Services ( TAPS ) specifications [ TAPS - ARCH ] describe a system with a common API for multiple protocols . 
 This edit is fine , IMO . 
 Please merge when you 're readyThanks for this work ! This looks all good to me ( without having checked the XML from the RPC though ) .
Paragraph (version A):
In the following sections we discuss specific caveats to QUIC's
applicability, and issues that application developers must consider
when using QUIC as a transport for their application.
Paragraph (version B):
In the following sections, we discuss specific caveats to QUIC's
applicability and issues that application developers must consider
when using QUIC as a transport for their applications.
Paragraph (version A):
Measurement studies have shown between three Trammell16 and five
Swett16 percent of networks block all UDP traffic, though there is
little evidence of other forms of systematic disadvantage to UDP
traffic compared to TCP Edeline16.  This blocking implies that all
applications running on top of QUIC must either be prepared to accept
connectivity failure on such networks, or be engineered to fall back
to some other transport protocol.  In the case of HTTP, this fallback
is TLS over TCP.
Paragraph (version A):
The IETF TAPS specifications I-D.ietf-taps-arch describe a system
with a common API for multiple protocols.  This is particularly
relevant for QUIC as it addresses the implications of fallback among
multiple protocols.
Paragraph (version A):
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided.  In general, an application
that implements fallback needs to consider the security consequences.
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.  Additionally, downgrades to older
TLS versions than 1.3, which is used in QUIC version 1, might result
in significantly weaker cryptographic protection.  For example, the
results of protocol negotiation RFC7301 only have confidentiality
protection if TLS 1.3 is used.
Paragraph (version B):
Measurement studies have shown between 3% Trammell16 and 5% Swett16
of networks block all UDP traffic, though there is little evidence of
other forms of systematic disadvantage to UDP traffic compared to TCP
Edeline16.  This blocking implies that all applications running on
top of QUIC must either be prepared to accept connectivity failure on
such networks or be engineered to fall back to some other transport
protocol.  In the case of HTTP, this fallback is TLS over TCP.
Paragraph (version B):
The IETF TAPS specifications TAPS-ARCH describe a system with a
common API for multiple protocols.  This is particularly relevant for
QUIC as it addresses the implications of fallback among multiple
protocols.
Paragraph (version B):
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided.  In general, an application
that implements fallback needs to consider the security consequences.
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.  Additionally, downgrades to TLS
versions older than 1.3, which is used in QUIC version 1, might
result in significantly weaker cryptographic protection.  For
example, the results of protocol negotiation RFC7301 only have
confidentiality protection if TLS 1.3 is used.
Paragraph (version A):
PaaschNanog).  And even if Fast Open successfully operates end-to-
end, it is limited to a single packet of TLS handshake and
application data, unlike QUIC 0-RTT.
Paragraph (version B):
PaaschNanog).  And even if Fast Open successfully operates end to
end, it is limited to a single packet of TLS handshake and
application data, unlike QUIC 0-RTT.
Paragraph (version A):
Retransmission or (malicious) replay of data contained in 0-RTT
packets could cause the server side to receive multiple copies of the
same data.
Paragraph (version B):
Retransmission or malicious replay of data contained in 0-RTT packets
could cause the server side to receive multiple copies of the same
data.
Paragraph (version A):
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
to be free of lasting effect.  Initiating data retrieval or
establishing configuration are examples of actions that could be
safe.  Idempotent operations - those for which repetition has the
same net effect as a single operation - might be safe.  However, it
is also possible to combine individually idempotent operations into a
non-idempotent sequence of operations.
Paragraph (version A):
Once a server accepts 0-RTT data there is no means of selectively
discarding data that is received.  However, protocols can define ways
to reject individual actions that might be unsafe if replayed.
Paragraph (version B):
In some cases, it might be sufficient to limit application data sent
in 0-RTT to data that does not cause actions with lasting effects at
a server.  Initiating data retrieval or establishing configuration
are examples of actions that could be safe.  Idempotent operations -
those for which repetition has the same net effect as a single
operation - might be safe.  However, it is also possible to combine
individually idempotent operations into a non-idempotent sequence of
operations.
Paragraph (version B):
Once a server accepts 0-RTT data, there is no means of selectively
discarding data that is received.  However, protocols can define ways
to reject individual actions that might be unsafe if replayed.
Paragraph (version A):
Because QUIC is encapsulated in UDP, applications using QUIC must
deal with short network idle timeouts.  Deployed stateful middleboxes
will generally establish state for UDP flows on the first packet
sent, and keep state for much shorter idle periods than for TCP.
RFC5382 suggests a TCP idle period of at least 124 minutes, though
there is no evidence of widespread implementation of this guideline
in the literature.  Short network timeout for UDP, however, is well-
documented.  According to a 2010 study (Hatonen10), UDP applications
can assume that any NAT binding or other state entry can expire after
just thirty seconds of inactivity.  Section 3.5 of RFC8085 further
discusses keep-alive intervals for UDP: it requires a minimum value
of 15 seconds, but recommends larger values, or omitting keep-alive
entirely.
Paragraph (version A):
By using a connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout.  However, this only helps if one
endpoint maintains availability at the address its peer uses, and the
peer is the one to send after the timeout occurs.
Paragraph (version A):
Some QUIC connections might not be robust to NAT rebinding because
the routing infrastructure (in particular, load balancers) uses the
address/port four-tuple to direct traffic.  Furthermore, middleboxes
with functions other than address translation could still affect the
path.  In particular, some firewalls do not admit server traffic for
which the firewall has no recent state for a corresponding packet
sent from the client.
Paragraph (version B):
Because QUIC is encapsulated in UDP, applications using QUIC must
deal with short network idle timeouts.  Deployed stateful middleboxes
will generally establish state for UDP flows on the first packet sent
and keep state for much shorter idle periods than for TCP.  RFC5382
suggests a TCP idle period of at least 124 minutes, though there is
no evidence of widespread implementation of this guideline in the
literature.  However, short network timeout for UDP is well-
documented.  According to a 2010 study (Hatonen10), UDP applications
can assume that any NAT binding or other state entry can expire after
just thirty seconds of inactivity.  Section 3.5 of RFC8085 further
discusses keep-alive intervals for UDP: it requires that there is a
minimum value of 15 seconds, but recommends larger values, or that
keep-alive is omitted entirely.
Paragraph (version B):
By using a connection ID, QUIC is designed to be robust to NAT
rebinding after a timeout.  However, this only helps if one endpoint
maintains availability at the address its peer uses, and the peer is
the one to send after the timeout occurs.
Paragraph (version B):
Some QUIC connections might not be robust to NAT rebinding because
the routing infrastructure (in particular, load balancers) uses the
address/port 4-tuple to direct traffic.  Furthermore, middleboxes
with functions other than address translation could still affect the
path.  In particular, some firewalls do not admit server traffic for
which the firewall has no recent state for a corresponding packet
sent from the client.
Paragraph (version A):
Ignore the issue, if the application-layer protocol consists only
of interactions with no or very short idle periods, or the
protocol's resistance to NAT rebinding is sufficient.
Paragraph (version B):
Ignore the issue if the application-layer protocol consists only
of interactions with no or very short idle periods or if the
protocol's resistance to NAT rebinding is sufficient.
Paragraph (version A):
Either the server or the client in a QUIC application can send PING
frames as keep-alives, to prevent the connection and any on-path
state from timing out.  Recommendations for the use of keep-alives
are application-specific, mainly depending on the latency
requirements and message frequency of the application.  In this case,
the application mapping must specify whether the client or server is
responsible for keeping the application alive.  While Hatonen10
suggests that 30 seconds might be a suitable value for the public
Internet when a NAT is on path, larger values are preferable if the
deployment can consistently survive NAT rebinding or is known to be
in a controlled environment (e.g.  data centres) in order to lower
network and computational load.
Paragraph (version A):
Sending PING frames more frequently than every 30 seconds over long
idle periods may result in excessive unproductive traffic in some
situations, and unacceptable power usage for power-constrained
(mobile) devices.  Additionally, timeouts shorter than 30 seconds can
make it harder to handle transient network interruptions, such as VM
migration or coverage loss during mobility.  See RFC8085, especially
Section 3.5.
Paragraph (version A):
Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic.  In this case, a
client that wants to send data to a server over a connection that has
been idle longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect.  When
possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection.  Of
course, this approach is only valid in cases in which it is safe to
use 0-RTT and when the client is the restarting peer.
Paragraph (version B):
Either the server or the client in a QUIC application can send PING
frames as keep-alives to prevent the connection and any on-path state
from timing out.  Recommendations for the use of keep-alives are
application specific, mainly depending on the latency requirements
and message frequency of the application.  In this case, the
application mapping must specify whether the client or server is
responsible for keeping the application alive.  While Hatonen10
suggests that 30 seconds might be a suitable value for the public
Internet when a NAT is on path, larger values are preferable if the
deployment can consistently survive NAT rebinding or is known to be
in a controlled environment (e.g., data centers) in order to lower
network and computational load.
Paragraph (version B):
Sending PING frames more frequently than every 30 seconds over long
idle periods may result in excessive unproductive traffic in some
situations and unacceptable power usage for power-constrained
(mobile) devices.  Additionally, timeouts shorter than 30 seconds can
make it harder to handle transient network interruptions, such as VM
migration or coverage loss during mobility.  See RFC8085, especially
Section 3.5.
Paragraph (version B):
Alternatively, the client (but not the server) can use session
resumption instead of sending keep-alive traffic.  In this case, a
client that wants to send data to a server over a connection that has
been idle longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect.  When
possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection.  Of
course, this approach is only valid in cases in which it is safe to
use 0-RTT and when the client is the restarting peer.
Paragraph (version A):
The tradeoffs between resumption and keep-alives need to be evaluated
on a per-application basis.  In general, applications should use
keep-alives only in circumstances where continued communication is
highly likely; QUIC-HTTP, for instance, recommends using keep-alives
only when a request is outstanding.
Paragraph (version A):
QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection, without head-of-line
blocking between streams.  Stream data is carried within frames,
where one QUIC packet on the wire can carry one or multiple stream
frames.
Paragraph (version B):
The trade-offs between resumption and keep-alives need to be
evaluated on a per-application basis.  In general, applications
should use keep-alives only in circumstances where continued
communication is highly likely; QUIC-HTTP, for instance, recommends
using keep-alives only when a request is outstanding.
Paragraph (version B):
QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection without head-of-line
blocking between streams.  Stream data is carried within frames where
one QUIC packet on the wire can carry one or multiple stream frames.
Paragraph (version A):
Multiple streams provide concurrency.  Data that can be processed
independently, and therefore would suffer from head of line
blocking if forced to be received in order, should be transmitted
over separate streams.
Paragraph (version A):
Streams can provide message orientation, and allow messages to be
cancelled.  If one message is mapped to a single stream, resetting
the stream to expire an unacknowledged message can be used to
emulate partial reliability for that message.
Paragraph (version B):
Multiple streams provide concurrency.  Data that can be processed
independently, and therefore would suffer from head-of-line
blocking if forced to be received in order, should be transmitted
over separate streams.
Paragraph (version B):
Streams can provide message orientation and allow messages to be
canceled.  If one message is mapped to a single stream, resetting
the stream to expire an unacknowledged message can be used to
emulate partial reliability for that message.
Paragraph (version A):
QUIC assigns a numerical identifier to each stream, called the stream
ID.  While the relationship between these identifiers and stream
types is clearly defined in version 1 of QUIC, future versions might
change this relationship for various reasons.  QUIC implementations
should expose the properties of each stream (which endpoint initiated
the stream, whether the stream is unidirectional or bidirectional,
the stream ID used for the stream); applications should query for
these properties rather than attempting to infer them from the stream
ID.
Paragraph (version B):
QUIC assigns a numerical identifier, called the stream ID, to each
stream.  While the relationship between these identifiers and stream
types is clearly defined in version 1 of QUIC, future versions might
change this relationship for various reasons.  QUIC implementations
should expose the properties of each stream (which endpoint initiated
the stream, whether the stream is unidirectional or bidirectional,
the stream ID used for the stream); applications should query for
these properties rather than attempting to infer them from the stream
ID.
Paragraph (version A):
The method of allocating stream identifiers to streams opened by the
application might vary between transport implementations.  Therefore,
an application should not assume a particular stream ID will be
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
opened, but makes no assumptions about future stream IDs or the way
in which they are assigned (see Section 6 of QUIC-HTTP).
Paragraph (version B):
The method of allocating stream identifiers to streams opened by the
application might vary between transport implementations.  Therefore,
an application should not assume a particular stream ID will be
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
opened but makes no assumptions about future stream IDs or the way in
which they are assigned (see Section 6 of QUIC-HTTP).
Paragraph (version A):
Streams are meaningful only to the application; since stream
information is carried inside QUIC's encryption boundary, a given
packet exposes no information about which stream(s) are carried
within the packet.  Therefore, stream multiplexing is not intended to
be used for differentiating streams in terms of network treatment.
Application traffic requiring different network treatment should
therefore be carried over different five-tuples (i.e.  multiple QUIC
connections).  Given QUIC's ability to send application data in the
first RTT of a connection (if a previous connection to the same host
has been successfully established to provide the necessary
credentials), the cost of establishing another connection is
extremely low.
Paragraph (version B):
Streams are meaningful only to the application; since stream
information is carried inside QUIC's encryption boundary, a given
packet exposes no information about which stream(s) are carried
within the packet.  Therefore, stream multiplexing is not intended to
be used for differentiating streams in terms of network treatment.
Application traffic requiring different network treatment should
therefore be carried over different 5-tuples (i.e., multiple QUIC
connections).  Given QUIC's ability to send application data in the
first RTT of a connection (if a previous connection to the same host
has been successfully established to provide the necessary
credentials), the cost of establishing another connection is
extremely low.
Paragraph (version A):
Stream prioritization is not exposed to either the network or the
receiver.  Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Applications can implement their own prioritization
scheme on top of QUIC: an application protocol that runs on top of
QUIC can define explicit messages for signaling priority, such as
those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can
define rules that allow an endpoint to determine priority based on
context; or it can provide a higher level interface and leave the
determination to the application on top.
Paragraph (version B):
Stream prioritization is not exposed to either the network or the
receiver.  Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Applications can implement their own prioritization
scheme on top of QUIC: an application protocol that runs on top of
QUIC can define explicit messages for signaling priority, such as
those defined in RFC9218 for HTTP.  An application protocol can
define rules that allow an endpoint to determine priority based on
context or it can provide a higher-level interface and leave the
determination to the application on top.
Paragraph (version A):
Priority handling of retransmissions can be implemented by the sender
in the transport layer.  QUIC recommends retransmitting lost data
before new data, unless indicated differently by the application.
When a QUIC endpoint uses fully reliable streams for transmission,
prioritization of retransmissions will be beneficial in most cases,
filling in gaps and freeing up the flow control window.  For
partially reliable or unreliable streams, priority scheduling of
retransmissions over data of higher-priority streams might not be
desirable.  For such streams, QUIC could either provide an explicit
interface to control prioritization, or derive the prioritization
decision from the reliability level of the stream.
Paragraph (version B):
Priority handling of retransmissions can be implemented by the sender
in the transport layer.  QUIC recommends retransmitting lost data
before new data, unless indicated differently by the application.
When a QUIC endpoint uses fully reliable streams for transmission,
prioritization of retransmissions will be beneficial in most cases,
filling in gaps and freeing up the flow control window.  For
partially reliable or unreliable streams, priority scheduling of
retransmissions over data of higher-priority streams might not be
desirable.  For such streams, QUIC could either provide an explicit
interface to control prioritization or derive the prioritization
decision from the reliability level of the stream.
Paragraph (version A):
QUIC flow control Section 4 of QUIC provides a means of managing
access to the limited buffers endpoints have for incoming data.  This
mechanism limits the amount of data that can be in buffers in
endpoints or in transit on the network.  However, there are several
ways in which limits can produce conditions that can cause a
connection to either perform suboptimally or deadlock.
Paragraph (version B):
QUIC flow control (Section 4 of QUIC) provides a means of managing
access to the limited buffers endpoints have for incoming data.  This
mechanism limits the amount of data that can be in buffers in
endpoints or in transit on the network.  However, there are several
ways in which limits can produce conditions that can cause a
connection to either perform suboptimally or become deadlocked.
Paragraph (version A):
The size and rate of transport flow control credit updates can affect
performance.  Applications that use QUIC often have a data consumer
that reads data from transport buffers.  Some implementations might
have independent transport-layer and application-layer receive
buffers.  Consuming data does not always imply it is immediately
processed.  However, a common flow control implementation technique
is to extend credit to the sender, by emitting MAX_DATA and/or
MAX_STREAM_DATA frames, as data is consumed.  Delivery of these
frames is affected by the latency of the back channel from the
receiver to the data sender.  If credit is not extended in a timely
manner, the sending application can be blocked, effectively
throttling the sender.
Paragraph (version B):
The size and rate of updates to flow control credit can affect
performance.  Applications that use QUIC often have a data consumer
that reads data from transport buffers.  Some implementations might
have independent buffers at the transport layer and application
layer.  Consuming data does not always imply it is immediately
processed.  However, a common implementation technique is to extend
flow control credit to the sender by emitting MAX_DATA and/or
MAX_STREAM_DATA frames as data is consumed.  Delivery of these frames
is affected by the latency of the back channel from the receiver to
the data sender.  If credit is not extended in a timely manner, the
sending application can be blocked, effectively throttling the
sender.
Paragraph (version A):
A data consumer can eagerly read all data as it becomes available, in
order to make the receiver extend flow control credit and reduce the
chances of a deadlock.  However, such a data consumer might need
other means for holding a peer accountable for the additional state
it keeps for partially processed messages.
Paragraph (version B):
A data consumer can eagerly read all data as it becomes available in
order to make the receiver extend flow control credit and reduce the
chances of a deadlock.  However, such a data consumer might need
other means for holding a peer accountable for the additional state
it keeps for partially processed messages.
Paragraph (version A):
Deadlocking can also occur if data on different streams is
interdependent.  Suppose that data on one stream arrives before the
data on a second stream on which it depends.  A deadlock can occur if
the first stream is left unread, preventing the receiver from
extending flow control credit for the second stream.  To reduce the
likelihood of deadlock for interdependent data, the sender should
ensure that dependent data is not sent until the data it depends on
has been accounted for in both stream- and connection- level flow
control credit.
Paragraph (version A):
Some deadlocking scenarios might be resolved by cancelling affected
streams with STOP_SENDING or RESET_STREAM.  Cancelling some streams
results in the connection being terminated in some protocols.
Paragraph (version B):
Deadlocking can also occur if data on different streams is
interdependent.  Suppose that data on one stream arrives before the
data on a second stream on which it depends.  A deadlock can occur if
the first stream is left unread, preventing the receiver from
extending flow control credit for the second stream.  To reduce the
likelihood of deadlock for interdependent data, the sender should
ensure that dependent data is not sent until the data it depends on
has been accounted for in both stream- and connection-level flow
control credit.
Paragraph (version B):
Some deadlocking scenarios might be resolved by canceling affected
streams with STOP_SENDING or RESET_STREAM.  Canceling some streams
results in the connection being terminated in some protocols.
Paragraph (version A):
QUIC endpoints are responsible for communicating the cumulative limit
of streams they would allow to be opened by their peer.  Initial
limits are advertised using the initial_max_streams_bidi and
initial_max_streams_uni transport parameters.  As streams are opened
and closed they are consumed, and the cumulative total is
incremented.  Limits can be increased using the MAX_STREAMS frame but
there is no mechanism to reduce limits.  Once stream limits are
reached, no more streams can be opened, which prevents applications
using QUIC from making further progress.  At this stage connections
can be terminated via idle timeout or explicit close; see sec-
termination).
Paragraph (version A):
An application that uses QUIC and communicated a cumulative stream
limit might require the connection to be closed before the limit is
reached.  For example, to stop the server to perform scheduled
maintenance.  Immediate connection close causes abrupt closure of
actively used streams.  Depending on how an application uses QUIC
streams, this could be undesirable or detrimental to behavior or
performance.
Paragraph (version B):
QUIC endpoints are responsible for communicating the cumulative limit
of streams they would allow to be opened by their peer.  Initial
limits are advertised using the initial_max_streams_bidi and
initial_max_streams_uni transport parameters.  As streams are opened
and closed, they are consumed, and the cumulative total is
incremented.  Limits can be increased using the MAX_STREAMS frame,
but there is no mechanism to reduce limits.  Once stream limits are
reached, no more streams can be opened, which prevents applications
using QUIC from making further progress.  At this stage, connections
can be terminated via idle timeout or explicit close; see sec-
termination.
Paragraph (version B):
An application that uses QUIC and communicates a cumulative stream
limit might require the connection to be closed before the limit is
reached, e.g., to stop the server in order to perform scheduled
maintenance.  Immediate connection close causes abrupt closure of
actively used streams.  Depending on how an application uses QUIC
streams, this could be undesirable or detrimental to behavior or
performance.
Paragraph (version A):
A more graceful closure technique is to stop sending 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 peer 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.
Paragraph (version A):
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 sec-termination).
Paragraph (version B):
A more graceful closure technique is to stop sending 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 peer, 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.
Paragraph (version B):
Instead of relying on stream limits to avoid abrupt closure, an
application layer's 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 sec-termination).
Paragraph (version A):
By default, many implementations will try to maximally pack QUIC
packets DATA frames from one or more streams to minimize bandwidth
consumption and computational costs (see Section 13 of QUIC).  If
there is not enough data available to fill a packet, an
implementation might wait for a short time, to optimize bandwidth
efficiency instead of latency.  This delay can either be pre-
configured or dynamically adjusted based on the observed sending
pattern of the application.
Paragraph (version A):
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
should be sent out immediately.  Alternatively, if the application
expects to use a specific sending pattern, it can also provide a
suggested delay to QUIC for how long to wait before bundle frames
into a packet.
Paragraph (version A):
Similarly, an application has usually no control about the length of
a QUIC packet on the wire.  QUIC provides the ability to add a
PADDING frame to arbitrarily increase the size of packets.  Padding
is used by QUIC to ensure that the path is capable of transferring
datagrams of at least a certain size, during the handshake (see
Sections 8.1 and 14.1 of QUIC) and for path validation after
connection migration (see Section 8.2 of QUIC) as well as for
Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see
Section 14.3 of QUIC).
Paragraph (version B):
By default, many implementations will try to pack STREAM frames from
from one or more streams into each QUIC packet, in order to minimize
bandwidth consumption and computational costs (see Section 13 of
QUIC).  If there is not enough data available to fill a packet, an
implementation might wait for a short time to optimize bandwidth
efficiency instead of latency.  This delay can either be
preconfigured or dynamically adjusted based on the observed sending
pattern of the application.
Paragraph (version B):
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
should be sent out immediately.  Alternatively, if the application
expects to use a specific sending pattern, it can also provide a
suggested delay to QUIC for how long to wait before bundling frames
into a packet.
Paragraph (version B):
Similarly, an application usually has no control over the length of a
QUIC packet on the wire.  QUIC provides the ability to add a PADDING
frame to arbitrarily increase the size of packets.  Padding is used
by QUIC to ensure that the path is capable of transferring datagrams
of at least a certain size during the handshake (see Sections 8.1 and
Section 8.2 of QUIC) as well as for Datagram Packetization Layer PMTU
Discovery (DPLPMTUD) (see Section 14.3 of QUIC).
Paragraph (version A):
QUIC recommends that endpoints signal any detected errors to the
peer.  Errors can occur at the transport level and the application
level.  Transport errors, such as a protocol violation, affect the
entire connection.  Applications that use QUIC can define their own
error detection and signaling (see, for example, Section 8 of QUIC-
HTTP).  Application errors can affect an entire connection or a
single stream.
Paragraph (version B):
QUIC recommends that endpoints signal any detected errors to the
peer.  Errors can occur at the transport layer and the application
layer.  Transport errors, such as a protocol violation, affect the
entire connection.  Applications that use QUIC can define their own
error detection and signaling (see, for example, Section 8 of QUIC-
HTTP).  Application errors can affect an entire connection or a
single stream.
Paragraph (version A):
Connection errors lead to connection termination.  They are signaled
using a CONNECTION_CLOSE frame, which contains an error code and a
reason field that can be zero length.  Different types of
CONNECTION_CLOSE frame are used to signal transport and application
errors.
Paragraph (version B):
Connection errors lead to connection termination.  They are signaled
using a CONNECTION_CLOSE frame, which contains an error code and a
reason field that can be zero length.  Different types of
CONNECTION_CLOSE frames are used to signal transport and application
errors.
Paragraph (version A):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP (see Section 13.2 of QUIC).  That is, it recommends
every other packet is acknowledged.  However, generating and
processing QUIC acknowledgments consumes resources at a sender and
receiver.  Acknowledgments also incur forwarding costs and contribute
to link utilization, which can impact performance over some types of
network.  Applications might be able to improve overall performance
by using alternative strategies that reduce the rate of
acknowledgments.  I-D.ietf-quic-ack-frequency describes an extension
to signal the desired delay of acknowledgments and discusses use
cases as well as implications for congestion control and recovery.
Paragraph (version B):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP (see Section 13.2 of QUIC).  That is, it recommends
every other packet is acknowledged.  However, generating and
processing QUIC acknowledgments consumes resources at a sender and
receiver.  Acknowledgments also incur forwarding costs and contribute
to link utilization, which can impact performance over some types of
network.  Applications might be able to improve overall performance
by using alternative strategies that reduce the rate of
acknowledgments.  QUIC-ACK-FREQUENCY describes an extension to signal
the desired delay of acknowledgments and discusses use cases as well
as implications for congestion control and recovery.
Paragraph (version A):
In general, port numbers serve two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes
connect" RFC6335.  The assumption that an application can be
identified in the network based on the port number is less true today
due to encapsulation and mechanisms for dynamic port assignments, as
also noted in RFC6335.
Paragraph (version A):
As QUIC is a general-purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC.  For
applications with a fallback to TCP that do not already have an
alternate mapping to UDP, usually the registration (if necessary) and
use of the UDP port number corresponding to the TCP port already
registered for the application is appropriate.  For example, the
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to
HTTP/1.1 or HTTP/2 over TLS over TCP.
Paragraph (version B):
In general, port numbers serve two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes
connect" (Section 3 of RFC6335).  The assumption that an application
can be identified in the network based on the port number is less
true today due to encapsulation and mechanisms for dynamic port
assignments, as noted in RFC6335.
Paragraph (version B):
As QUIC is a general-purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC.  For an
application with a fallback to TCP that does not already have an
alternate mapping to UDP, it is usually appropriate to register (if
necessary) and use of the UDP port number corresponding to the TCP
port already registered for the application.  For example, the
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to
HTTP/1.1 or HTTP/2 over TLS over TCP.
Paragraph (version A):
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.
Paragraph (version B):
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 "h3" as the Application-Layer Protocol Negotiation (ALPN)
RFC7301 token.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Services might block source ports associated with protocols known to
be vulnerable to reflection attacks, to avoid the overhead of
processing large numbers of packets.  However, this practice has
negative effects on clients: not only does it require establishment
of a new connection, but in some instances, might cause the client to
avoid using QUIC for that service for a period of time, downgrading
to a non-UDP protocol (see fallback).
Paragraph (version B):
Services might block source ports associated with protocols known to
be vulnerable to reflection attacks to avoid the overhead of
processing large numbers of packets.  However, this practice has
negative effects on clients - not only does it require establishment
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
to a non-UDP protocol (see fallback).
Paragraph (version A):
QUIC supports connection migration by the client.  If the client's IP
address changes, a QUIC endpoint can still associate packets with an
existing transport connection using the Destination Connection ID
field (see also connid) in the QUIC header.  This supports cases
where address information changes, such as NAT rebinding, intentional
change of the local interface, the expiration of a temporary IPv6
address RFC8981, or the server indicating a preferred address
Section 9.6 of QUIC.
Paragraph (version A):
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-
length connection ID is also strongly recommended when active
migration is supported.  If a connection is intentionally migrated to
new path, a new connection ID is used to minimize linkability by
network observers.  The other QUIC endpoint uses the connection ID to
link different addresses to the same connection and entity if a non-
zero-length connection ID is provided.
Paragraph (version B):
QUIC supports connection migration by the client.  If the client's IP
address changes, a QUIC endpoint can still associate packets with an
existing transport connection using the Destination Connection ID
field (see connid) in the QUIC header.  This supports cases where the
address information changes, such as NAT rebinding, the intentional
change of the local interface, the expiration of a temporary IPv6
address RFC8981, or the indication from the server of a preferred
address (Section 9.6 of QUIC).
Paragraph (version B):
Use of a non-zero-length connection ID for the server is strongly
recommended if any clients are or could be behind a NAT.  A non-zero-
length connection ID is also strongly recommended when active
migration is supported.  If a connection is intentionally migrated to
new path, a new connection ID is used to minimize linkability by
network observers.  The other QUIC endpoint uses the connection ID to
link different addresses to the same connection and entity if a non-
zero-length connection ID is provided.
Paragraph (version A):
The base specification of QUIC version 1 only supports the use of a
single network path at a time, which enables failover use cases.
Path validation is required so that endpoints validate paths before
use to avoid address spoofing attacks.  Path validation takes at
least one RTT and congestion control will also be reset after path
migration.  Therefore, migration usually has a performance impact.
Paragraph (version B):
The base specification of QUIC version 1 only supports the use of a
single network path at a time, which enables failover use cases.
Path validation is required so that endpoints validate paths before
use to avoid address spoofing attacks.  Path validation takes at
least one RTT, and congestion control will also be reset after path
migration.  Therefore, migration usually has a performance impact.
Paragraph (version A):
Only the client can actively migrate in version 1 of QUIC.  However,
servers can indicate during the handshake that they prefer to
transfer the connection to a different address after the handshake.
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
instance.  The server can provide an IPv4 and an IPv6 address in a
transport parameter during the TLS handshake and the client can
select between the two if both are provided.  See also Section 9.6 of
QUIC.
Paragraph (version B):
Only the client can actively migrate in version 1 of QUIC.  However,
servers can indicate during the handshake that they prefer to
transfer the connection to a different address after the handshake.
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
instance.  The server can provide an IPv4 and an IPv6 address in a
transport parameter during the TLS handshake, and the client can
select between the two if both are provided.  See Section 9.6 of
QUIC.
Paragraph (version A):
QUIC idle timeout is enabled via transport parameters.  Client and
server announce a timeout period and the effective value for the
connection is the minimum of the two values.  After the timeout
period elapses, the connection is silently closed.  An application
therefore should be able to configure its own maximum value, as well
as have access to the computed minimum value for this connection.  An
application may adjust the maximum idle timeout for new connections
based on the number of open or expected connections, since shorter
timeout values may free-up resources more quickly.
Paragraph (version A):
Application data exchanged on streams or in datagrams defers the QUIC
idle timeout.  Applications that provide their own keep-alive
mechanisms will therefore keep a QUIC connection alive.  Applications
that do not provide their own keep-alive can use transport-layer
mechanisms (see Section 10.1.2 of QUIC, and resumption-v-keepalive).
However, QUIC implementation interfaces for controlling such
transport behavior can vary, affecting the robustness of such
approaches.
Paragraph (version B):
QUIC idle timeout is enabled via transport parameters.  The client
and server announce a timeout period, and the effective value for the
connection is the minimum of the two values.  After the timeout
period elapses, the connection is silently closed.  An application
therefore should be able to configure its own maximum value, as well
as have access to the computed minimum value for this connection.  An
application may adjust the maximum idle timeout for new connections
based on the number of open or expected connections since shorter
timeout values may free-up resources more quickly.
Paragraph (version B):
Application data exchanged on streams or in datagrams defers the QUIC
idle timeout.  Applications that provide their own keep-alive
mechanisms will therefore keep a QUIC connection alive.  Applications
that do not provide their own keep-alive can use transport-layer
mechanisms (see Section 10.1.2 of QUIC and resumption-v-keepalive).
However, QUIC implementation interfaces for controlling such
transport behavior can vary, affecting the robustness of such
approaches.
Paragraph (version A):
QUIC exposes some information to the network in the unencrypted part
of the header, either before the encryption context is established or
because the information is intended to be used by the network.  For
more information on manageability of QUIC see also I-D.ietf-quic-
manageability.  QUIC has a long header that exposes some additional
information (the version and the source connection ID), while the
short header exposes only the destination 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.
Paragraph (version A):
The connection ID can be zero length.  Zero length connection IDs can
be chosen on each endpoint individually, on any packet except the
first packets sent by clients during connection establishment.
Paragraph (version B):
QUIC exposes some information to the network in the unencrypted part
of the header either before the encryption context is established or
because the information is intended to be used by the network.  For
more information on manageability of QUIC, see also QUIC-
MANAGEABILITY.  QUIC has a long header that exposes some additional
information (the version and the source connection ID), while the
short header exposes only the destination 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.
Paragraph (version B):
The connection ID can be zero length.  Zero-length connection IDs can
be chosen on each endpoint individually and on any packet except the
first packets sent by clients during connection establishment.
Paragraph (version A):
QUIC supports a server-generated connection ID, transmitted to the
client during connection establishment (see Section 7.2 of QUIC).
Servers behind load balancers may need to change the connection ID
during the handshake, encoding the identity of the server or
information about its load balancing pool, in order to support
stateless load balancing.
Paragraph (version B):
QUIC supports a server-generated connection ID that is transmitted to
the client during connection establishment (see Section 7.2 of QUIC).
Servers behind load balancers may need to change the connection ID
during the handshake, encoding the identity of the server or
information about its load balancing pool, in order to support
stateless load balancing.
Paragraph (version A):
Server deployments with load balancers and other routing
infrastructure need to ensure that this infrastructure consistently
routes packets to the server instance that has the connection state,
even if addresses, ports, and/or connection IDs change.  This might
require coordination between servers and infrastructure.  One method
of achieving this involves encoding routing information into the
connection ID.  For an example of this technique, see QUIC-LB.
Paragraph (version B):
Server deployments with load balancers and other routing
infrastructure need to ensure that this infrastructure consistently
routes packets to the server instance that has the connection state,
even if addresses, ports, or connection IDs change.  This might
require coordination between servers and infrastructure.  One method
of achieving this involves encoding routing information into the
connection ID.  For an example of this technique, see QUIC-LB.
Paragraph (version A):
While sufficiently robust connection ID generation schemes will
mitigate linkability issues, they do not provide full protection.
Analysis of the lifetimes of six-tuples (source and destination
addresses as well as the migrated CID) may expose these links anyway.
Paragraph (version A):
In the case where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs.
Conversely, in the opposite limit where every server handles multiple
simultaneous migrations, even an exposed server mapping may be
insufficient information.
Paragraph (version A):
The most efficient mitigations for these attacks are through network
design and/or operational practice, by using a load balancing
architecture that loads more flows onto a single server-side address,
by coordinating the timing of migrations in an attempt to increase
the number of simultaneous migrations at a given time, or through
other means.
Paragraph (version A):
QUIC provides a Retry packet that can be sent by a server in response
to the client Initial packet.  The server may choose a new connection
ID in that packet and the client will retry by sending another client
Initial packet with the server-selected connection ID.  This
mechanism can be used to redirect a connection to a different server,
e.g., due to performance reasons or when servers in a server pool are
upgraded gradually, and therefore may support different versions of
QUIC.
Paragraph (version B):
While sufficiently robust connection ID generation schemes will
mitigate linkability issues, they do not provide full protection.
Analysis of the lifetimes of 6-tuples (source and destination
addresses as well as the migrated Connection ID) may expose these
links anyway.
Paragraph (version B):
In the case where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs.
Conversely, where every server handles multiple simultaneous
migrations, even an exposed server mapping may be insufficient
information.
Paragraph (version B):
The most efficient mitigations for these attacks are through network
design and/or operational practices, by using a load-balancing
architecture that loads more flows onto a single server-side address,
by coordinating the timing of migrations in an attempt to increase
the number of simultaneous migrations at a given time, or by using
other means.
Paragraph (version B):
QUIC provides a Retry packet that can be sent by a server in response
to the client Initial packet.  The server may choose a new connection
ID in that packet, and the client will retry by sending another
client Initial packet with the server-selected connection ID.  This
mechanism can be used to redirect a connection to a different server,
e.g., due to performance reasons or when servers in a server pool are
upgraded gradually and therefore may support different versions of
QUIC.
Paragraph (version A):
In this case, it is assumed that all servers belonging to a certain
pool are served in cooperation with load balancers that forward the
traffic based on the connection ID.  A server can choose the
connection ID in the Retry packet such that the load balancer will
redirect the next Initial packet to a different server in that pool.
Alternatively the load balancer can directly offer a Retry offload as
further described in QUIC-RETRY.
Paragraph (version A):
Section 4 of RFC5077 describes an example approach for constructing
TLS resumption tickets that can be also applied for validation
tokens, however, the use of more modern cryptographic algorithms is
highly recommended.
Paragraph (version A):
QUIC, as defined in QUIC, has a single congestion controller and
recovery handler.  This design assumes that all packets of a QUIC
connection, or at least with the same 5-tuple {dest addr, source
addr, protocol, dest port, source port}, that have the same DiffServ
Code Point (DSCP) RFC2475 will receive similar network treatment
since feedback about loss or delay of each packet is used as input to
the congestion controller.  Therefore, packets belonging to the same
connection should use a single DSCP.  Section 5.1 of RFC7657 provides
a discussion of DiffServ interactions with datagram transport
protocols RFC7657 (in this respect the interactions with QUIC
resemble those of SCTP).
Paragraph (version B):
In this case, it is assumed that all servers belonging to a certain
pool are served in cooperation with load balancers that forward the
traffic based on the connection ID.  A server can choose the
connection ID in the Retry packet such that the load balancer will
redirect the next Initial packet to a different server in that pool.
Alternatively, the load balancer can directly offer a Retry offload
as further described in QUIC-RETRY.
Paragraph (version B):
The approach described in Section 4 of RFC5077 for constructing TLS
resumption tickets provides an example that can also be applied to
validation tokens.  However, the use of more modern cryptographic
algorithms than those presented in this example is highly
recommended.
Paragraph (version B):
QUIC, as defined in QUIC, has a single congestion controller and
recovery handler.  This design assumes that all packets of a QUIC
connection, or at least with the same 5-tuple {dest addr, source
addr, protocol, dest port, source port}, that have the same Diffserv
Code Point (DSCP) RFC2475 will receive similar network treatment
since feedback about loss or delay of each packet is used as input to
the congestion controller.  Therefore, packets belonging to the same
connection should use a single DSCP.  Section 5.1 of RFC7657 provides
a discussion of DiffServ interactions with datagram transport
protocols RFC7657 (in this respect, the interactions with QUIC
resemble those of Stream Control Transmission Protocol (SCTP)).
Paragraph (version A):
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.
Paragraph (version B):
If differential network treatment is desired, e.g., by the use of
different DSCPs, multiple QUIC connections to the same server may be
used.  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.
Paragraph (version A):
Versioning in QUIC may change the protocol's behavior completely,
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
version number will not necessarily provide a better service, but
might simply provide a different feature set.  As such, an
application needs to be able to select which versions of QUIC it
wants to use.
Paragraph (version B):
Versioning in QUIC may change the protocol's behavior completely,
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
version number will not necessarily provide a better service but
might simply provide a different feature set.  As such, an
application needs to be able to select which versions of QUIC it
wants to use.
Paragraph (version A):
A new version could use an encryption scheme other than TLS 1.3 or
higher.  QUIC specifies requirements for the cryptographic handshake
as currently realized by TLS 1.3 and described in a separate
specification QUIC-TLS.  This split is performed to enable light-
weight versioning with different cryptographic handshakes.
Paragraph (version A):
The QUIC Versions Registry established in QUIC allows for provisional
registrations for experimentation.  Registration, also of
experimental versions, is important to avoid collision.  Experimental
versions should not be used long-term or registered as permanent to
minimize the risk of fingerprinting based on the version number.
Paragraph (version B):
A new version could use an encryption scheme other than TLS 1.3 or
higher.  QUIC specifies requirements for the cryptographic handshake
as currently realized by TLS 1.3 and described in a separate
specification QUIC-TLS.  This split is performed to enable
lightweight versioning with different cryptographic handshakes.
Paragraph (version B):
The "QUIC Versions" registry established in QUIC allows for
provisional registrations for experimentation.  Registration, also of
experimental versions, is important to avoid collision.  Experimental
versions should not be used long-term or registered as permanent to
minimize the risk of fingerprinting based on the version number.
Paragraph (version A):
QUIC version 1 does not specify a version negotiation mechanism in
the base specification, but I-D.draft-ietf-quic-version-negotiation
proposes an extension that provides compatible version negotiation.
Paragraph (version B):
QUIC version 1 does not specify a version negotiation mechanism in
the base specification, but QUIC-VERSION-NEGOTIATION proposes an
extension that provides compatible version negotiation.
Paragraph (version A):
See Section 5 of I-D.draft-ietf-quic-version-negotiation for details.
Paragraph (version B):
See Section 5 of QUIC-VERSION-NEGOTIATION for details.
Paragraph (version A):
QUIC datagrams are not flow-controlled, and as such data chunks may
be dropped if the receiver is overloaded.  While the reliable
transmission service of QUIC provides a stream-based interface to
send and receive data in order over multiple QUIC streams, the
datagram service has an unordered message-based interface.  If
needed, an application layer framing can be used on top to allow
separate flows of unreliable datagrams to be multiplexed on one QUIC
connection.
Paragraph (version A):
This document has no actions for IANA; however, note that ports
recommends that application bindings to QUIC for applications using
TCP register UDP ports analogous to their existing TCP registrations.
Paragraph (version A):
See the security considerations in QUIC and QUIC-TLS; the security
considerations for the underlying transport protocol are relevant for
applications using QUIC, as well.  Considerations on linkability,
replay attacks, and randomness discussed in QUIC-TLS should be taken
into account when deploying and using QUIC.
Paragraph (version B):
QUIC datagrams are not flow controlled, and as such data chunks may
be dropped if the receiver is overloaded.  While the reliable
transmission service of QUIC provides a stream-based interface to
send and receive data in order over multiple QUIC streams, the
datagram service has an unordered message-based interface.  If
needed, an application-layer framing can be used on top to allow
separate flows of unreliable datagrams to be multiplexed on one QUIC
connection.
Paragraph (version B):
This document has no actions for IANA; however, note that ports
recommends that an application that has already registered a TCP port
but wants to specify QUIC as a transport should register a UDP port
analogous to their existing TCP registration.
Paragraph (version B):
See the security considerations in QUIC and QUIC-TLS; the security
considerations for the underlying transport protocol are relevant for
applications using QUIC.  Considerations on linkability, replay
attacks, and randomness discussed in QUIC-TLS should be taken into
account when deploying and using QUIC.
Paragraph (version A):
Application developers should note that any fallback they use when
QUIC cannot be used due to network blocking of UDP should guarantee
the same security properties as QUIC; if this is not possible, the
connection should fail to allow the application to explicitly handle
fallback to a less-secure alternative.  See fallback.
Paragraph (version B):
Application developers should note that any fallback they use when
QUIC cannot be used due to network blocking of UDP should guarantee
the same security properties as QUIC.  If this is not possible, the
connection should fail to allow the application to explicitly handle
fallback to a less-secure alternative.  See fallback.