Skip to content

Commit 810bedd

Browse files
authored
Update draft-ietf-quic-recovery.md
1 parent 5d965ca commit 810bedd

File tree

1 file changed

+17
-9
lines changed

1 file changed

+17
-9
lines changed

draft-ietf-quic-recovery.md

Lines changed: 17 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -250,23 +250,31 @@ the acknowledgement indicates that a later packet was received, while the
250250
reordering threshold provides some tolerance for reordering of packets in the
251251
network.
252252

253+
Spuriously declaring packets lost leads to unnecessary retransmissions and
254+
may result in degraded performance due to the actions of the congestion
255+
controller upon detecting loss. Implementations that detect spurious
256+
retransmissions and increase the reordering threshold in packets or time
257+
MAY choose to start with smaller initial reordering thresholds to minimize
258+
recovery latency.
259+
253260
#### Packet Threshold
254261

255262
The RECOMMENDED initial value for kReorderingThreshold is 3, based on
256263
TCP loss recovery {{?RFC5681}} {{?RFC6675}}. Some networks may exhibit higher
257-
degrees of reordering, causing a sender to detect spurious losses. Spuriously
258-
declaring packets lost leads to unnecessary retransmissions and may result in
259-
degraded performance due to the actions of the congestion controller upon
260-
detecting loss. Implementers MAY use algorithms developed for TCP, such as
264+
degrees of reordering, causing a sender to detect spurious losses.
265+
Implementers MAY use algorithms developed for TCP, such as
261266
TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience.
262267

263268
#### Time-based
264269

265-
QUIC implementations can use time-based loss detection to handle reordering
266-
based on time elapsed since the packet was sent. This may be used either as
267-
a replacement for a packet reordering threshold or in addition to it. When
268-
a larger packet is acknowledged, if it was sent more than the threshold after
269-
any in flight packets, those packets are immediately declared lost.
270+
Time-based loss detection uses a time threshold to determine how much
271+
reordering to tolerate. In this document, the threshold is expressed as a
272+
fraction of an RTT, but implemenantations MAY experiment with absolute
273+
thresholds. This may be used either as a replacement for a packet reordering
274+
threshold or in addition to it.
275+
276+
When a larger packet is acknowledged, if it was sent more than the
277+
threshold after any in flight packets, those packets are immediately declared lost.
270278
Otherwise, a timer is set for the the reordering threshold minus the time
271279
difference between the earliest in flight packet and the largest newly
272280
acknowledged packet. Note that in some cases the timer could become longer

0 commit comments

Comments
 (0)