Subject: [quicwg/base-drafts] Remove using_time_based_loss_detection from Recovery draft (#1969)

From: ianswett <[email-masked]>
Date: Mon, 05 Nov 2018 21:19:47 -0800

@pravb Indicated declaring a packet lost if the reordering threshold(ie: 3) OR the time threshold has been reached, then a packet is declared lost.

I'd like to remove early retransmit entirely, because it's a bit complex and having QUIC operating in two alternate modes, but indicating both can be enabled at once in the text is very confusing.

-- 
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/1969

---

From: Matt Olson <[email-masked]>
Date: Thu, 08 Nov 2018 18:44:47 -0800

The IETF RACK/TLP draft for TCP has a more dynamic hybrid of RACK ("time-based") and dupthresh ("packet-based") recovery: dupthresh is used at first, but then turned off when any reordering is detected. The idea being that a packet-based threshold is too sensitive on networks with moderate reordering. It would be easy to adapt this to QUIC. Along with the dynamic time-based reordering threshold that is a MAY in the QUIC spec right now iirc, this would go under the general heading of "reordering tolerance."

-- 
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/1969#issuecomment-437231311

---

From: ianswett <[email-masked]>
Date: Thu, 08 Nov 2018 19:05:55 -0800

Thanks Matt, is there evidence the current RACK algorithm is a good approach for mixing packet and time reordering thresholds dynamically?

I believe there were few experiments that showed starting with time-only caused regressions on flows with little to no reordering, particularly in low RTT environments where the alarm granularity is comparable to the RTT.

If we think there's enough evidence the current RACK algorithm is close to optimal, I'm happy to put that in, but given RACK is not yet an RFC, I was under the impression it was still evolving?

-- 
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/1969#issuecomment-437234878

---

From: Matt Olson <[email-masked]>
Date: Fri, 09 Nov 2018 14:28:34 -0800

The main dissent I've heard about the current RACK algo is that we shouldn't ship code that tolerates reordering because it might incentivize use of technologies that introduce reordering. Link bonding, for instance, can introduce such reordering supposedly, although that's a bit surprising since you could just hash tuples to NICs. Anyway, that's the narrative.

Probably this is something that should be its own Issue and outside the scope of removing the kUsingTimeLossDetection variable. I'll open the new issue.

-- 
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/1969#issuecomment-437514930

---

From: ianswett <[email-masked]>
Date: Sat, 10 Nov 2018 05:07:46 -0800

Based on my understanding of modern networking, I'd expect fraction of packets reordered to increase over time, even if the distance in time is quite small(ie: ~1ms).

And that narrative would argue a default reordering threshold of 1 dupack, which TCP has never recommended to my knowledge.

Good point that this seems like a larger question for both RACK and QUIC.

-- 
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/1969#issuecomment-437582699

---

From: Matt Olson <[email-masked]>
Date: Sat, 10 Nov 2018 16:15:20 -0800

Opened issue:
#1986 

-- 
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/1969#issuecomment-437632351

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Nov 2018 11:52:21 +0000 (UTC)

@ianswett : I'd argue against removing ER, though I'm in favor of removing time-based-loss-detection since that's basically a separable boolean in the code that can be added once someone has more experience with it. ER requires at least one ack and uses a timer, and FR uses packet thresholds.

-- 
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/1969#issuecomment-437852457

---

From: ianswett <[email-masked]>
Date: Mon, 12 Nov 2018 06:46:29 -0800

I don't think removing time threshold loss detection is the right direction, both based on personal experience and on talking with Praveen and Yuchung about RACK.  Removing ER seems like a better long term direction.  Time threshold loss detection still requires a larger packet to be declared acknowledged to declare a smaller one lost.

-- 
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/1969#issuecomment-437907432