From 923cf90bbe870c024d8a9a365b275d7ba75ee609 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 20 Dec 2024 14:40:55 +0100 Subject: [PATCH] acks are not congestion control -> be careful this PR is a clarification based on the discussion in issue #454. Of course it's optimal to add this recommendation or not. However, it's in the implementation considerations section and I think at least noting the issue is a good thing. --- draft-ietf-quic-multipath.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 0b3ada1a..9e629e80 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -979,7 +979,10 @@ faster if the scheduling strategy is stable, but besides that implementations can choose between multiple strategies such as sending PATH_ACK frames on the path they acknowledge packets, or sending PATH_ACK frames on the shortest path, which results in shorter control loops -and thus better performance. +and thus better performance. As packets that only carries PATH_ACK frames +are not congestion controlled, sending only PATH_ACK frames on a path +should carefully consider the load induced by these packets, especially +if the capacity is unknown on that path. ## Retransmissions