Subject: [quicwg/base-drafts] Add LIMIT_UPDATE and replaces concurrent stream limit (#421)

From: Mike Bishop <[email-masked]>
Date: Wed, 29 Mar 2017 09:20:59 -0700

Fixes #419.  I largely copied the WINDOW_UPDATE language.  It might actually be cleaner to recast this as a third level of flow control:  Bytes on streams, bytes on connection, streams on connection.  That would let us consolidate some of the duplicated language.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add LIMIT_UPDATE and replaces concurrent stream limit

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 29 Mar 2017 09:38:06 -0700

marten-seemann commented on this pull request.

> @@ -2405,6 +2433,20 @@ A receiver MAY use an autotuning mechanism to tune the size of the offset
 increment to advertise based on a roundtrip time estimate and the rate at which
 the receiving application consumes data, similar to common TCP implementations.
 
+### Stream Limit Increment
+
+As with flow control, this document leaves when and how many streams to make
+available to a peer via LIMIT_UPDATE to the implementation, but offers a few
+considerations. LIMIT_UPDATE frames constitute overhead, and therefore, sending
+a LIMIT_UPDATE with small offset increments is undesirable.  At the same time,

The only case where this is a noticeable overhead is when each stream is only used to transfer a small number of bytes, e.g. in the often cited case of video streaming where every frame consumes a stream. For HTTP (and probably all other use cases) sending the 5 bytes consumed by the LIMIT_UPDATE frame will be negligible.

-- 
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/421#pullrequestreview-29776166

---

From: Marten Seemann <[email-masked]>
Date: Wed, 29 Mar 2017 09:39:40 -0700

+### Stream Limit Increment
+
+As with flow control, this document leaves when and how many streams to make
+available to a peer via LIMIT_UPDATE to the implementation, but offers a few
+considerations. LIMIT_UPDATE frames constitute overhead, and therefore, sending
+a LIMIT_UPDATE with small offset increments is undesirable.  At the same time,
+withholding LIMIT_UPDATES prevents the peer from fully utilizing the transport.
+Implementations must find the correct tradeoff between these sides to determine
+how large an offset increment to send in a WINDOW_UPDATE.
+
+A receiver MAY adjust the number of permitted streams not in the "closed" state
+based on current activity, system conditions, and other environmental factors.

Better: the maximum StreamID.

-- 
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/421#pullrequestreview-29776543

---

From: Mike Bishop <[email-masked]>
Date: Wed, 29 Mar 2017 12:15:26 -0700

@MikeBishop pushed 1 commit.

7e587bb  Not much overhead

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/421/files/8f698ebb334161cfcfdbcf89ac52f98e14cc5569..7e587bb7a00bd5d1697ce4507bc042ff2118b2a5

---

From: ianswett <[email-masked]>
Date: Fri, 31 Mar 2017 14:59:33 -0700

ianswett commented on this pull request.

High level question: Is there any way we could easily fold this into the WINDOW_UPDATE frame?

I'm blanking on ideas at the moment, but it would be nice.

-- 
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/421#pullrequestreview-30354856