Draft: draft-ietf-quic-applicability

Commentary: Intended to , , 
 The draft says section 8 of quic - transport ; it 's section 13 . 
 It is odd that this section does n't mention QUIC 's robustness to NAT rebinding at all . While this wo n't work behind 4 - tuple load balancers , middlebox timers may be irrelevant depending on the conesequences of the timeout . 
 While TFO has some 0RTT - like properties , it does not fully replace it , not only because the SYN or option gets scrubbed , but also because you 're limited to one packet payload . Also , this ought to mention TLS stacks that offer replay protection . I would think a modern QUIC interface would offer a signal to separate  from 1RTT data , so that both senders and receivers can manage their application data appropriately . 
 will be 
 This is editorial , but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group . This will not age well , and the intro should be worded as if it were already a published RFC . The intro still talks about " HTTP/2 over QUIC " when it 's now HTTP/3 .
Paragraph (version A):
QUIC QUIC is a new transport protocol currently under development in
the IETF quic working group, focusing on support of semantics as
needed for HTTP/2 QUIC-HTTP such as stream-multiplexing to avoid
head-of-line blocking.  Based on current deployment practices, QUIC
is encapsulated in UDP.  The version of QUIC that is currently under
development will integrate TLS 1.3 TLS13 to encrypt all payload data
and most control information.
Paragraph (version A):
This document provides guidance for application developers that want
to use the QUIC protocol without implementing it on their own.  This
includes general guidance for application use of HTTP/2 over QUIC as
well as the use of other application layer protocols over QUIC.  For
specific guidance on how to integrate HTTP/2 with QUIC, see QUIC-
HTTP.
Paragraph (version B):
QUIC QUIC is a new transport protocol providing a number of advanced
features.  While initially designed for the HTTP use case, like most
transports it is intended for use with a much wider variety of
applications.  QUIC is encapsulated in UDP.  The version of QUIC that
is currently under development will integrate TLS 1.3 TLS13 to
encrypt all payload data and most control information.  HTTP
operating over QUIC is known as HTTP/3.
Paragraph (version B):
This document provides guidance for application developers that want
to use the QUIC protocol without implementing it on their own.  This
includes general guidance for applications operating over HTTP/3 or
directly over QUIC.  For specific guidance on how to integrate HTTP/3
with QUIC, see QUIC-HTTP.
Paragraph (version A):
These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the
fallback protocol.  For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the
application layer if needed.  Further, TCP without the TCP Fast Open
extension does not support 0-RTT session resumption.  TCP Fast Open
can be requested by the connection initiator but might no be
supported by the far end or could be blocked on the network path.
Note that there is some evidence of middleboxes blocking SYN data
even if TFO was successfully negotiated (see PaaschNanog).
Paragraph (version B):
These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the
fallback protocol.  For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the
application layer if needed.
Paragraph (version B):
Further, TCP implementations and network paths often do not support
the Fast Open option, which is analogous to 0-RTT session resumption.
Even if Fast Open successfully operates end-to-end, it is limited to
a single packet of payload, unlike QUIC 0-RTT.
Paragraph (version B):
Note that there is some evidence of middleboxes blocking SYN data
even if TFO was successfully negotiated (see PaaschNanog).
Paragraph (version A):
Data in the first flight sent by the client in a connection
established with 0-RTT MUST be idempotent (as specified in section
be framed, such that multiple reception of idempotent data is
recognized as such by the receiverApplications that cannot treat data
that may appear in a 0-RTT connection establishment as idempotent
MUST NOT use 0-RTT establishment.  For this reason the QUIC transport
SHOULD provide an interface for the application to indicate if 0-RTT
support is in general desired or a way to indicate whether data is
idempotent, whether PFS is a hard requirement for the application,
and/or whether rejected 0-RTT dgitata should be retransmitted or
withdrawn.
Paragraph (version B):
whether rejected 0-RTT data should be retransmitted or withdrawn.
Paragraph (version B):
Some TLS implementations may offer replay protection, which may
mitigate some of these issues.
Paragraph (version A):
Ignore it, if the application-layer protocol consists only of
interactions with no or very short idle periods.
Paragraph (version B):
By using a Connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout.  However, 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 may 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):
Ignore it, 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.