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 <[email protected]> On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, August 4, 2021 11:30 AM
To: Bob Briscoe <[email protected]>
Cc: Jana Iyengar <[email protected]>; Ian Swett <[email protected]>; QUIC IETF
mailing list <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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/
