Subject: [quicwg/base-drafts] Two reasons to exceed bytes in flight (#4004)

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Aug 2020 21:53:33 -0700

It might pay to reconcile:

> An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see
{{vars-of-interest}}) to be larger than the congestion window, unless the packet
is sent on a PTO timer expiration; see {{pto}}.

And

> When entering recovery, a single packet MAY be sent even if bytes in flight
now exceeds the recently reduced congestion window.

Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.

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

---

From: Marten Seemann <[email-masked]>
Date: Sun, 16 Aug 2020 23:25:27 -0700

Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?

-- 
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/4004#issuecomment-674685176

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Aug 2020 23:45:25 -0700

That sentence is the the definition of the [recovery period](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-7.5-3).  We haven't implemented that either, and I was wondering if it truly helps.

-- 
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/4004#issuecomment-674693657

---

From: mirjak <[email-masked]>
Date: Mon, 17 Aug 2020 02:31:28 -0700

For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for 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/4004#issuecomment-674771574

---

From: ianswett <[email-masked]>
Date: Mon, 17 Aug 2020 06:48:21 -0700

The second sentence was added later in #3483, and the MUST wasn't updated, so I'll fix that.

Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going.  I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.

-- 
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/4004#issuecomment-674892606

---

From: mirjak <[email-masked]>
Date: Mon, 17 Aug 2020 07:02:57 -0700

#3483 seems to be the wrong issue you are pointed to...

-- 
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/4004#issuecomment-674900573

---

From: ianswett <[email-masked]>
Date: Mon, 17 Aug 2020 14:04:20 +0000 (UTC)

Good catch, it's #3443

-- 
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/4004#issuecomment-674901354

---

From: ianswett <[email-masked]>
Date: Tue, 18 Aug 2020 16:02:28 -0700

Closed #4004 via #4006.

-- 
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/4004#event-3668425000