Subject: [quicwg/base-drafts] Adjust autotuning recommendations (#2240)

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 21:02:14 -0800

This doesn't need normative text.

This adds @ianswett's recommendation about only sending flow control
frames when there are other frames to send.  Though I added another note
about the peer being explicitly blocked, which I think is a useful
transition to the next paragraph.

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

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

-- Commit Summary --

  * Adjust autotuning recommendations

-- File Changes --

    M draft-ietf-quic-transport.md (6)

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 20 Dec 2018 21:17:57 -0800

marten-seemann requested changes on this pull request.

It takes one RTT for the sender to learn that the receiver is blocked and to grant additional flow control credit, so this will lead to frequent stalls of the connection, if one receiver has nothing else to send.

-- 
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/2240#pullrequestreview-187274727

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 21:35:44 -0800

I don't think so.  Flow control credits can go out with acknowledgments.  The advice is there so that you don't have the MAX_DATA frame go out immediately, with a delayed ACK going out 20ms later.  They can both go out together.

-- 
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/2240#issuecomment-449260477

---

From: Marten Seemann <[email-masked]>
Date: Thu, 20 Dec 2018 21:38:55 -0800

Bundling frames definitely makes sense, but I don’t think we need the “or when a peer is blocked” part. 

-- 
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/2240#issuecomment-449260881

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 21:55:16 -0800

Your assertion being that a blocked peer will already have to live with being blocked for a round trip, so the gain isn't worth documenting?

-- 
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/2240#issuecomment-449264606

---

From: Marten Seemann <[email-masked]>
Date: Thu, 20 Dec 2018 22:03:47 -0800

I’m saying that you shouldn’t let your peer become blocked under normal circumstances.
I just noticed that in the corner case where the peer is blocked because the application is consuming data too slowly, it actually makes sense to not bundle the flow control update. So I guess the text is fine as is. 

-- 
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/2240#issuecomment-449266761

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 02:30:03 -0800

The text just says that sending more packets causes more packets to be sent. That is kind of obvious.

Also, sending flow control with other frames isn't working if there isn't anything to ACK or anything to send once the application gets around to drain its buffer and inform transport about more credits.

-- 
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/2240#issuecomment-449351527

---

From: janaiyengar <[email-masked]>
Date: Fri, 21 Dec 2018 20:13:16 +0000 (UTC)

janaiyengar commented on this pull request.

>  advertised additional credit based on a round-trip time estimate and the rate at
 which the receiving application consumes data, similar to common TCP
-implementations.
+implementations.  Sending frames related to flow control only when there are
+other frames to send or when a peer is blocked ensures that flow control doesn't

This sentence is very vague, and I'm not sure I find it useful. What issue is it tackling?

-- 
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/2240#pullrequestreview-187525404

---

From: ianswett <[email-masked]>
Date: Fri, 21 Dec 2018 13:09:37 -0800

ianswett approved this pull request.

It's an optimization I've suggested a few times to ensure sending more frequent updates doesn't have substantial overhead.

-- 
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/2240#pullrequestreview-187539327