Draft: draft-ietf-quic-transport

Commentary: had some useful feedback in . This does n't address the following items as numbered in the issue : ( 2 ) Because the fix to ( 1 ) seems adequate by my reckoning . That addresses the question of considering the impact on other network users . ( 6 ) This does n't appear to be a problem . It might be a formatting issue , with the URL not appearing . ( 7 ) This is addressed in the recent draft by adding Section 2 ( 9 ) and ( 11 ) I ca n't find the rendering glitch mentioned . The rest of these are good . 
 Fine and thanks for looking to these . I do think something more needs to be said about the need to avoid collateral impact on the forward traffic of this and other traffic sharing a path . To me this really important in an IETF Transport specification , especially one that might displace TCP . /It can also improve connection throughput on severely asymmetric links ; see Section 3 of { { ?  To me , a note to make sure this is n't ignored would seem enough , but I 'd be happy to take this up as a separate WGLC comment if that seems better . 
 Let 's take that up separately . I do n't object to the language , but I just did n't know what to say . 
 I think there are NiTs in the second half the ID also , and while I suspectthese do n't change the intended meaning , they nevertheless should be examined by the editors : ( 1 ) Concerning ACKS : I thought the following text was heading in the correct direction , but I remain concerned that this could be read to suggest that performance of the flow should drive the changes . /However , an implementer should only deviate from these requirements after careful consideration of the performance implications of doing so./ I ’d love this to actually say something about congestion . Decisions made in the generation of ACKs can impact the congestion to the network and therefore also the performance of other flows that share a path . I really think we should say this . ( 2 ) And collateral impact on other traffic : /It can also improve connection throughput on severely asymmetric links ; see Section 3 of { { ?  It also can have important congestion impacts on other traffic that shares an asymmetric bottleneck , besides the self - harm of reducing the application ’s own throughput . ( 3 ) Justify ? This text seems a good recommendation , but there is n’t a hint at why this is a strong requirement , could the editors add one line of text explaining ? /Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram./ ( 4 ) The size and frequency of ACKs can impact the performance of QUIC , so there are also congestion control reasons to not overly report ACK ranges . /This is necessary if an ACK frame would be too large to fit in a packet , however receivers MAY also limit ACK frame size further to preserve space for other frames./ ( 5 ) This seems an awkward sentence and I could not understand what was intended : /A receiver MUST NOT bundle an ack - eliciting frame with all packets that would otherwise be non - ack - eliciting , to avoid an infinite feedback loop of acknowledgements./ Perhaps /all/ in this is part of my confusion ? ( 6 ) In Section :  ( missing words ) /Implementors are encouraged to register version numbers of QUIC that they are using for private experimentation on the GitHub wiki at ./ either way , it may be better to complete the sentence ? ( 7 ) In Section : PING Frame : ( NiT ) This seems good advice , but I ’d love the sentence to include “ to keep a connection alive ” , since at the moment reading this alone , could be seen as rather general guidance . Whereas there are other uses of PINGs , such as PLPMTUD , and for this use can generate pings by clients and servers : /An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended . / e.g. /An application protocol SHOULD provide guidance about the conditions under which it recommends generating a PING to keep a connection alive./ ( 8) In ACKs : ( NiT ) /This is unlike TCP SACKs ( { { ? RFC2018}})./This is unlike reneging for TCP SACKs ( { { ? RFC2018}})./ can we be slightly more explicit about the important difference by adding a couple of words ? ( 9 ) In Section : STREAM Frames ( line break :) /Offset:/ The first sentence in /Offset/ appears to have an odd line - break mid sentence . ( 10 ) In Section : Extension Frames /which / that/ ? /other extensions which modify or replace the same functionality unless the behavior of the combination is explicitly defined./ ( 11 ) In Section : Transport Error Codes ( line break :)  ( 0xB ): :/ The first sentence needs a line - break mid sentence . ( 12 ) In Section : Version Negotiation Is this only a recommendation ? “ Clients that support multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support . ” Whereas in Section : Packet Size /A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least 1200 bytes , by adding PADDING frames to the Initial packet or by coalescing the Initial packet ; see { { packet - coalesce}}./ I think the latter is true , and suspect that version negotiation section should n’t include this text , but instead refer to the text norm initial packet size . ( 13 ) In Section : Cryptographic and Transport Handshake Is this intended as optional , I think it is required when ECN is to be used ? “ An endpoint can verify support for Explicit Congestion Notification ( ECN ) in the first packets it sends , as described in { { ecn - validation } } . ” seems to suggest this is optional , whereas , I think actually this is describing a needed mechanism , so is it better to say “ An endpoint verifies ” as is done in the section : Initiating Connection Migration . which says : “ The new path might not have the same ECN capability . Therefore , the endpoint verifies ECN capability as described in { { ecn } } . ” 
 Let 's get these in and deal with more specific issues separately .
Paragraph (version A):
The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet.  Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the
largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually
supported version.
Paragraph (version B):
The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet.  Clients that support
multiple QUIC versions SHOULD pad the first UDP datagram they send to
the largest of the minimum datagram sizes from all versions they
support.  This ensures that the server responds if there is a
mutually supported version.
Paragraph (version A):
An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in ecn-validation.
Paragraph (version B):
An endpoint verifies support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in ecn-validation.
Paragraph (version A):
Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram.  Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first
packet in the datagram.
Paragraph (version B):
Receivers MAY route based on the information in the first packet
contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets
for different connections into a single UDP datagram.  Receivers
SHOULD ignore any subsequent packets with a different Destination
Connection ID than the first packet in the datagram.
Paragraph (version A):
The algorithms in QUIC-RECOVERY are expected to be resilient to
receivers that do not follow guidance offered above.  However, an
implementer should only deviate from these requirements after careful
consideration of the performance implications of doing so.
Paragraph (version B):
The algorithms in QUIC-RECOVERY are expected to be resilient to
receivers that do not follow guidance offered above.  However, an
implementation should only deviate from these requirements after
careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
Paragraph (version A):
It is possible that retaining many ACK Ranges could cause an ACK
frame to become too large.  A receiver can discard unacknowledged ACK
Ranges to limit ACK frame size, at the cost of increased
retransmissions from the sender.  This is necessary if an ACK frame
would be too large to fit in a packet, however receivers MAY also
limit ACK frame size further to preserve space for other frames.
Paragraph (version B):
It is possible that retaining many ACK Ranges could cause an ACK
frame to become too large.  A receiver can discard unacknowledged ACK
Ranges to limit ACK frame size, at the cost of increased
retransmissions from the sender.  This is necessary if an ACK frame
would be too large to fit in a packet.  Receivers MAY also limit ACK
frame size further to preserve space for other frames or to limit the
capacity that acknowledgments consume.
Paragraph (version A):
A receiver MUST NOT bundle an ack-eliciting frame with all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgements.
Paragraph (version B):
A receiver MUST NOT bundle an ack-eliciting frame with packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgements.
Paragraph (version A):
QUIC acknowledgements are irrevocable.  Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK
frame.  This is unlike TCP SACKs (RFC2018).
Paragraph (version B):
QUIC acknowledgements are irrevocable.  Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK
frame.  This is unlike reneging for TCP SACKs (RFC2018).
Paragraph (version A):
Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other
extensions which modify or replace the same functionality unless the
behavior of the combination is explicitly defined.  Such extensions
SHOULD define their interaction with previously-defined extensions
modifying the same protocol components.
Paragraph (version B):
Extensions that modify or replace core protocol functionality
(including frame types) will be difficult to combine with other
extensions that modify or replace the same functionality unless the
behavior of the combination is explicitly defined.  Such extensions
SHOULD define their interaction with previously-defined extensions
modifying the same protocol components.
Paragraph (version A):
A server received a Retry Token in a client Initial that is
invalid.
Paragraph (version B):
A server received a client Initial that contained an invalid Token
field.