Draft: draft-ietf-quic-transport

Commentary: Also removes obsolete text about acknowledging CRYPTO frames quickly , now that Initial and Handshake packet spaces have a maxackdelay of 0 . 
 Sorry I 'm late here but I think it would still be good to mention that congestion control usually is supposed to work on a RTT granularity and if you send less ACKs than one per RTT that can have an impact on cc . I do n't think this has to be a normative requirement given you have normative requirements on maxackdelay and a reasonable default value but it would still be good to mention this dependency as cc is done on sender and ACKing on receiver and therefore it might not always that obvious . 
 The spec gives no reason ( that I can see ) as to why an ACK frame must be sent at least once per round trip ( assuming there are ack - eliciting packets to acknowledge ) , effectively overwriting the ACK delay logic when the RTT is very small . If the RTT is smaller than the platform 's timer granularity , this is n't really even possible . I propose to remove this requirement . If the WG instead feels that we should keep this requirement , then there should be a reasoning for it ; and probably an update to the PTO calculation as well . 
 As I commented on the PR that this came up in , given we have an explicit maxackdelay that 's now communicated , removing the 1 ACK per RTT requirement seems wise . TCP has no such recommendation and I 'm unaware of any indications or proposals that it should have such a property . 
 point that the RTT can be smaller than the platform 's granularity is a good one . I agree that this text ought to be removed . 
 This is changing text in a SHOULD statement , so I believe it should be marked as design . 
 LGTM
Paragraph (version A):
A receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter.  This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received.  The
sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission.
Paragraph (version B):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  An endpoint commits to a maximum delay using the
max_ack_delay transport parameter; see transport-parameter-
definitions.  max_ack_delay declares an explicit contract: an
endpoint promises to never delay acknowledgments of an ack-eliciting
packet by more than the indicated value.  If it does, any excess
accrues to the RTT estimate and could result in delayed
retransmissions from the peer.  For Initial and Handshake packets, a
max_ack_delay of 0 is used.  The sender uses the receiver's
"max_ack_delay" value in determining timeouts for timer-based
retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY.
Paragraph (version A):
Acknowledgements of packets carrying CRYPTO frames SHOULD be
minimally delayed, to complete the handshake with minimal latency.
Delaying them by a small amount, such as the local timer granularity,
allows the endpoint to bundle any data sent in response with the ACK
frame.  ACK frames SHOULD be sent immediately when the crypto stack
indicates all data for that packet number space has been received.
Paragraph (version A):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  An endpoint commits to a maximum delay using the
max_ack_delay transport parameter; see transport-parameter-
definitions.  max_ack_delay declares an explicit contract: an
endpoint promises to never delay acknowledgments of an ack-eliciting
packet by more than the indicated value.  If it does, any excess
accrues to the RTT estimate and could result in delayed
retransmissions from the peer.  For Initial and Handshake packets, a
max_ack_delay of 0 is used.