Change:
In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet <del> that is out of order.  The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint SHOULD return to acknowledging every other packet within a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order.  If every subsequent ack-eliciting packet arrives out of </del> <ins> that is out of order.  The endpoint SHOULD NOT continue sending ACK frames immediately unless more ack-eliciting packets are received out of order.  If every subsequent ack-eliciting packet arrives out of </ins> order, then an ACK frame SHOULD be sent immediately for every received ack-eliciting packet.

Discussion:
Currently the transport draft says: However, since this text was written, recovery was changed to require packet AND time threshold loss detection, so the only time sending multiple immediate ACKs for a single missing packet would be beneficial is if the first ACK is lost. Also, only sending 1 immediate ACK is a lot easier to implement and reason about in my opinion than "up to 1/8 RTT".
NAME NAME NAME Can you please mark this as design since the PR will change normative text.
I think it could have other effects - it will impact the robustness to loss/congestion on the return path compared to the way TCP operates. Sending one isolated ACK here isn't the same, although you could argue that the ACK information is indeed repeated "ACK Delay" or "N packets" later. If we relax the number of packets per ACK this may need a little more thought to avoid delaying congestion detection when there is loss?
Currently in the drafts, N is 2, so there are very few cases where sending more ACKs would be beneficial. The worst case I can construct is If the first ACK is lost, then the loss detection could be delayed by the maxackdelay IF exactly one more packet was received. That seems quite acceptable and loss of ack-only packets is rare in my experience. Drafts like the ack-frequency extension do change the dynamics some, but they also increase the relative cost of sending immediate ACKs more than once. For example, instead of sending an ACK-only packet every 10 or 20 packets, a receiver could switch to sending an ACK for every packet, which could massively slow down the connection and increase load on the network. I'm going to run a production experiment with this change as well to confirm that it performs as well or better, but that may take a few months.
My point is I think this is the wrong direction. I think n=2 is unnecessarily restrictive as a default, and does have unwanted performance impacts in some places. I think the case of loss for a burst of one packet that you mention is handed by the timer. The congestion impact is minor.

While I agree for n=2 the method doesn't make much difference, for n=10, it would make a difference - because I'd expect it to be Important to be able to robustly detect and respond after congestion, I'm not sure it matters if the intention is to send DupACK+k immediate ACks or to send ACKs more frequently for some proportion of a RTT.
NAME You appear to be saying that if we substantially changed the current ACK guidance, this PR might be suboptimal. Is that correct? I don't believe the current guidance is optimal in almost any circumstance, so I would really like to change it. Also, I don't believe we'll end up changing the ACK behavior substantially in the core drafts at this point, so I believe we should proceed with guidance we think works well with the existing draft without being substantially sub-optimal if a receiver does unilaterally decide to ACK less frequently.
NAME : I'd like to move this one along. I think this is generally fine, and it makes things quite a bit simplicity for the implementation, and it reduces the number of ACKs significantly when there's some reordering. If you think we should have a different recommendation, please say so. I'm marking this proposal-ready so this gets into the next consensus call run.
I think it will impact the robustness to loss/congestion on the return path compared to the way TCP operates, but the use of PTO generally mitigates this... There are cases where relying only on the PTO would delay congestion detection, such as when there is a significantly reduced path RTT at the same time as loss (we could think of scenario where this is a result of re-routing for the path). I’m also interested in a case where there is loss in both directions (which can also happen in congestion collapse). The reduction of ACK information could result in unnecessary duplicated data (because the sender does not receive ACK range info). This issue seems most severe when there are too few ACKs per RTT. It seems there is merit in ensuring there are sufficient ACKs per RTT - e.g., a rule that sends ACKs at least every (say) 1/8 RTT would seem wise. Overall, I am in favour of the proposal to change the response after loss/reorder. QUIC currently generates a lot more ACK traffic (in volume) than TCP.

ACK after loss event are common with RENO overflowing a router buffer (we are looking at this now). This proposed change is likely to really help reduce ACK traffic volume on the return path. If the arguments for this seem valid, I think related issue needs to be considered again.
currently states: NAME notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.
That section used to be in recovery, where we have a definition already(which is now unused), so I'd suggest we move it over. "Out-of-order Packets: : Packets that do not increase the largest received packet number for its packet number space by exactly one. Packets arrive out of order when earlier packets are lost or delayed."
Isn't this supposed to be "Packets that increase the largest received packet number ... by more than one." in this case?
Thinking about this some more, there are three possible definitions here for out-of-order: a newly received packet is greater than largest received by more than one, a newly received packet is smaller than the largest received, both (1) and (2). (1) is the obvious case where a loss happens and a subsequent packet is received. (2) is the reordering case, where an earlier packet is delivered later, and while it does not indicate loss, it does indicate that a gap was filled. It's useful to signal (2) as well immediately to prevent a sender from unnecessarily retransmitting what it believes to be a missing packet. The definition we want for "out-of-order" is the one that is most useful for determining when to send an immediate ack. The definition in the PR captures both (1) and (2), and is probably the one we want.
NAME : If you believe we ought to change the definition, please re-open, and we can continue this discussion.