quic-ack-frequency: fewer OK, but not excess

[Bob Briscoe <[e-mail]>]

In 6. Sending Acknowledgments 
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-00#section-6> 
it says "On receiving an ACK_FREQUENCY frame...endpoint MUST send an 
acknowledgement when..."

What if it doesn't? Why MUST?
The underlying question here is what is the interoperability requirement?
Imagine I'm host A, and I instruct B to set ACK-eliciting threshold = 8 
packets.

 1. What if B ACKs more frequently? e.g. every packet, is it a DoS
    attack? Is this a protocol violation?
 2. The spec allows B to ACK less often (it says greater than or equal
    to "ACK-eliciting threshold"), but it says no longer than
    max_ack_delay. What if A has told B to set max_ack_delay = 960 μs,
    but B has other things taking up its resources, so B sends an ACK
    every 2ms? A's congestion controller might not perform quite so
    well, but is this a protocol violation? What can A do about it, and
    does it really need to expect B to do anything differently?

To propose answers to my own questions, I would suggest that:

 1. A MAY consider B is violating the protocol if B ACKs more frequently
    than ACK-eliciting threshold (after having acknowledged the relevant
    ACK_FREQUENCY frame). Then if A can cope, it just keeps calm and
    carries on. But if it can't it is entitled to panic.
 2. In contrast, A needs no recourse if B sends any or all ACKs more
    infrequently than the max_ack_delay. The connection performance goes
    to pieces, but that's what happens when one machine can't cope.


Changes to the text of §6 that would put all the above into effect:

  * s/"max_ack_delay"/at least "max_ack_delay"/ in second bullet.
  * After the two bullets, add something to the effect of "...MAY
    consider B is violating..." as in the bullet above.
  * §6.3 (Batch Processing of Packets) should not be described as an
    exception. It's just an example of a case when an ACK is sent when
    the number of received ack-eliciting packets is greater than, not
    equal to, the "ACK-eliciting threshold" (as already allowed in the
    first bullet).


------------------------------------------------------------------------
In 6.2. Expediting Congestion Signals 
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-00#section-6.2> 
there's a similar issue. It says
    "...an endpoint SHOULD immediately acknowledge packets marked with 
the ECN Congestion Experienced (CE)..."

Up to a point this is OK, but during overload in one direction, it 
causes every packet to be ACKd in the other. The forward direction is 
going to have to slow down due to the CE marking, but it might not be 
the best idea to stuff up the queue with ACKs on the reverse path at 
just the same moment.

Also, if QUIC is used in a DC, or with L4S across an ECN AQM that uses a 
simple step marking threshold, it can lead to runs of 100% ECN marking 
lasting for around 1 RTT. But by the quoted rule, the receiver SHOULD 
ACK every packet. I'm aware that this is a quote from RFC9000, but at 
least RFC9000 allows us to "deviate from these requirements after 
careful consideration" because it seems wrong.

There's also the question of whether this is meant to mean that an 
endpoint SHOULD ACK acknowledgement packets marked CE, which could lead 
to an interminable ACK ping-pong.

There has been a long discussion going on about a similar subject in 
tcpm. You might want to refer to the thread:
Seeking WG opinions on ACKing ACKs with good cause 
<https://mailarchive.ietf.org/arch/msg/tcpm/xudSM54FV2HRyzF9fbrj34-0ST8/>

It might be quicker to just read the text resulting from that thread, 
which is now in the Accurate ECN TCP Feedback draft:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.2.5.1
There's a lot of tricky stuff there.

Cheers



Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/