Subject: [quicwg/base-drafts] confusing Fast Retransmit modes (#1212)

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Mar 2018 16:50:43 +0000 (UTC)

The loss recovery spec describes to different (and mutually exclusive) Fast Retransmit modes: one detects reordering in packet number space, the other one in time space.

The Fast Retransmit section is not clear about the fact that implementations have to choose one or the other mode, and just mentions time reordering at the very end.

Furthermore, I find the pseudo code for `DetectLostPackets` pretty hard to read, since depending on the mode, different variables are set to infinite and then used in comparisons. It would probably be easier to provide two different definitions of this functions depending on the mode.

I'd be happy to write up a PR, if people agree that the current text needs improvement in that direction.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1212

---

From: ianswett <[email-masked]>
Date: Fri, 16 Mar 2018 13:52:00 +0000 (UTC)

Agreed, though technically both of these could run at once, I think it's best to describe them as two mutually exclusive modes.

A PR to improve the text and pseudocode would be appreciated, thanks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1212#issuecomment-373719201

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 17 Mar 2018 00:46:21 -0700

ya there's some places which use the delayUntilLost for for time space for the early retransmit threshold. It might be nice to separate those two out to show that early retransmit is always active.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1212#issuecomment-373901678

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 18 Mar 2018 07:01:34 +0000 (UTC)

I don't think these are mutually exclusive modes. With TCP today we do both, if the SACK information suggests lost packets or RACK kicks in and marks packets lost. Time based detection cannot work for low latency connections due to lack of fine grained timers so you always need to augment with packet based detection. IMO an implementation should do both.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1212#issuecomment-373977171