Subject: [quicwg/base-drafts] QUIC flow control is not quite like HTTP/2 (#3766)

From: ianswett <[email-masked]>
Date: Mon, 15 Jun 2020 12:32:36 -0700

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

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

-- Commit Summary --

  * QUIC flow control is not quite like HTTP/2

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2020 18:30:36 -0700

@martinthomson approved this pull request.

> @@ -792,10 +792,9 @@ is not excessive buffering at multiple layers.
 
 ## Data Flow Control {#data-flow-control}
 
-QUIC employs a credit-based flow-control scheme similar to that in HTTP/2
-{{?HTTP2}}, where a receiver advertises the number of bytes it is prepared to
-receive on a given stream and for the entire connection.  This leads to two
-levels of data flow control in QUIC:
+QUIC employs a limit-based flow-control scheme similar, where a receiver

```suggestion
QUIC employs a limit-based flow-control scheme where a receiver
```

> -A receiver MAY send MAX_STREAM_DATA frames in multiple packets in order to make
-sure that the sender receives an update before running out of flow control
-credit, even if one of the packets is lost.
-
-A receiver advertises credit for a connection by sending a MAX_DATA frame, which
-indicates the maximum of the sum of the absolute byte offsets of all streams.  A
-receiver maintains a cumulative sum of bytes received on all streams, which is
-used to check for flow control violations. A receiver might use a sum of bytes
-consumed on all streams to determine the maximum data limit to be advertised.
-
-A receiver can advertise a larger offset by sending MAX_STREAM_DATA or MAX_DATA
-frames.  Once a receiver advertises an offset, it MAY advertise a smaller
-offset, but this has no effect.
+frames to the sender to advertise larger limits.
+
+A receiver can advertise a larger limit for a stream by sending a MAX_STREAM_DATA

"can advertise a larger limit" or "can increase the limit for a stream"

> @@ -845,7 +844,7 @@ is flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame when it has no ack-eliciting packets in flight.

-## Flow Credit Increments {#fc-credit}
+## Incrementing Flow Control {#fc-credit}

```suggestion
## Increasing Flow Control Limits {#fc-credit}
```

-- 
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/3766#pullrequestreview-431098081

---

From: Mike Bishop <[email-masked]>
Date: Tue, 16 Jun 2020 15:17:44 -0700

@MikeBishop approved this pull request.

I support Martin's suggestions, but otherwise am fine with 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/3766#pullrequestreview-431930901

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 16 Jun 2020 15:22:17 -0700

@LPardue commented on this pull request.

> +A receiver can advertise a larger limit for a stream by sending a MAX_STREAM_DATA
+frame with the Stream ID field set appropriately.  A MAX_STREAM_DATA frame
+indicates the maximum absolute byte offset of a stream.  A receiver could use the
+current offset of data consumed to determine the flow control offset to be
+advertised. A receiver MAY send MAX_STREAM_DATA frames in multiple packets in
+order to make sure that the sender receives an update before running out of
+flow control, even if one of the packets is lost.
+
+A receiver can advertise a larger limit for a connection by sending a MAX_DATA
+frame, which indicates the maximum of the sum of the absolute byte offsets of
+all streams.  A receiver maintains a cumulative sum of bytes received on all
+streams, which is used to check for flow control violations. A receiver might
+use a sum of bytes consumed on all streams to determine the maximum data limit
+to be advertised.
+
+Once a receiver advertises an offset for the connection or a stream, it MAY

```suggestion
Once a receiver advertises a limit for the connection or a stream, it MAY
```

limit seems more consistent now

-- 
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/3766#pullrequestreview-431933174

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jun 2020 15:23:59 -0700

@martinthomson commented on this pull request.

+advertise a smaller offset, but this has no effect.

```suggestion
advertise a smaller limit, but this has no effect.
```

-- 
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/3766#pullrequestreview-431933917

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Jun 2020 15:25:36 -0700

@janaiyengar commented on this pull request.

 
+advertises the number of bytes it is prepared to receive on a given stream and

```suggestion
advertises the limit of total bytes it is prepared to receive on a given stream or
```

-- 
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/3766#pullrequestreview-431934648

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Jun 2020 15:30:14 -0700

@janaiyengar pushed 1 commit.

dfb94a815e866b84f8a7be38937b73a05ae4c703  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3766/files/bb9e928dcec780905e15821ae806ee5d05364672..dfb94a815e866b84f8a7be38937b73a05ae4c703

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 16 Jun 2020 15:41:10 -0700

@janaiyengar pushed 2 commits.

f654ed92721df0edc218f713a46626049ea71515  reflow
c39e5f0414c81ee03b0005c4e2b6ca984cb4f8c6  space

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3766/files/dfb94a815e866b84f8a7be38937b73a05ae4c703..c39e5f0414c81ee03b0005c4e2b6ca984cb4f8c6

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jun 2020 18:09:22 -0700

Merged #3766 into master.

-- 
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/3766#event-3451406777