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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Bob,

On just one point (and it's a BCP 14 point),

On Tue, Jul 27, 2021 at 5:43 PM Bob Briscoe <[e-mail]> wrote:

> 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.
>
>  I may be missing something, but is that saying that A MAY consider B is
violating the protocol if B ACKs more frequently because of packet
reordering (as in
https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-00#section-6.1
)?

>From a BCP 14 perspective - I've sent plenty of email about SHOULDs, both
as a GenART reviewer and as an AD, asking "so why would an endpoint NOT do
that ("why is that SHOULD not a MUST?"). But in this case, I THINK you're
describing where B MUST do something (In Section 6), but B has a good
reason to violate the MUST (in 6.1) from A's perspective, and A might or
might not decide that even if B violates the MUST, A can just go on.

Do I have that wrong?

If so, my apologies, but if not, this is a poster child for SHOULD, rather
than a MUST that can be ignored, or not, depending on how A is feeling that
day.

Best,

Spencer

>
>    1. 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/
>
>