Subject: [quicwg/base-drafts] Érik Vyncke's Transport Comment 4 (#4527)

From: Lucas Pardue <[email-masked]>
Date: Tue, 05 Jan 2021 19:46:28 -0800

Érik Vyncke said:

> -- Section 4.2 and others  --
> The specification is rather vague about the behavior (no default timer, no
> default "window", nothing said about increasing the credit, ...) and leaves a
> lot to implantations. Is it an issue or is it described in QUIC-RECOVERY ?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 02:09:05 -0800

Yes, the recovery draft includes all the necessary timers (aside from the idle timeout, which I think is adequately covered).  However, if you are talking about flow control specifically, then that does not necessarily need timers.  Other commenters have bemoaned the lack of guidance regarding flow control and it has improved, but the prevailing view of the working group is that it is only a problem if you try to optimize.  So we have what is written, which says that if you want tight flow control limits (in the order of BDP), then you risk performance problems if you don't provide timely updates.

-- 
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/4527#issuecomment-755208934

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Jan 2021 07:42:59 -0800

The willingness to allow more flow control credit is (almost?) always triggered by an event, such as the application reading from the stream; or a stream being reset and the stack deciding to discard the buffered data.  As such, flow control *can* be implemented purely on an event-based basis.  Now, this isn't optimal for performance -- you might not want to generate flow control updates every time one of these events happens, but rather coalesce them -- but that's an optimization that implementations can decide whether and how to pursue.

-- 
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/4527#issuecomment-758032323

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 14:25:29 -0800

Many stacks also increase their buffer allocations in response to increases in perceived BDP.

-- 
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/4527#issuecomment-758263703

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 20:37:46 -0800

As this is an issue the working group has consensus on, I don't think we should change anything.  However, it is more than simply editorial, so I can't close the issue.  I propose that we do though.

-- 
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/4527#issuecomment-758392978

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Jan 2021 00:18:00 -0800

Labelling this as design, but am noting your suggestion to close with no action.

-- 
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/4527#issuecomment-758487896

---

From: David Schinazi <[email-masked]>
Date: Wed, 13 Jan 2021 09:00:43 -0800

I support closing with no action.

-- 
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/4527#issuecomment-759584609