Subject: [quicwg/base-drafts] clarify that persistent congestion is a contigous loss across all PN spaces (#3940)

From: Kazuho Oku <[email-masked]>
Date: Tue, 21 Jul 2020 21:53:44 -0700

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

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

-- Commit Summary --

  * clarify that persistent congestion is a contigous loss across all PN spaces

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3940.patch
https://github.com/quicwg/base-drafts/pull/3940.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/3940

---

From: Marten Seemann <[email-masked]>
Date: Tue, 21 Jul 2020 22:23:09 -0700

@marten-seemann requested changes on this pull request.

I'm not sure this actually clarifies how to declare persistent congestion when ACKs are received for multiple packet number spaces. That is, I wouldn't know how to implement `InPersistentCongestion` based on this text.

-- 
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/3940#pullrequestreview-453002297

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 Jul 2020 17:53:55 -0700

@marten-seemann It sounds like that your complaint is not against the change in this PR by itself. Reading your comments on #3939 it is my understanding that you think the change to the text is fine.

I'd assume that your complaint is rather about the pseudo-code not clarifying how QUIC stacks can implement `InPersistentCongestion`.

Regarding how, I could well be wrong, but I think it is not that difficult to implement InPersistentCongestion (see https://github.com/quicwg/base-drafts/pull/3889#discussion_r459160599).

I am positive to adding a description regarding how QUIC stacks might implement InPersistentCongestion, though I am not sure if we can come up with a pseudo-code that explains the algorithm linked above, considering the fact that we do not describe how an endpoint might implement a sentmap. So maybe adding a few lines of comments to the pseudo-code would be a good thing to do.

-- 
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/3940#issuecomment-662769117

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2020 20:48:07 -0700

@martinthomson approved this pull request.

These are unrelated changes, but I re-read the text and I think that it could be better.

The core change is fine.

> +network is considered to be experiencing persistent congestion.  Commonly, this
+can be established by consecutive PTOs, but since the PTO timer is reset when a
+new ack-eliciting packet is sent, an explicit duration must be used to account
+for those cases where PTOs do not occur or are substantially delayed. The

This business about establishing PC using PTO is really confusing and I would remove this sentence.

```suggestion
network is considered to be experiencing persistent congestion.  The
```

> -sent over a long enough period of time, the network is considered to be
-experiencing persistent congestion.  Commonly, this can be established by
-consecutive PTOs, but since the PTO timer is reset when a new ack-eliciting
-packet is sent, an explicit duration must be used to account for those cases
-where PTOs do not occur or are substantially delayed. The rationale for this
-threshold is to enable a sender to use initial PTOs for aggressive probing, as
-TCP does with Tail Loss Probe (TLP; see {{RACK}}), before establishing
-persistent congestion, as TCP does with a Retransmission Timeout (RTO; see
-{{?RFC5681}}). The RECOMMENDED value for kPersistentCongestionThreshold is 3,
-which is approximately equivalent to two TLPs before an RTO in TCP.
+sent over a long enough period of time across all the packet number spaces, the
+network is considered to be experiencing persistent congestion.  Commonly, this
+can be established by consecutive PTOs, but since the PTO timer is reset when a
+new ack-eliciting packet is sent, an explicit duration must be used to account
+for those cases where PTOs do not occur or are substantially delayed. The
+rationale for this threshold is to enable a sender to use initial PTOs for

```suggestion
rationale for this threshold is to allow a sender to initially use PTOs for
```

-- 
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/3940#pullrequestreview-453819975

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 Jul 2020 21:34:33 -0700

@kazuho pushed 1 commit.

38372f2ed3e7c00327ad75a0b32ef12c2929e105  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/3940/files/19f1b795dfbd56435c7fa8798e94076bd383cd8b..38372f2ed3e7c00327ad75a0b32ef12c2929e105

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 Jul 2020 21:34:41 -0700

@kazuho pushed 1 commit.

817fe3b38a23123cb39b0b4d7ec8e9378a9cf240  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/3940/files/38372f2ed3e7c00327ad75a0b32ef12c2929e105..817fe3b38a23123cb39b0b4d7ec8e9378a9cf240

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 Jul 2020 21:35:43 -0700

@kazuho commented on this pull request.

I'm not the editor, but I think I agree. The rationale for choosing 3 as the multiplier is explained below. That's sufficient.

-- 
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/3940#discussion_r459209779

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 28 Jul 2020 11:23:19 -0700

#3961 subsumes this.

-- 
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/3940#issuecomment-665200932