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]> 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/ > >
