[quicwg/base-drafts] Split stream initial flow control (#1016)

Martin Thomson <notifications@github.com> Thu, 14 December 2017 16:27 UTC

Date: Thu, 14 Dec 2017 08:27:57 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba78e47381deb068182563cf80b58f9dfa3116e4492cf00000001164a688d92a169ce10d16a95@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1016@github.com>
Subject: [quicwg/base-drafts] Split stream initial flow control (#1016)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a32a68da291_2e863f8a7f472f2c26804f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/lSU6rWty_HiNEMh2ZEcnI8pnaF0>

The initial_max_stream_data transport parameter governs three types of stream data:
* data received on unidirectional streams initiated by a peer
* data received on bidirectional streams initiated by a peer
* data received on bidirectional streams initiated by this endpoint

These are currently all controlled by the same transport parameter.  We should consider whether having multiple transport parameters is desirable.  Obviously, having more is desirable, and I could see a fairly good case for just relying on MAX_STREAM_DATA for the last of these, but for streams that are remotely initiated, that is less directly useful.  It seems likely that streams used for different purposes will have different constraints.

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

Re: [quicwg/base-drafts] Split stream initial flo… Martin Thomson
[quicwg/base-drafts] Split stream initial flow co… Martin Thomson
Re: [quicwg/base-drafts] Split stream initial flo… Martin Thomson