Draft: draft-ietf-quic-recovery

Commentary: At the moment , we state that a QUIC packet that contains frames other than ACK and PADDING ( ) , but I wonder if that is true for CONNECTIONCLOSE frame . A CONNECTIONCLOSE frame never elicits an acknowledgment . IIUC , it is not meant to be governed by the congestion controller . Considering the aspects , I think we should add CONNECTION_CLOSE to the list of non - ACK - eliciting frames . 
 That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE , which is consistent with the intent . If we make this change , I believe APPLICATIONCLOSE needs to be on the list as well . Now that we discuss ack - eliciting in transport , I think we 'd need to change both transport and recovery and mark this design . So I think this would be a slight improvement , but I an also imagine people claiming that CONNECITON_CLOSE is already special , so there 's no need for a change . 
 APPLICATION_CLOSE is no more . This seems like a fine change . 
 This seems sensible . 
 Discussed in Cupertino . Obvious correction . 
 Seems right to me . Editorial tweaks suggested .
Paragraph (version A):
All frames besides ACK or PADDING are considered ack-eliciting.
Paragraph (version B):
All frames other than ACK, PADDING, and CONNECTION_CLOSE are
considered ack-eliciting.
Paragraph (version A):
Packets that contain only ACK frames do not count toward
congestion control limits and are not considered in-flight.
Paragraph (version B):
Packets containing frames besides ACK or CONNECTION_CLOSE frames
count toward congestion control limits and are considered in-
flight.
Paragraph (version A):
A QUIC packet that contains frames other than ACK and PADDING.
These cause a recipient to send an acknowledgment (see sending-
acknowledgements).
Paragraph (version B):
A QUIC packet that contains frames other than ACK, PADDING, and
CONNECTION_CLOSE.  These cause a recipient to send an
acknowledgment (see sending-acknowledgements).
Paragraph (version A):
Each endpoint advertises its own idle timeout to its peer.  An
endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully.  The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an
ack-eliciting packet; see QUIC-RECOVERY), but only if no other ack-
eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity.
Paragraph (version B):
Each endpoint advertises its own idle timeout to its peer.  An
endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully.  The timer is also restarted
when sending an ack-eliciting packet (see QUIC-RECOVERY), but only if
no other ack-eliciting packets have been sent since last receiving a
packet.  Restarting when sending packets ensures that connections do
not prematurely time out when initiating new activity.
Paragraph (version A):
Endpoints acknowledge all packets they receive and process.  However,
only ack-eliciting packets (see QUIC-RECOVERY) trigger the sending of
an ACK frame.  Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons.
Paragraph (version B):
Endpoints acknowledge all packets they receive and process.  However,
only ack-eliciting packets cause an ACK frame to be sent within the
maximum ack delay.  Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons.