Cross-path acknowledgments should be congestion controlled

[michael-eriksson]

QUIC packets that only contain an ACK frame are not congestion controlled. RFC 9000 states that:

Since packets containing only ACK frames are not congestion controlled, an endpoint MUST NOT send more than one such packet in response to receiving an ack-eliciting packet.

When ACK-only packets are sent on another path than where the ack-eliciting packets were received, this requirement is obviously violated. A receiver of a big flow of packets could easily swamp a low-latency, low-bandwidth path by sending the acknowledgments there.

[huitema]

The requirement in RFC 9000 is not about congestion control. It is about not having an infinite cycle of sending an ACK, receiving an ACK in return, ACKing that, etc.

The issue that you describe is also happening in asymmetric links, without using multipath. If the return path is too narrow, it could be congested by too many ACKs. RFC 9000 is silent about that, largely because previous attempts at congestion control of acknowledgements have been "inconclusive". Since ACKs are not immediately acknowledged, the congestion control loop is very loose, and thus very imprecise. You can easily reach a state where congestion control slows the sending of ACKs, which in turn slows the sending of data, etc.

In uni-path scenarios, the best protection against swamping the return path is to control ACK Frequency, which limits the number of ACKs sent per RTT. The big problem there is that the ACK Frequency draft does not mention multipath. It is probably too late to change that draft, so maybe we should write a companion draft, "ACK Frequency for Multipath". Basically, define a PATH_ACK_FREQUENCY frame similar to ACK Frequency but with a Path ID.

[michael-eriksson]

Christian wrote:

The requirement in RFC 9000 is not about congestion control. It is about not having an infinite cycle of sending an ACK, receiving an ACK in return, ACKing that, etc.

Hmm, I think that the quote from RFC 9000 very explicitly mentions congestion control...

But I agree that congestion controlled ACKs can easily lead to infinite ack cycles.

[huitema]

The sentence that you quoted does mention congestion control. The discussion of infinite loops happens a couple paragraphs later -- An endpoint that is only sending non-ack-eliciting packets might choose to occasionally add an ack-eliciting frame to those packets to ensure that it receives an acknowledgment; see Section 13.2.4. In that case, an endpoint MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments.

The spec does mention congestion control, as you said: Since packets containing only ACK frames are not congestion controlled, an endpoint MUST NOT send more than one such packet in response to receiving an ack-eliciting packet. That mean that if a node receives just one packet, it should send at most one ACK for that specific packet. It also implies that if you receive 2 or 3 packets, it is fine to send 2 or 3 ACKs. For example, if a node receives packets 1 and 2, it would be perfectly fine to send ACK 1-2 on path 1, and a copy of ACK 1-2 on path 2. Which would not address our problem, "avoid saturating a narrow return path".

The solution really is to send fewer ACKs overall, and that means adapting the ACK FREQUENCY draft for multipath.

[mirjak]

I agree that the problem discussed is not specific to a specific path and as such not specific to the multipath extension. I proposed to close the issue with no action.

The only thing we could do is to add a bit of discussion or a note of caution to not overload a path if one path is only used to send ACKs given they are not congestion control. But again this is effectively already a problem if you only have one path and send only ACKs in one direction. So not sure if even makes sense to explicitly say anything.