Draft: draft-ietf-quic-applicability

Commentary: ( thanks and ( thanks as well ( thanks 
 That 's a lot to work through . Consider breaking this up a little . I see a few things : is aided by using more streams where ordering is not necessary or where concurrency is desirable . the opposite end of things , streams provide ordering where ordering is critical . a message per stream allows messages to be cancelled . on concurrency need to be accounted for . 
 The app ID seems to have various places where the text needs a wee polish . I 'm sure this is not all , but there are quite a lot of NiTS here . It could be that some of these may be hints at topics that should become issues to be discussed , although I suspect that most ( or all ) are simply requests for editorial changes to improve clarity . NiT : Timeliness of the “ evidence ” . I agree with what is said , but I think we should be more cautious about current evidence we place in the RFC . “ While there is no evidence of widespread , systematic disadvantage ” can we say “ Current measurements show no evidence … ” or something that captures this . Nit : “ Robust to rebinding ” might be better as “ robust to NAT rebinding ” . Nit : “ can use 0 - RTT session resumption , ” , I ’d suggest a cross reference to section here in the QUIC  . Nit : “ connections may not be robust ” , this combination of may can often be misinterpreted by different usages of English , “ might not ” is likely unambiguous . Nit : “ In particular , firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client . ” I think this is about what I would call “ established ” state tracking - mixed plurals , could this be something a little like : “ 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 . ” Nit : “ Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some ” - could be another place to refer to RFC8085 o / andr QUIC  section . Nit : “ This of course only applies “ - is it possible to avoid “ of course ” here ? - or if needed , then please do explain more . Maybe “ This approach is valid only when … ” or something similar ? NiT : “ Using resumption in this way also assumes that the protocol does not accumulate any non - persistent state in association with a connection . ” - I ’m not sure what the assumption is here ? Is n’t this a requirement on the application ? Nit : “ Due to encoding limitations on “ . This would read easier if it did not start with “ due to ” . Nit : “ exceptional handling “ - is this “ exception handling ” - or is this something else then maybe this needs discussion ? Nit : “ If a QUIC receiver has maximum allowed concurrent streams open ” - I think this should be : “ If a QUIC receiver opened has the maximum allowed concurrent streams “ Nit : “ valuable to expose maximum number of allowed ” insert “ the ” ? Nit : for the avoidance of doubt : “ will try to maximally pack packets ” - please add “ QUIC ” before packets . Nit : “ may be valuable to indicate to QUIC that all data should be send out immediately ” … I agree , but think this means the QUIC sending stack , because I do n’t know the QUIC transport protocol mechanism to do this . Nit : Sect 7 : “ If a lower - layer address changes ” - what is this ? an IP address ? something more ? and “ can still associate packets with an existing connection ” - I ’d prefer “ transport ” or “ endpoint ” before connection here , because there are connections at other lower layers , which this is n’t about . Nit : “ Path validation means that the other endpoint in required ” - /other / remote/ ? ? /in / is/ Nit : “ congestion control will also be reset on path migration ” is /on/ better /after/ - please refer to the relevant section in the spec . Nit : “ Probing packets , which can not carry application data , can be sent on multiple paths at once . ” . I think should be “ QUIC packet probes ” and would be much better with a cross reference to the sections within the spec . Nit : “ This frames has two sets of types : one ” /This / These/ and /has / have/. Nit : “ Aside from the destination connection ID field of the first packets sent by clients , the connection ID can be zero length . “ . “ Aside from ” reads a little odd , but the intent seems correct , can you reword ? Nit : “ The most efficient mitigation for these attacks is operational , either by using a load balancing architecture ” Agree , but “ operational ” seems like the sentence is odd , is this appropriate operational practice , or design or something else ? 
 Duplicate reference : RFC7301 , mentioned in ' RFC7301 ' , was also mentioned in ' ALPN ' . 
 Unused Reference : ' I - D.nottingham - httpbis - retry ' is defined on line 861 , but no explicit reference was found in the text .
Paragraph (version A):
While there is no evidence of widespread, systematic disadvantage of
UDP traffic compared to TCP in the Internet Edeline16, somewhere
between three Trammell16 and five Swett16 percent of networks simply
block UDP traffic.  All applications running on top of QUIC must
therefore 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 1.3 over TCP.
Paragraph (version A):
An application that implements fallback needs to consider the
security consequences.  A fallback to TCP and TLS 1.3 exposes control
information to modification and manipulation in the network.  Further
downgrades to older TLS versions might result in significantly weaker
cryptographic protection.  For example, the results of protocol
negotiation ALPN only have confidentiality protection if TLS 1.3 is
used.
Paragraph (version B):
While recent measurements have shown no evidence of widespread,
systematic disadvantage of UDP traffic compared to TCP in the
Internet Edeline16, somewhere between three Trammell16 and five
Swett16 percent of networks simply block UDP traffic.  All
applications running on top of QUIC must therefore 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 1.3 over TCP.
Paragraph (version B):
An application that implements fallback needs to consider the
security consequences.  A fallback to TCP and TLS 1.3 exposes control
information to modification and manipulation in the network.  Further
downgrades to older TLS versions 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):
Some QUIC connections may not be robust to 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, firewalls will often not admit server traffic
for which it has not kept state for corresponding packets from the
client.
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 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 A):
Sending PING frames more frequently than every 30 seconds over long
idle periods may result in excessive unproductive traffic in some
situations, and to unacceptable power usage for power-constrained
(mobile) devices.  Additionally, time-outs shorter than 30 seconds
can make it harder to handle transient network interruptions, such as
VM migration or coverage loss during mobilty.
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 to unacceptable power usage for power-constrained
(mobile) devices.  Additionally, time-outs shorter than 30 seconds
can make it harder to handle transient network interruptions, such as
VM migration or coverage loss during mobilty.  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 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.  This
of course only applies in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is
idempotent.  Using resumption in this way also assumes that the
protocol does not accumulate any non-persistent state in association
with a connection.  State bound to a connection cannot reliably be
transferred to a resumed connection.
Paragraph (version B):
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 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.  This
approach is only valid in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is
idempotent.  It is also not applicable when the application binds
external state to the connection, as this state cannot reliably be
transferred to a resumed connection.
Paragraph (version A):
Due to encoding limitations on stream offsets and connection flow
control limits, both streams and connections can carry a maximum of
2^62-1 bytes in each direction.  In the presently unlikely event that
this limit is reached by an application, a new connection would need
to be established.
Paragraph (version B):
Streams and connections can each carry a maximum of 2^62-1 bytes in
each direction, due to encoding limitations on stream offsets and
connection flow control limits.  In the presently unlikely event that
this limit is reached by an application, a new connection would need
to be established.
Paragraph (version A):
Mapping of application data to streams is application-specific and
described for HTTP/3 in QUIC-HTTP.  In general, 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.  If the application requires certain data to
be received in order, that data should be sent on the same stream.
If there is a logical grouping of data chunks or messages, streams
can be reused, or a new stream can be opened for each chunk/message.
If one message is mapped to a single stream, resetting the stream to
expire an unacknowledged message can be used to emulate partial
reliability on a message basis.  If a QUIC receiver has maximum
allowed concurrent streams open and the sender on the other end
indicates that more streams are needed, it doesn't automatically lead
to an increase of the maximum number of streams by the receiver.
Therefore it can be valuable to expose maximum number of allowed,
currently open and currently used streams to the application to make
the mapping of data to streams dependent on this information.
Paragraph (version B):
A single stream provides ordering.  If the application requires
certain data to be received in order, that data should be sent on
the same stream.
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
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):
If a QUIC receiver has opened the maximum allowed concurrent streams,
and the sender indicates that more streams are needed, it doesn't
automatically lead to an increase of the maximum number of streams by
the receiver.  Therefore it can be valuable to expose the maximum
number of allowed, currently open, and currently used streams to the
application to make the mapping of data to streams dependent on this
information.
Paragraph (version A):
By default, many QUIC implementations will try to maximally pack
packets with one or more stream data frames 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 B):
By default, many implementations will try to maximally pack QUIC
packets with one or more stream data frames 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):
QUIC supports connection migration by the client.  If a lower-layer
address changes, a QUIC endpoint can still associate packets with an
existing connection using the Destination connection ID field (see
also connid) in the QUIC header, unless a zero-length value is used.
This supports cases where address information changes, such as NAT
rebinding, intentional change of the local interface, or based on an
indication in the handshake of the server for a preferred address to
be used.
Paragraph (version B):
QUIC supports connection migration by the client.  If an 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, unless a zero-length value is used.
This supports cases where address information changes, such as NAT
rebinding, intentional change of the local interface, or based on an
indication in the handshake of the server for a preferred address to
be used.
Paragraph (version A):
Currently QUIC only supports failover cases.  Only one "path" can be
used at a time, and only when the new path is validated all traffic
can be switched over to that new path.  Path validation means that
the other endpoint in required to validate the new path before use in
order to avoid address spoofing attacks.  Path validation takes at
least one RTT and congestion control will also be reset on path
migration.  Therefore migration usually has a performance impact.
Paragraph (version A):
Probing packets, which cannot carry application data, can be sent on
multiple paths at once.  Probing packets can be used to perform
address validation, measure path characteristics as input for the
switching decision, or prime the congestion controller in preparation
for switching to the new path.
Paragraph (version B):
Currently QUIC only supports failover cases.  Only one "path" can be
used at a time, and only when the new path is validated all traffic
can be switched over to that new path.  Path validation means that
the remote endpoint is required to validate the new path before use
in order 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):
QUIC probing packets, which cannot carry application data, can be
sent on multiple paths at once.  Probing packets can be used to
perform address validation, measure path characteristics as input for
the switching decision, or prime the congestion controller in
preparation for switching to the new path.
Paragraph (version A):
An immediate close will emit an CONNECTION_CLOSE frame.  This frames
has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the
application.  An application using QUIC can define application-
specific error codes (see, for example, QUIC-HTTP, Section 8.1).
Paragraph (version B):
An immediate close will emit an CONNECTION_CLOSE frame.  This frame
has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the
application.  An application using QUIC can define application-
specific error codes (see, for example, QUIC-HTTP, Section 8.1).
Paragraph (version A):
Aside from the destination connection ID field of the first packets
sent by clients, the connection ID can be zero length.  This is a
choice that is made by each endpoint individually.
Paragraph (version B):
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 A):
The most efficient mitigation for these attacks is operational,
either by using a load balancing architecture that loads more flows
onto a single server-side address, by coordinating the timing of
migrations to attempt to increase the number of simultaneous
migrations at a given time, or through other means.
Paragraph (version B):
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 to attempt to increase the
number of simultaneous migrations at a given time, or through other
means.