Original text:
6. <del> 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. </del>  7.

Reviewer comments:
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 doesn'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.
URL adds two use cases that uses IMMEDIATE_ACK.
Seems would benefit from a little polish and some improvement in the examples.

Revised text:
6.  <ins> 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. </ins> 7.