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

[Christian Huitema <[e-mail]>]

The design assumes that using the ACK-Frequency frames is mutually 
beneficial for clients and servers. Clients follow the servers' 
directive because they believe that by doing so they will benefit from 
better performance. Yes, the server is probably not going to just 
disconnect if the client sends too many ACKs. But the server will 
definitely slow down, and that's not in the client's interest.

-- Christian Huitema

On 8/4/2021 11:58 AM, Mike Bishop wrote:
> This also seems to fall into the realm of requirements that are difficult to enforce against the other side.  There are some corner cases where you might be sure, and if you cared to track over time you could infer whether your peer is complying within a reasonable probability… but it would be hard to be certain.  This seems like a SHOULD.
>
> From: QUIC <[e-mail]> On Behalf Of Spencer Dawkins at IETF
> Sent: Wednesday, August 4, 2021 11:30 AM
> To: Bob Briscoe <[e-mail]>
> Cc: Jana Iyengar <[e-mail]>; Ian Swett <[e-mail]>; QUIC IETF mailing list <[e-mail]>
> Subject: Re: quic-ack-frequency: fewer OK, but not excess
>
> 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]<mailto:[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/