Draft: draft-ietf-quic-transport

Commentary: These are the items from my transport read - through that did n't seem to warrant separate issues . Feel free to pick and choose , of course . 
 In Transport , we say : However , in TLS we have a section named " Packet Protection " ( Section 5 ) with subsections describing how to protect Initial ( 5.2 ) and Retry ( 5.8 ) packets which talk about Initial , at least , as using packet protection . I think it would be clearer to describe the lack of security properties that this limited form of protection provides , rather than say they 're not protected at all . Alternatively , we could rework the language in TLS , but that feels like a bigger terminology change . 
 ekr suggested that we limit the use of " integrity protection " ( and I presume " confidentiality protection " ) to those cases where the protection is real , and not based on fixed keys or trivially - acquired keys . I think that might be the best answer here , even if that takes more effort to get right . 
 : That sounds good like a good way forward . 
 otherwise be non - ack - eliciting , to avoid an infinite feedback loop of acknowledgements . This text seems weird . Suppose I have an implementation which tries to send out data packets on a specific clock ( e.g. , one per second ) . This is n't totally unrealistic for media . Now suppose my ACK delay timer fires and I want to send an ACK . This text would prohibit my from sending the data packet early to save packets . Surely that 's not what 's intended . 
 I think this is in reaction to the practice of bundling a ping with an ack to trigger an ack of ack . Yes , if both peers bundle a ping with every ack you would get an infinite ping pong . But you would have to be crazy to do that . Plus , bundling a ping with every Nth ack for N 1 is actually a good way to trigger ack of ack . 
 This has always been hard to capture . In short , you ca n't only send ack - eliciting packets to acknowledge . 
 I think part of the issue is the double negation in " MUST NOT send packets that are exclusively ack - eliciting " , which makes it kinda hard to grasp by non - natives . Something like " end points MUST NOT force all their packets to elicit an acknowledgement " would be easier . 
 So the above or below is OK ? 
 No , I do n't think that works . You are speaking of generic ack - eliciting packets , or not , but the problem is much better described and understood if you make a specific statement about ack , ack of ack , and ack loops . You may want to generalize after that to other non ack eliciting frames , but the only such in the main spec are path challenges , so that 's not a very high priority . 
 It 's not really the bundling that 's the issue , but the idea that one should n't send extra ack - eliciting frames when sending an ack . This is n't shorter , but how about : " A receiver MUST NOT generate and bundle an ack - eliciting frame with packets that would otherwise be non - ack - eliciting , to avoid an infinite feedback loop of acknowledgements . " 
 I feel like this has the same problem as before . I would suggest that part of the issue here is that we are trying to make something really crisp . Looking at the rest of the graf , where we actually endorse this practice , I suggest we do : A receiver that sends only non - ack - eliciting packets , such as ACK frames , might not receive an acknowledgement for a long period of time . This could cause the receiver to maintain state for a large number of ACK frames for a long period of time , and ACK frames it sends could be unnecessarily large . In such a case , a receiver could bundle a PING or other small ack - eliciting frame to elicit an ACK from the peer . Caution : If receivers add additional ack - eliciting frames to every ACK , this would create an infinite feedback loop of acknowledgements . Therefore , receivers SHOULD only do this occasionally , such as once per round trip . 
 Alomost there . I like EKR 's text , except for the once per round trip part . Do n't do that , because it leads to a loop of round trip period . 
 That 1 - RTT thing came from the previous text , so I was just retaining it . I have no personal opinion . 
 I also touched this text in ; there was previously an " all " that dramatically changes the meaning of the restriction that got dropped somewhere , so I put it back . The point is that it 's okay to toss a PING in to your ACK - only packets once in a while so you can clear out old ACK ranges , but you should n't do that every time you send an ACK . 
 For some reason , this text is already in the draft . I note that concern about 1 - RTT looping remains . I 'm going to close this and let those who want to deal with the looping do so ( that smells a little design - y , unfortunately ) . 
 Doing this in chunks . I'm happy with this .
Paragraph (version A):
The endpoint initiating a QUIC connection.
Paragraph (version A):
The endpoint accepting incoming QUIC connections.
Paragraph (version A):
An opaque identifier that is used to identify a QUIC connection at
an endpoint.  Each endpoint sets a value for its peer to include
in packets sent towards the endpoint.
Paragraph (version B):
The endpoint that initiates a QUIC connection.
Paragraph (version B):
The endpoint that accepts a QUIC connection.
Paragraph (version B):
When used without qualification, the tuple of IP version, IP
address, and UDP port number that represents one end of a network
path.
Paragraph (version B):
An opaque identifier that is used to identify a QUIC connection at
an endpoint.  Each endpoint selects one or more Connection IDs for
its peer to include in packets sent towards the endpoint.
Paragraph (version B):
Packet and frame diagrams in this document use a custom format.  The
purpose of this format is to summarize, not define, protocol
elements.  Prose defines the complete semantics and details of
structures.
Paragraph (version A):
The least significant two bits from a stream ID therefore identify a
stream as one of four types, as summarized in stream-id-types.
Paragraph (version A):
Within each type, streams are created with numerically increasing
stream IDs.  A stream ID that is used out of order results in all
streams of that type with lower-numbered stream IDs also being
opened.
Paragraph (version A):
The first bidirectional stream opened by the client has a stream ID
of 0.
Paragraph (version B):
The two least significant bits from a stream ID therefore identify a
stream as one of four types, as summarized in stream-id-types.
Paragraph (version B):
reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (frame-reset-stream) if the stream was not already in a
terminal state.
Paragraph (version B):
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that
stream.  For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part.  The initial state for the
receiving part of a stream is "Recv".
Paragraph (version B):
It is possible that all stream data has already been received when a
RESET_STREAM is received (that is, in the "Data Recvd" state).
Similarly, it is possible for remaining stream data to arrive after
receiving a RESET_STREAM frame (the "Reset Recvd" state).  An
implementation is free to manage this situation as it chooses.
Paragraph (version B):
On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that
stream.
Paragraph (version B):
An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state
(stream-states).  The receiver MUST use the final size of the stream
to account for all bytes sent on the stream in its connection level
flow controller.
Paragraph (version A):
An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (frame-streams-blocked).
This signal is considered useful for debugging.  An endpoint MUST NOT
wait to receive this signal before advertising additional credit,
since doing so will mean that the peer will be blocked for at least
an entire round trip, and potentially for longer if the peer chooses
to not send STREAMS_BLOCKED frames.
Paragraph (version A):
QUIC's connection establishment combines version negotiation with the
cryptographic and transport handshakes to reduce connection
establishment latency, as described in handshake.  Once established,
a connection may migrate to a different IP or port at either endpoint
as described in migration.  Finally, a connection may be terminated
by either endpoint, as described in termination.
Paragraph (version A):
A Version Negotiation (packet-version) packet echoes the connection
IDs selected by the client, both to ensure correct routing toward the
client and to allow the client to validate that the packet is in
response to an Initial packet.
Paragraph (version B):
A Version Negotiation (packet-version) packet echoes the connection
IDs selected by the client, both to ensure correct routing toward the
client and to demonstrate that the packet is in response to a packet
sent by the client.
Paragraph (version A):
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (frame-new-connection-id).  The sequence
number on each newly-issued connection ID MUST increase by 1.  The
connection ID randomly selected by the client in the Initial packet
and any connection ID provided by a Retry packet are not assigned
sequence numbers unless a server opts to retain them as its initial
connection ID.
Paragraph (version B):
An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on
migration, as the peer will be unable to respond if the pool is
exhausted.
Paragraph (version B):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port.  These packets
are processed using the selected connection; otherwise, the server
continues below.
Paragraph (version B):
be informed when Early Data has been accepted or rejected by a
server.
Paragraph (version A):
QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency.  QUIC uses the CRYPTO
frame frame-crypto to transmit the cryptographic handshake.  Version
0x00000001 of QUIC uses TLS as described in QUIC-TLS; a different
QUIC version number could indicate that a different cryptographic
handshake protocol is in use.
Paragraph (version A):
every connection produces distinct and unrelated keys,
Paragraph (version B):
A client MUST change the Destination Connection ID it uses for
sending packets in response to only the first received Initial or
Retry packet.  A server MUST set the Destination Connection ID it
uses for sending packets based on the first received Initial packet.
Any further changes to the Destination Connection ID are only
permitted if the values are taken from NEW_CONNECTION_ID frames; if
subsequent Initial packets include a different Source Connection ID,
they MUST be discarded.  This avoids unpredictable outcomes that
might otherwise result from stateless processing of multiple Initial
packets with different Source Connection IDs.
Paragraph (version B):
Each endpoint includes the value of the Source Connection ID field
from the first Initial packet it sent in the
initial_source_connection_id transport parameter; see transport-
parameter-definitions.  A server includes the Destination Connection
ID field from the first Initial packet it received from the client in
the original_destination_connection_id transport parameter; if the
server sent a Retry packet, this refers to the first Initial packet
received before sending the Retry packet.  If it sends a Retry
packet, a server also includes the Source Connection ID field from
the Retry packet in the retry_source_connection_id transport
parameter.
Paragraph (version B):
QUIC includes the encoded transport parameters in the cryptographic
handshake.  Once the handshake completes, the transport parameters
declared by the peer are available.  Each endpoint validates the
values provided by its peer.
Paragraph (version B):
The server uses the NEW_TOKEN frame (frame-new-token) to provide the
client with an address validation token that can be used to validate
future connections.  In a future connection, the client includes this
token in Initial packets to provide address validation.  The client
MUST include the token in all Initial packets it sends, unless a
Retry replaces the token with a newer one.  The client MUST NOT use
the token provided in a Retry for future connections.  Servers MAY
discard any Initial packet that does not carry the expected token.
Paragraph (version A):
Path validation is used during connection migration (see migration
and preferred-address) by the migrating endpoint to verify
reachability of a peer from a new local address.  In path validation,
endpoints test reachability between a specific local address and a
specific peer address, where an address is the two-tuple of IP
address and port.
Paragraph (version A):
An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames.  In particular, an
endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU
discovery, or an endpoint may bundle a PATH_RESPONSE with its own
PATH_CHALLENGE.
Paragraph (version B):
An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames.  In particular, an
endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU
discovery, or an endpoint may include a PATH_RESPONSE with its own
PATH_CHALLENGE.
Paragraph (version A):
An endpoint MAY probe for peer reachability from a new local address
using path validation migrate-validate prior to migrating the
connection to the new local address.  Failure of path validation
simply means that the new path is not usable for this connection.
Failure to validate a path does not cause the connection to end
unless there are no valid alternative paths available.
Paragraph (version B):
An endpoint MAY probe for peer reachability from a new local address
using path validation (migrate-validate) prior to migrating the
connection to the new local address.  Failure of path validation
simply means that the new path is not usable for this connection.
Failure to validate a path does not cause the connection to end
unless there are no valid alternative paths available.
Paragraph (version A):
Receiving a PATH_CHALLENGE frame from a peer indicates that the peer
is probing for reachability on a path.  An endpoint sends a
PATH_RESPONSE in response as per migrate-validate.
Paragraph (version B):
Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address.  Note that
since acknowledgments may be received on any path, return
reachability on the new path is not established.  No method is
provided to establish return reachability, as endpoints independently
determine reachability on each direction of a path.  To establish
reachability on the new path, an endpoint MAY concurrently initiate
path validation (migrate-validate) on the new path.  An endpoint MAY
defer path validation until after a peer sends the next non-probing
frame to its new address.
Paragraph (version A):
If an endpoint skips validation of a peer address as described in
migration-response, it does not need to limit its sending rate.
Paragraph (version B):
If an endpoint skips validation of a peer address as described above,
it does not need to limit its sending rate.
Paragraph (version B):
Using a stable connection ID on multiple network paths would allow a
passive observer to correlate activity between those paths.  An
endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses,
as discussed in connection-id.  For this to be effective, endpoints
need to ensure that connection IDs they provide cannot be linked by
any other entity.
Paragraph (version B):
An endpoint SHOULD NOT initiate migration with a peer that has
requested a zero-length connection ID, because traffic over the new
path might be trivially linkable to traffic over the old one.  If the
server is able to associate packets with a zero-length connection ID
to the right connection, it means that the server is using other
information to demultiplex packets.  For example, a server might
provide a unique address to every client, for instance using HTTP
alternative services ALTSVC.  Information that might allow correct
routing of packets across multiple network paths will also allow
activity on those paths to be linked by entities other than the peer.
Paragraph (version A):
Migrating a connection to a new server address mid-connection is left
for future work.  If a client receives packets from a new server
address not indicated by the preferred_address transport parameter,
the client SHOULD discard these packets.
Paragraph (version B):
A server might receive a packet addressed to its preferred IP address
at any time after it accepts a connection.  If this packet contains a
PATH_CHALLENGE frame, the server sends a packet containing a
PATH_RESPONSE frame as per migrate-validate.  The server MUST send
non-probing packets from its original address until it receives a
non-probing packet from the client at its preferred address and until
the server has validated the new path.
Paragraph (version B):
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see termination.  However, state in middleboxes
might time out earlier than that.  Though REQ-5 in RFC4787 recommends
a 2 minute timeout interval, experience shows that sending packets
every 30 seconds is necessary to prevent the majority of middleboxes
from losing state for UDP flows GATEWAY.
Paragraph (version B):
Allowing retransmission of a closing packet is an exception to the
requirement that a new packet number be used for each packet in
packet-numbers.  Sending new packet numbers is primarily of
advantage to loss recovery and congestion control, which are not
expected to be relevant for a closed connection.  Retransmitting
the final packet requires less state.
Paragraph (version B):
A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured that the server has accepted 0-RTT and so sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
Paragraph (version B):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of bytes following it are set to values that
SHOULD be indistinguishable from random.  The last 16 bytes of the
datagram contain a Stateless Reset Token.
Paragraph (version A):
The stateless reset token MUST be difficult to guess.  In order to
create a Stateless Reset Token, an endpoint could randomly generate
RFC4086 a secret for every connection that it creates.  However, this
presents a coordination problem when there are multiple instances in
a cluster or a storage problem for an endpoint that might lose state.
Stateless reset specifically exists to handle the case where state is
lost, so this approach is suboptimal.
Paragraph (version B):
Application-specific protocol errors are signaled using the
CONNECTION_CLOSE frame with a frame type of 0x1d.  Errors that are
specific to the transport, including all those described in this
document, are carried in the CONNECTION_CLOSE frame with a frame type
of 0x1c.
Paragraph (version B):
Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by
maintaining a minimum packet number below which all packets are
immediately dropped.  Any minimum needs to account for large
variations in round trip time, which includes the possibility that a
peer might probe network paths with much larger round trip times; see
migration.
Paragraph (version B):
The Frame Type field uses a variable-length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  For frame types defined in this document, this
means a single-byte encoding, even though it is possible to encode
these values as a two-, four- or eight-byte variable-length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01.  This rule applies to
all current and future QUIC frame types.  An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
A sender sends one or more frames in a QUIC packet; see frames.
Paragraph (version A):
When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently.  Doing so
helps with timely loss detection at the peer.
Paragraph (version B):
When sending a packet for any reason, an endpoint SHOULD attempt to
include an ACK frame if one has not been sent recently.  Doing so
helps with timely loss detection at the peer.
Paragraph (version A):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames.  An endpoint SHOULD
bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames.
Paragraph (version B):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to include an ACK frame with outgoing frames.
Paragraph (version B):
When an ACK frame is sent, one or more ranges of acknowledged packets
are included.  Including acknowledgements for older packets reduces
the chance of spurious retransmissions caused by losing previously
sent ACK frames, at the cost of larger ACK frames.
Paragraph (version B):
In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering.  In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost.  In this case, the loss recovery
algorithm could cause spurious retransmissions, but the sender will
continue making forward progress.
Paragraph (version B):
A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of
time.  This could cause the receiver to maintain state for a large
number of ACK frames for a long period of time, and ACK frames it
sends could be unnecessarily large.  In such a case, a receiver could
send a PING or other small ack-eliciting frame occasionally, such as
once per round trip, to elicit an ACK from the peer.
Paragraph (version B):
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgements.
Paragraph (version B):
ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being acknowledged; see packet-protected.
For instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys.
Paragraph (version B):
ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in
sending-acknowledgements.  Delaying the transmission of packets
containing ACK frames or resending old ACK frames can cause the
peer to generate an inflated RTT sample or unnecessarily disable
ECN.
Paragraph (version A):
The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit.  Care is
necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent.
Paragraph (version B):
The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit.  Care is
necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent; see fc-credit.
Paragraph (version A):
Other versions of QUIC might have different properties to this
version.  The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in QUIC-INVARIANTS.
Paragraph (version B):
Other versions of QUIC might have different properties from this
version.  The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in QUIC-INVARIANTS.
Paragraph (version B):
The Destination Connection ID field follows the Destination
Connection ID Length field, which indicates the length of this
field.  negotiating-connection-ids describes the use of this field
in more detail.
Paragraph (version B):
The Source Connection ID field follows the Source Connection ID
Length field, which indicates the length of this field.
negotiating-connection-ids describes the use of this field in more
detail.
Paragraph (version B):
The header form bit, Destination and Source Connection ID lengths,
Destination and Source Connection ID fields, and Version fields of a
long header packet are version-independent.  The other fields in the
first byte are version-specific.  See QUIC-INVARIANTS for details on
how packets from different versions of QUIC are interpreted.
Paragraph (version B):
The packet number field is 1 to 4 bytes long.  The packet number
is protected using header protection; see Section 5.4 of QUIC-TLS.
The length of the packet number field is encoded in the Packet
Number Length bits of byte 0; see above.
Paragraph (version A):
A Version Negotiation packet cannot be explicitly acknowledged in an
ACK frame by a client.  Receiving another Initial packet implicitly
acknowledges a Version Negotiation packet.
Paragraph (version B):
A Version Negotiation packet is not acknowledged.  It is only sent in
response to a packet that indicates an unsupported version; see
server-pkt-handling.
Paragraph (version B):
The value of the token that was previously provided in a Retry
packet or NEW_TOKEN frame; see validate-handshake.
Paragraph (version B):
A server SHOULD treat a violation of remembered limits (zerortt-
parameters) as a connection error of an appropriate type (for
instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
Paragraph (version B):
The preferred_address transport parameter contains an address and
port for both IP version 4 and 6.  The four-byte IPv4 Address
field is followed by the associated two-byte IPv4 Port field.
This is followed by a 16-byte IPv6 Address field and two-byte IPv6
Port field.  After address and port pairs, a Connection ID Length
field describes the length of the following Connection ID field.
Finally, a 16-byte Stateless Reset Token field includes the
stateless reset token associated with the connection ID.  The
format of this transport parameter is shown in fig-preferred-
address.
Paragraph (version B):
The Connection ID field and the Stateless Reset Token field
contain an alternative connection ID that has a sequence number of
1; see issue-cid.  Having these values sent alongside the
preferred address ensures that there will be at least one unused
active connection ID when the client initiates migration to the
preferred address.
Paragraph (version A):
Endpoints can use PING frames (type=0x01) to verify that their peers
are still alive or to check reachability to the peer.  As shown in
ping-format a PING frame contains no content.
Paragraph (version B):
When present, there are 3 ECN counts, as shown in ecn-count-format.
Paragraph (version B):
A variable-length integer indicating the final size of the stream
by the RESET_STREAM sender, in unit of bytes; see final-size.
Paragraph (version B):
All data sent in STREAM frames counts toward this limit.  The sum of
the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it
has sent.  This includes violations of remembered limits in Early
Data; see zerortt-parameters.
Paragraph (version B):
The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver.  An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the
affected stream.  This includes violations of remembered limits in
Early Data; see zerortt-parameters.
Paragraph (version A):
An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer.  For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15.  An endpoint MUST terminate a connection
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
permitted.
Paragraph (version B):
An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer.  For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15.  An endpoint MUST terminate a connection
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
permitted.  This includes violations of remembered limits in Early
Data; see zerortt-parameters.
Paragraph (version B):
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data, but is unable to do so due to connection-level flow
control; see flow-control.  DATA_BLOCKED frames can be used as input
to tuning of flow control algorithms; see fc-credit.
Paragraph (version A):
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to due to stream-level flow
control.  This frame is analogous to DATA_BLOCKED (frame-data-
blocked).
Paragraph (version B):
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to do so due to stream-level flow
control.  This frame is analogous to DATA_BLOCKED (frame-data-
blocked).
Paragraph (version A):
A variable-length integer indicating the stream which is flow
control blocked.
Paragraph (version B):
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer; see frame-max-streams.  A
STREAMS_BLOCKED frame of type 0x16 is used to indicate reaching the
bidirectional stream limit, and a STREAMS_BLOCKED frame of type 0x17
is used to indicate reaching the unidirectional stream limit.
Paragraph (version A):
The sequence number assigned to the connection ID by the sender.
See issue-cid.
Paragraph (version B):
The sequence number assigned to the connection ID by the sender,
encoded as a variable-length integer; see issue-cid.
Paragraph (version A):
Transmission errors, timeouts and retransmissions might cause the
same NEW_CONNECTION_ID frame to be received multiple times.  Receipt
of the same frame multiple times MUST NOT be treated as a connection
error.  A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to identify new connection IDs from old ones.
Paragraph (version B):
Transmission errors, timeouts and retransmissions might cause the
same NEW_CONNECTION_ID frame to be received multiple times.  Receipt
of the same frame multiple times MUST NOT be treated as a connection
error.  A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to handle receiving the same
NEW_CONNECTION_ID frame multiple times.
Paragraph (version A):
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is
sufficient to ensure that it is easier to receive the packet than it
is to guess the value correctly.
Paragraph (version B):
Including 64 bits of entropy in a PATH_CHALLENGE frame ensures that
it is easier to receive the packet than it is to guess the value
correctly.
Paragraph (version A):
A variable length integer error code which indicates the reason
for closing this connection.  A CONNECTION_CLOSE frame of type
0x1c uses codes from the space defined in error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version A):
A human-readable explanation for why the connection was closed.
This can be zero length if the sender chooses to not give details
beyond the Error Code.  This SHOULD be a UTF-8 encoded string
RFC3629.
Paragraph (version A):
An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame.  An
endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport
parameter.
Paragraph (version B):
An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame.  An
endpoint can use a transport parameter to signal its willingness to
receive extension frame types.  One transport parameter can indicate
support for one or more extension frame types.
Paragraph (version A):
The attacks commonly known as Slowloris SLOWLORIS try to keep many
connections to the target endpoint open and hold them open as long as
possible.  These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being
closed for inactivity.  This might involve sending small amounts of
data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss
rate.
Paragraph (version B):
The attacks commonly known as Slowloris (SLOWLORIS) try to keep many
connections to the target endpoint open and hold them open as long as
possible.  These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being
closed for inactivity.  This might involve sending small amounts of
data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss
rate.
Paragraph (version A):
An adversarial endpoint can open lots of streams, exhausting state on
an endpoint.  The adversarial endpoint could repeat the process on a
large number of connections, in a manner similar to SYN flooding
attacks in TCP.
Paragraph (version B):
An adversarial endpoint can open a large number of streams,
exhausting state on an endpoint.  The adversarial endpoint could
repeat the process on a large number of connections, in a manner
similar to SYN flooding attacks in TCP.
Paragraph (version A):
If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset.  To defend against
this style of denial service, endpoints that share a static key for
stateless reset (see reset-token) MUST be arranged so that packets
with a given connection ID always arrive at an instance that has
connection state, unless that connection is no longer active.
Paragraph (version A):
In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could happen
while an active instance retains connection state; even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance in the packet being routed to the
correct instance, it is better to send a stateless reset than wait
for connections to time out.  However, this is acceptable only if the
routing cannot be influenced by an attacker.
Paragraph (version B):
If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset.  To defend against
this style of denial of service, endpoints that share a static key
for stateless reset (see reset-token) MUST be arranged so that
packets with a given connection ID always arrive at an instance that
has connection state, unless that connection is no longer active.
Paragraph (version B):
More generally, servers MUST NOT generate a stateless reset if a
connection with the corresponding connection ID could be active on
any endpoint using the same static key.
Paragraph (version B):
In the case of a cluster that uses dynamic load balancing, it is
possible that a change in load balancer configuration could occur
while an active instance retains connection state.  Even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance of the packet being routed to the
correct instance, it is better to send a stateless reset than wait
for the connection to time out.  However, this is acceptable only if
the routing cannot be influenced by an attacker.
Paragraph (version B):
Address validation (address-validation) is used to verify that an
entity that claims a given address is able to receive packets at that
address.  Address validation limits amplification attack targets to
addresses for which an attacker can observe packets.
Paragraph (version B):
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange.  Further, parameter negotiation is folded into the TLS
transcript and thus provides the same integrity guarantees as
ordinary TLS negotiation.  An attacker can observe the client's
transport parameters (as long as it knows the version-specific salt)
but cannot observe the server's transport parameters and cannot
influence parameter negotiation.
Paragraph (version B):
Permanent registrations in QUIC registries use the Specification
Required policy (RFC8126), unless otherwise specified.  The
designated expert(s) verify that a specification exists and is
readily accessible.  Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).  The creation of a registry MAY specify
additional constraints on permanent registrations.
Paragraph (version B):
The "QUIC Transport Parameters" registry governs a 62-bit space.
This registry follows the registration policy from iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy (RFC8126).
Paragraph (version B):
In addition to the advice in iana-policy, specifications for new
permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of
frame.  An accompanying transport parameter registration is expected
for most registrations; see iana-transport-parameters.
Specifications for permanent registrations also need to describe the
format and assigned semantics of any fields in the frame.