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/
