Draft: draft-ietf-quic-transport

Commentary: These are mostly mechanical , but there are a few that likely need some review . 
 The following NiTs are from a careful read of QUIC transport . I expect all are editorial and that the editors may be able to perform suitable changes to improve reading . to which /deciding which streams to dedicate resources to / deciding the stream to which resources should be dedicated/ that /operations which an application MUST / operations that an application MUST/ avoid sides … causes .. /because the opening of either send or receive sides causes the stream to open in both directions./because the opening of either the send or receive side causes the stream to be open in both directions./ add /a/ /The sending part of stream / The sending part of a stream/ Other sentences include /frame/ /is created when the first STREAM , STREAMDATABLOCKED , or RESETSTREAM is received for that stream./is created when the first STREAM , STREAMDATABLOCKED , or RESETSTREAM frame is received for that stream./ This did not parse for me , is this better ? /A sender  NOT send STREAM or STREAMDATABLOCKED after sending a RESETSTREAM ; that is , in the terminal states and in the " Reset Sent " state . /A sender  NOT send a STREAM or STREAMDATABLOCKED frame that is in the terminal states and in the " Reset Sent " state ( after sending a RESETSTREAM frame)./is this /can / MAY/ - because MUST is used for illegal frames ? /A receiver can send STOPSENDING in any state / include word frame to be consistent with other text ? /STREAM frames received after sending  are / STREAM frames received after sending a STOPSENDING frame are/ include word frame to be consistent with other text ? /can terminate one direction by sending a RESETSTREAM / can terminate one direction by sending a RESETSTREAM frame/ /which / that/ , add /to be/ /method which will allow packets with that connection ID to be routed back to the endpoint and identified by the endpoint upon receipt / method that allows packets with that connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt/ rate control ? /Servers MAY rate control these packets to avoid storms of Version Negotiation packets./ perhaps /rate limit/ or /control the rate of/ The words appear to depend on the wrong previous sentence : /Servers MAY rate control these packets to avoid storms of Version Negotiation packets . Otherwise , servers MUST drop packets that specify unsupported versions./ appear to be an “ otherwise ” to rate control , but is this actually intended as an “ otherwise ” to “ SHOULD send a Version Negotiation packet ” ? -/which / that/ , /There are certain operations which an application MUST / There are certain operations that an application MUST/ or any number more permitted by initial cwnd and initialmaxstreamdata_uni , the current text needs to not suggest this is unlimited ! /As a result , this handshake may consist of as few as 4 UDP datagrams , or any number more./ are required to comply with implied … /Endpoints are required to comply with the restrictions implied by these parameters;/ change /implied/ to /defined/ or perhaps remove the word?is this the same , I was n’t sure what the original ordering was ? /Implementations MUST support buffering at least 4096 bytes of data received in CRYPTO frames out of order . /Implementations MUST support buffering at least 4096 bytes of data received in out of order CRYPTO frames./ awkward multiple use of /used/ ? perhaps : /Address validation is used by QUIC to avoid being used for a traffic amplification attack./Address validation in QUIC avoids QUIC being used for a traffic amplification attack./ I did not understand this , please add something to explain : /Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction./please be careful about the layer at which s size is expressed . /in a UDP datagram of at least 1200 bytes/ Is this actually a UDP datagram or size 1200 or a payload of 1200B ( as previously stated in the section ) or something different ? 
 A few suggestions .
Paragraph (version A):
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams.  When deciding which
streams to dedicate resources to, the implementation SHOULD use the
information provided by the application.
Paragraph (version A):
There are certain operations which an application MUST be able to
perform when interacting with QUIC streams.  This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
Paragraph (version B):
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams.  When deciding the streams
to which resources are dedicated, the implementation SHOULD use the
information provided by the application.
Paragraph (version B):
There are certain operations that an application MUST be able to
perform when interacting with QUIC streams.  This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
Paragraph (version A):
Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines.  For the most part,
the use of these state machines is the same whether the stream is
unidirectional or bidirectional.  The conditions for opening a stream
are slightly more complex for a bidirectional stream because the
opening of either send or receive sides causes the stream to open in
both directions.
Paragraph (version B):
Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines.  For the most part,
the use of these state machines is the same whether the stream is
unidirectional or bidirectional.  The conditions for opening a stream
are slightly more complex for a bidirectional stream because the
opening of either the send or receive side causes the stream to open
in both directions.
Paragraph (version A):
The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application.  The
"Ready" state represents a newly created stream that is able to
accept data from the application.  Stream data might be buffered in
this state in preparation for sending.
Paragraph (version B):
The sending part of a stream that the endpoint initiates (types 0 and
2 for clients, 1 and 3 for servers) is opened by the application.
The "Ready" state represents a newly created stream that is able to
accept data from the application.  Stream data might be buffered in
this state in preparation for sending.
Paragraph (version A):
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 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 stream is "Recv".
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 stream is "Recv".
Paragraph (version A):
A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd").  A sender MUST NOT send STREAM or
STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the
terminal states and in the "Reset Sent" state.  A receiver could
receive any of these three frames in any state, due to the
possibility of delayed delivery of packets carrying them.
Paragraph (version A):
The receiver only sends MAX_STREAM_DATA in the "Recv" state.  A
receiver can send STOP_SENDING in any state where it has not received
a RESET_STREAM frame; that is states other than "Reset Recvd" or
"Reset Read".  However there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, since all stream data
has been received.  A sender could receive either of these two frames
in any state as a result of delayed delivery of packets.
Paragraph (version B):
A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd").  A sender MUST NOT send a STREAM or
STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or
any terminal state, that is, after sending a RESET_STREAM frame.  A
receiver could receive any of these three frames in any state, due to
the possibility of delayed delivery of packets carrying them.
Paragraph (version B):
The receiver only sends MAX_STREAM_DATA in the "Recv" state.  A
receiver MAY send STOP_SENDING in any state where it has not received
a RESET_STREAM frame; that is states other than "Reset Recvd" or
"Reset Read".  However there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, since all stream data
has been received.  A sender could receive either of these two frames
in any state as a result of delayed delivery of packets.
Paragraph (version A):
STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames
can be discarded upon receipt.
Paragraph (version B):
STREAM frames received after sending a STOP_SENDING frame are still
counted toward connection and stream flow control, even though these
frames can be discarded upon receipt.
Paragraph (version A):
An endpoint that wishes to terminate both directions of a
bidirectional stream can terminate one direction by sending a
RESET_STREAM, and it can encourage prompt termination in the opposite
direction by sending a STOP_SENDING frame.
Paragraph (version B):
An endpoint that wishes to terminate both directions of a
bidirectional stream can terminate one direction by sending a
RESET_STREAM frame, and it can encourage prompt termination in the
opposite direction by sending a STOP_SENDING frame.
Paragraph (version A):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and identified
by the endpoint upon receipt.
Paragraph (version B):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and to be
identified by the endpoint upon receipt.
Paragraph (version A):
If a server receives a packet that has an unsupported version, but
the packet is sufficiently large to initiate a new connection for any
version supported by the server, it SHOULD send a Version Negotiation
packet as described in send-vn.  Servers MAY rate control these
packets to avoid storms of Version Negotiation packets.  Otherwise,
servers MUST drop packets that specify unsupported versions.
Paragraph (version B):
If a server receives a packet that indicates an unsupported version
but is large enough to initiate a new connection for any one
supported version, the server SHOULD send a Version Negotiation
packet as described in send-vn.  Servers MAY limit the number of
packets that it responds to with a Version Negotiation packet.
Servers MUST drop smaller packets that specify unsupported versions.
Paragraph (version A):
There are certain operations which an application MUST be able to
perform when interacting with the QUIC transport.  This document does
not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this
section on a QUIC connection.
Paragraph (version B):
There are certain operations that an application MUST be able to
perform when interacting with the QUIC transport.  This document does
not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this
section on a QUIC connection.
Paragraph (version A):
Note that multiple QUIC packets - even of different packet types -
can be coalesced into a single UDP datagram; see packet-coalesce).
As a result, this handshake may consist of as few as 4 UDP datagrams,
or any number more.  For instance, the server's first flight contains
Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
packets with a short header.
Paragraph (version B):
Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see packet-coalesce.  As a
result, this handshake may consist of as few as 4 UDP datagrams, or
any number more (subject to limits inherent to the protocol, such as
congestion control or anti-amplification).  For instance, the
server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets with a short header.
Paragraph (version A):
During connection establishment, both endpoints make authenticated
declarations of their transport parameters.  Endpoints are required
to comply with the restrictions implied by these parameters; the
description of each parameter includes rules for its handling.
Paragraph (version B):
During connection establishment, both endpoints make authenticated
declarations of their transport parameters.  Endpoints are required
to comply with the restrictions that each parameter defines; the
description of each parameter includes rules for its handling.
Paragraph (version A):
Implementations MUST support buffering at least 4096 bytes of data
received in CRYPTO frames out of order.  Endpoints MAY choose to
allow more data to be buffered during the handshake.  A larger limit
during the handshake could allow for larger keys or credentials to be
exchanged.  An endpoint's buffer size does not need to remain
constant during the life of the connection.
Paragraph (version B):
Implementations MUST support buffering at least 4096 bytes of data
received in out of order CRYPTO frames.  Endpoints MAY choose to
allow more data to be buffered during the handshake.  A larger limit
during the handshake could allow for larger keys or credentials to be
exchanged.  An endpoint's buffer size does not need to remain
constant during the life of the connection.
Paragraph (version A):
Address validation is used by QUIC to avoid being used for a traffic
amplification attack.  In such an attack, a packet is sent to a
server with spoofed source address information that identifies a
victim.  If a server generates more or larger packets in response to
that packet, the attacker can use the server to send more data toward
the victim than it would be able to send on its own.
Paragraph (version B):
Address validation ensures that an endpoint cannot be used for a
traffic amplification attack.  In such an attack, a packet is sent to
a server with spoofed source address information that identifies a
victim.  If a server generates more or larger packets in response to
that packet, the attacker can use the server to send more data toward
the victim than it would be able to send on its own.
Paragraph (version A):
Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary.  Sending padded datagrams ensures that
the server is not overly constrained by the amplification
restriction.
Paragraph (version B):
Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary.  A client that sends padded datagrams
allows the server to send more data prior to completing address
validation.
Paragraph (version A):
Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets.  A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgements for
all the data it has sent.  In this case, when the client has no
reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address.  To
prevent this deadlock, clients MUST send a packet on a probe timeout
(PTO, see Section 6.2 of QUIC-RECOVERY).  Specifically, the client
MUST send an Initial packet in a UDP datagram of at least 1200 bytes
if it does not have Handshake keys, and otherwise send a Handshake
packet.
Paragraph (version B):
Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets.  A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgements for
all the data it has sent.  In this case, when the client has no
reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address.  To
prevent this deadlock, clients MUST send a packet on a probe timeout
(PTO, see Section 6.2 of QUIC-RECOVERY).  Specifically, the client
MUST send an Initial packet in a UDP datagram that contains at least
1200 bytes if it does not have Handshake keys, and otherwise send a
Handshake packet.