Subject: [quicwg/base-drafts] SHOULD use adaptive thresholds (#3572)

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 07:08:03 -0700

Fixes #3571
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3572

-- Commit Summary --

  * SHOULD use adaptive thresholds

-- File Changes --

    M draft-ietf-quic-recovery.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3572.patch
https://github.com/quicwg/base-drafts/pull/3572.diff

-- 
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/pull/3572

---

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 12:24:29 -0700

@ianswett pushed 1 commit.

56a5ef401e3be26ef9b984969673ffcbf016ea39  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/694774d0cc5c88a62d40975221f96ed622ea238d..56a5ef401e3be26ef9b984969673ffcbf016ea39

---

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 12:25:08 -0700

5dfecdf98cece40f60b04b2110e3587ecfde4828  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/56a5ef401e3be26ef9b984969673ffcbf016ea39..5dfecdf98cece40f60b04b2110e3587ecfde4828

---

From: Matt Olson <[email-masked]>
Date: Wed, 08 Apr 2020 16:27:28 -0700

Since RFC4653 doesn't seem like it would map to QUIC as readily as the stuff in the RACK draft about reorder-threshold tuning (it seems to be all about extending the Limited Transmit algorithm), maybe RACK is a better reference?

https://tools.ietf.org/pdf/draft-ietf-tcpm-rack-08.pdf
c.f. "Update RACK reordering window"

-- 
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/pull/3572#issuecomment-611244928

---

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 16:29:20 -0700

I would prefer to reference RACK, but it's not an RFC yet and I'm not sure it will be prior to QUIC shipping.  What's the best way to handle that?

-- 
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/pull/3572#issuecomment-611245479

---

From: Matt Olson <[email-masked]>
Date: Wed, 08 Apr 2020 16:49:44 -0700

The QUIC recovery spec already references the RACK draft in multiple places.

-- 
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/pull/3572#issuecomment-611251048

---

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 17:02:49 -0700

464d19911876512bf66747c79c7c85f0ff911139  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/5dfecdf98cece40f60b04b2110e3587ecfde4828..464d19911876512bf66747c79c7c85f0ff911139

---

From: ianswett <[email-masked]>
Date: Wed, 08 Apr 2020 17:03:31 -0700

Fair point, I replaced the old reference with the RACK reference.  PTAL.

-- 
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/pull/3572#issuecomment-611254795

---

From: Matt Olson <[email-masked]>
Date: Wed, 08 Apr 2020 17:47:44 -0700

LG!

-- 
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/pull/3572#issuecomment-611266885

---

From: Matt Olson <[email-masked]>
Date: Wed, 08 Apr 2020 17:47:58 -0700

@maolson-msft approved this pull request.

-- 
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/pull/3572#pullrequestreview-390423681

---

From: Nick Banks <[email-masked]>
Date: Wed, 08 Apr 2020 17:56:15 -0700

@nibanks approved this pull request.

-- 
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/pull/3572#pullrequestreview-390426016

---

From: ianswett <[email-masked]>
Date: Tue, 14 Apr 2020 15:36:27 -0700

196ecf7da23afd34a11fcc024395a7aa553e74a5  Non-normative

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/464d19911876512bf66747c79c7c85f0ff911139..196ecf7da23afd34a11fcc024395a7aa553e74a5

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 15:37:44 -0700

@martinthomson commented on this pull request.

> @@ -420,8 +420,9 @@ The RECOMMENDED initial value for the packet reordering threshold
 less than 3, to keep in line with TCP {{?RFC5681}}.
 
 Some networks may exhibit higher degrees of reordering, causing a sender to
-detect spurious losses.  Implementers MAY use algorithms developed for TCP, such
-as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience.
+detect spurious losses.  Increasing reordering thresholds after losses
+are spuriously detected have proven useful in TCP, such	as TCP-NCR

```suggestion
are spuriously detected have proven useful in TCP, such as TCP-NCR
```

-- 
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/pull/3572#pullrequestreview-393343080

---

From: ianswett <[email-masked]>
Date: Tue, 14 Apr 2020 15:37:52 -0700

ccd78939eed2efc0329fb41752dec4695d630c83  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/196ecf7da23afd34a11fcc024395a7aa553e74a5..ccd78939eed2efc0329fb41752dec4695d630c83

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 16:29:54 -0700

@martinthomson approved this pull request.

+are spuriously detected have proven useful in TCP, such as TCP-NCR
+{{?RFC4653}}, and are expected to be equally useful in QUIC.

The "such as" is injected at an odd point here, which seems to break up the flow.

```suggestion
detect spurious losses.  Increasing reordering thresholds after losses, as
recommended in TCP-NCR {{?RFC4653}}, have proven to be useful in TCP and are
expected to be equally useful in 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/pull/3572#pullrequestreview-393362608

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 17:46:13 -0700

@janaiyengar commented on this pull request.

Slight rewording

```suggestion
detect spurious losses. Increasing reordering thresholds after spurious
detection of losses can make the transport more robust to reordering,
as TCP-NCR {{?RFC4653}} does for TCP. Such mechanisms are
expected to make QUIC more robust to reordering as well.
```

-- 
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/pull/3572#pullrequestreview-393387097

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 17:47:18 -0700

never mind this -- I like @martinthomson's suggestion better.

-- 
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/pull/3572#discussion_r408517232

---

From: ianswett <[email-masked]>
Date: Sat, 18 Apr 2020 14:51:59 -0700

27e3e87f9d41148ba04c39bde51e3c4030126193  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/ccd78939eed2efc0329fb41752dec4695d630c83..27e3e87f9d41148ba04c39bde51e3c4030126193

---

From: Matt Olson <[email-masked]>
Date: Mon, 20 Apr 2020 11:32:57 -0700

I don't see any conversation in this PR about it, but I see a commit titled simply "non-normative" reverting the reference from RACK back to NCR. It's not a big deal, but I'm just curious about the reasoning.

-- 
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/pull/3572#issuecomment-616734041

---

From: ianswett <[email-masked]>
Date: Thu, 23 Apr 2020 08:30:21 -0700

There's conversation on the issue(https://github.com/quicwg/base-drafts/issues/3571#issuecomment-611350198) and Jana was concerned about adding another reference to RACK as well as recommending something that we don't have a detailed algorithm(and pseudocode) for.  In general, anything we have a SHOULD for has more text(and typically pseudocode) than this, so I accepted that point and adjusted the PR.  For example, the pseudocode doesn't detail how to detect spurious losses, since it's expected that could be fairly complex and implementation dependent.

-- 
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/pull/3572#issuecomment-618465616

---

From: ianswett <[email-masked]>
Date: Thu, 23 Apr 2020 08:31:58 -0700

089f74a748bfa3dc057071e06bf997331d5ab6cc  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/27e3e87f9d41148ba04c39bde51e3c4030126193..089f74a748bfa3dc057071e06bf997331d5ab6cc

---

From: Matt Olson <[email-masked]>
Date: Thu, 23 Apr 2020 10:25:27 -0700

I see, thanks for pointing me to that. But Jana's ask seems to me to be all about SHOULD versus MAY, and orthogonal to referencing NCR vs RACK; if it was a SHOULD, then you'd still have the same incompletely-specified-algorithm problem with NCR. It seems to me that now that SHOULD is removed, Jana would agree that RACK is a better reference since it maps more cleanly to 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/pull/3572#issuecomment-618532843

---

From: Matt Olson <[email-masked]>
Date: Thu, 23 Apr 2020 10:33:49 -0700

Actually, I'm not so confident that RACK maps all that cleanly either, and Jana made the point that RACK's ReoWnd adjustment algorithm hasn't been closely examined, so I'm going to bow out here- I'm happy with either NCR or RACK.

-- 
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/pull/3572#issuecomment-618537698

---

From: ianswett <[email-masked]>
Date: Thu, 30 Apr 2020 08:54:54 -0700

4d3e918fee5ed3468f7a4ee1e67c3f05bbe0236f  QUIC could see more reordering

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3572/files/089f74a748bfa3dc057071e06bf997331d5ab6cc..4d3e918fee5ed3468f7a4ee1e67c3f05bbe0236f