Draft: draft-ietf-quic-ack-frequency

Commentary: Also , 
 There 's nothing odd about an immediate ACK ! Perhaps the text should start by saying that the spec allows a receiver to do this anyway ? However , the current text does n't explain why the Immediate ACK might be useful . I could see three places that might benefit from an IMMEDIATE_ACK : Two cases relevant to SCTP [ RFC7053 ] are : When the rate of transmission was very low and packets might be lost and not detected ( something not uncommon in some SCTP uses ) ; as an alternative to detect connectivity failure and trigger path failover . I 'm not sure how important these specific cases are for QUIC , because the discussion at the time in TSVWG appeared to centre around use for signalling traffic ? There could also be real opportunity to use this to get more precise timing / congestion information . A set of per - packet ACKs might be useful while a CC is probing to confirm available capacity , etc . Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used . ( aside : I am actually uncertain whether this would really be a good change to TCP , especially with the heterogeniety of TCP middleboxes and senders , ... that 's another story , but I 'd think it might be nice to not rely on draft - gomez - tcpm - ack - pull as a reference . I could suggest RFC7053 , where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response . ) 
 We use an immediate ACK to support CC by delayed ACKs . 
 adds two use cases that uses IMMEDIATE_ACK . 
 Seems would benefit from a little polish and some improvement in the examples .
The IMMEDIATE_ACK Frame is a frame which causes the peer to send a
packet containing an ACK frame immediately, similar to the receipt of
Initial and Handshake packets during the QUIC handshake.
Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the
ACK if the vast majority of received packets contain an IMMEDIATE_ACK
or the receiver is under heavy load.  Senders MAY include multiple
IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is
identical to a single IMMEDIATE_ACK frame.
A sender can use an ACK_FREQUENCY frame to reduce the number of
acknowledgements sent by a receiver, but doing so increases the
chances that time-sensitive feedback is delayed as well.  For
example, as described in loss, delaying acknowledgements can increase
the time it takes for a sender to detect packet loss.  The
IMMEDIATE_ACK frame helps mitigate this problem.
An IMMEDIATE_ACK frame can be useful in other situations as well.
For example, it can be used with a PING frame (Section 19.2 of QUIC-
TRANSPORT) if a sender wants an immediate RTT measurement or if a
sender wants to establish receiver liveness as quickly as possible.
An endpoint SHOULD send a packet containing an ACK frame immediately
upon receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending
an ACK frame despite receiving an IMMEDIATE_ACK frame.  For example,
an endpoint might do this if a large number of received packets
contain an IMMEDIATE_ACK or if the endpoint is under heavy load.