From a7ad371908364e16474ec746a33aea4c30afc3d9 Mon Sep 17 00:00:00 2001 From: ianswett Date: Wed, 16 Oct 2019 20:01:49 -0400 Subject: [PATCH 1/2] MUST pace or limit bursts to 10 packets Fixes part or all of #3094 --- draft-ietf-quic-recovery.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 4a0ed6eda8..5132fd7965 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -753,6 +753,12 @@ delivery of ACK frames is important for efficient loss recovery. Packets containing only ACK frames should therefore not be paced, to avoid delaying their delivery to the peer. +Sending multiple packets into the network without any delay between them +creates a packet burst that might cause short-term congestion and losses. +Implementations MUST either use pacing or limit such bursts to minimum +of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same +as the recommended initial congestion window. + As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards). @@ -773,13 +779,6 @@ and not fully utilize the congestion window due to this delay. A sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay. -Sending multiple packets into the network without any delay between them -creates a packet burst that might cause short-term congestion and losses. -Implementations SHOULD either use pacing or reduce their congestion window -to limit such bursts to minimum of 10 * kMaxDatagramSize and -max(2* kMaxDatagramSize, 14720)), the same as the recommended initial -congestion window. - A sender MAY implement alternate mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in {{?RFC7661}}. From 8aa3f261bac737b25867c964a8eb941f362be36a Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 17 Oct 2019 12:42:55 -0400 Subject: [PATCH 2/2] Update draft-ietf-quic-recovery.md Remove the old paragraph --- draft-ietf-quic-recovery.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index bddbb425d0..9effcf32c2 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -779,13 +779,6 @@ and not fully utilize the congestion window due to this delay. A sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay. -Sending multiple packets into the network without any delay between them -creates a packet burst that might cause short-term congestion and losses. -Implementations SHOULD either use pacing or reduce their congestion window -to limit such bursts to minimum of 10 * kMaxDatagramSize and -max(2* kMaxDatagramSize, 14720)), the same as the recommended initial -congestion window. - A sender MAY implement alternative mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in {{?RFC7661}}.