Draft: draft-ietf-quic-applicability

Commentary: From PR : I 'd also like to see something like : /In this section , we discuss those aspects of the QUIC transport protocol that / This section discusses those aspects of the QUIC transport protocol that/ /Here , we are concerned primarily with the unencrypted part of QUIC 's wire image { { WIRE - IMAGE } } , which we define as the information available in the packet / This section is concerned primarily with the unencrypted part of QUIC 's wire image { { WIRE - IMAGE } } , defined as the information available in the packet/ and /least four datagrams we 'll call " Client Initial",/least four datagrams , labelled " Client Initial",/ and / 0 - RTT data may also be seen in the Client Initial datagram , as shown in /When the client uses 0 - RTT connection resumption , the Client Initial datagram can also carry 0 - RTT data , as shown in/ and /typically around 10 packets / typically to around 10 packets/ and /of a connection after one of one endpoint / of a connection after an endpoint/ I 'd prefer more like : /Though the guidance there holds , a particularly unwise behavior admits a handful of UDP packets and then makes a decision as to whether or not to filter later packets in the same connection . QUIC applications are encouraged to fail over to TCP if early packets do/ ... and I 'll close PR . 
 “ 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 . ” Could this benefit form a cross - reference to manageability , where this topic is also discussed from a network perspective ? 
 Three places where the text might avoid confusion when read in future years : 1 ) “ Further downgrades to older TLS versions than used in QUIC , which is 1.3 , “ … will it always be 1.3 , or should this be “ in QUIC [ REF ] is TLS 1.3 ” 2 ) “ Currently , QUIC only provides fully reliable stream transmission , which means that prioritization of retransmissions will be beneficial in most cases , by filling in gaps and freeing up the flow control window . “ I 'm not so happy with currently here : Is this the best way to say this , might it be better to say this rather than even hinting that future QUIC might only be reliable : “ When a QUIC endpoint provides provides fully reliable stream transmission , prioritization of retransmissions will be beneficial in most cases , by filling in gaps and freeing up the flow control window . “ 3 ) I ’d prefer to see a ref here , since this something that the WG might later decide to work upon : “ Currently QUIC only supports failover cases [ Quic - Transport ] . ” 
 That mega paragraph has a bunch of good concepts , but it 's all run together into a single blob , which makes it a bit hard to follow .
Paragraph (version A):
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.  Further
downgrades to older TLS versions than used in QUIC, which is 1.3,
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):
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.  Further
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 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.
Currently, QUIC only provides fully reliable stream transmission,
which means that prioritization of retransmissions will be beneficial
in most cases, by 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):
An application that uses QUIC might communicate a cumulative stream
limit but 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.  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 client and an
unpredictable closing period might not fit application or operational
needs.  Applications using QUIC can be conservative with open stream
limits in order to reduce the commitment and indeterminism.  However,
being overly conservative with stream limits affects stream
concurrency.  Balancing these aspects can be specific to applications
and their deployments.  Instead of relying on stream limits to avoid
abrupt closure, an application-layer graceful close mechanism can be
used to communicate the intention to explicitly close the connection
at some future point.
Paragraph (version A):
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):
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):
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 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):
Currently QUIC 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):
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.  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):
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.