From 923cf90bbe870c024d8a9a365b275d7ba75ee609 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 20 Dec 2024 14:40:55 +0100 Subject: [PATCH 1/5] 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 From 43dbcc8961de4a671460e429786335eb216c9a97 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 10 Jan 2025 16:15:32 +0100 Subject: [PATCH 2/5] suggested wording by Christian --- draft-ietf-quic-multipath.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 9e629e80..5e468a73 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -979,10 +979,9 @@ 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. 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. +and thus better performance. However, since packets that only carries PATH_ACK frames +are not congestion controlled, senders should carefully consider the load induced +by these packets, especially if the capacity is unknown on that path. ## Retransmissions From 365e2790745293422dcee175e247e5e0da534f9b Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 17 Jan 2025 12:35:24 +0100 Subject: [PATCH 3/5] nit. Thanks Christian! --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 5e468a73..2c5b1b18 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -979,7 +979,7 @@ 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. However, since packets that only carries PATH_ACK frames +and thus better performance. However, since packets that only carry PATH_ACK frames are not congestion controlled, senders should carefully consider the load induced by these packets, especially if the capacity is unknown on that path. From 6b61060e0542b509927e98cf2759103ff4ba1b16 Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 22 Jan 2025 09:56:25 +0100 Subject: [PATCH 4/5] Update draft-ietf-quic-multipath.md Co-authored-by: Yanmei Liu --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 2c5b1b18..670f10a3 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -980,7 +980,7 @@ 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. However, since packets that only carry PATH_ACK frames -are not congestion controlled, senders should carefully consider the load induced +are not congestion controlled (see {{Section 7 of QUIC-RECOVERY}}), senders should carefully consider the load induced by these packets, especially if the capacity is unknown on that path. ## Retransmissions From ccb3cc4f2eeb58ca1da8bf56de054bfd3a47f5be Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 22 Jan 2025 09:56:54 +0100 Subject: [PATCH 5/5] linebreak --- draft-ietf-quic-multipath.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 670f10a3..4e04a0d6 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -980,7 +980,8 @@ 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. However, since packets that only carry PATH_ACK frames -are not congestion controlled (see {{Section 7 of QUIC-RECOVERY}}), senders should carefully consider the load induced +are not congestion controlled (see {{Section 7 of QUIC-RECOVERY}}), +senders should carefully consider the load induced by these packets, especially if the capacity is unknown on that path. ## Retransmissions