Draft: draft-ietf-quic-applicability

Commentary: Any endpoint that identifies connections using a Connection ID requires that Connection ID in packets , including ICMP Error packets . Hence , that endpoint will not only request the peer to send Connection IDs but will also include Connection IDs on outgoing packets ( in case they result in an ICMP Error packet ) . Such ICMP Error packets are required for PMTU discovery , among other things . Such Connection IDs will be sent even if the peer gave its permission to omit Connection IDs using Transport Parameter omitconnectionid . See for more .
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, and/or whether PFS is a hard requirement for the
application.
Paragraph (version B):
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 A):
Mapping of application data to streams is application-specific and
described for HTTP/s 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 different streams.  If there is a logical grouping of those data
chunks or messages, stream can be reused, or a new stream can be
opened for each chunk/message.  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):
Mapping of application data to streams is application-specific and
described for HTTP/s 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 different streams.  If there is a logical grouping of those data
chunks or messages, stream can be reused, or a new stream can be
opened for each chunk/message.  If one message is mapped on a single
stream, resetting the stream if the message is not needed anymore can
be used to emulate partialreliability 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):
QUIC supports connection migration.  Even if lower-layer addresses
(usually the 4-tuple of IP addresses and ports) changes, QUIC packets
can still be associated with an existing connection based on the
Connection ID (see also section connid) in the QUIC header, if
present.  This supports cases where address information changes due
to e.g.  NAT rebinding or change of the local interface.  Currently
QUIC only supports failover cases.  Only one "path" can be used at a
time, and as soon as the new path is validated all traffic will be
switched over to the next path.
Paragraph (version B):
Note that the Connection ID in the short header may be omitted.  This
is a per-connection configuration option; if the Connection ID is not
present, then the peer omitting the connection ID will use the same
local address for the lifetime of the connection.