From 8e9af203e087c772ff278a670e4c2e2e57466535 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 6 Nov 2020 10:50:10 -0500 Subject: [PATCH] Martin's suggestion, tweaked Co-authored-by: Martin Thomson --- draft-ietf-quic-recovery.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 225f19c0cc..ba5626fead 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -194,13 +194,13 @@ not available. ## Clearer Loss Epoch -QUIC starts a loss epoch when a packet is lost and ends one when any packet -sent after the epoch starts is acknowledged. TCP waits for the gap in the -sequence number space to be filled, and so if a segment is lost multiple times -in a row, the loss epoch may not end for several round trips. Because both -should reduce their congestion windows only once per epoch, QUIC will do it -once for every round trip that experiences loss, while TCP may only do it -once across multiple round trips. +QUIC starts a loss epoch when a packet is lost. The loss epoch ends when any +packet sent after the start of the epoch is acknowledged. TCP waits for the gap +in the sequence number space to be filled, and so if a segment is lost multiple +times in a row, the loss epoch may not end for several round trips. Because both +should reduce their congestion windows only once per epoch, QUIC will do it once +for every round trip that experiences loss, while TCP may only do it once across +multiple round trips. ## No Reneging