Subject: [quicwg/base-drafts] Split initial MAX_STREAM_DATA transport parameters (#1542)

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jul 2018 19:15:33 -0700

This splits the one parameter into three and makes each optional, with a
default of 0.

Closes #1016.

(Separately, I'm convinced that we want to do some defragmentation of codepoints when we get the chance.  It might be unpleasant on those tracking the spec, but better that than what this sort of change produces.)
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Split initial MAX_STREAM_DATA transport parameters

-- File Changes --

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

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Jul 2018 20:30:57 -0700

MikeBishop approved this pull request.

Minor nits.

> @@ -1525,6 +1519,36 @@ initial_max_uni_streams (0x0008):
   equivalent to receiving a MAX_STREAM_ID containing 18 when received by a
   client or 19 when received by a server.
 
+initial_max_stream_data_bidi_local (0x0000):
+
+: The initial stream maximum data for bidirectional, local streams parameter

The verbage we've used elsewhere is "[server|client]-initiated [bi|uni]directional," I think.  Obviously we can't do exactly that with these, but perhaps "locally-initiated bidirectional" and "peer-initiated bidirectional" would be closer?

> +  created bidirectional stream opened by the endpoint that sets the transport
+  parameter.  This parameter is encoded as an unsigned 32-bit integer in units
+  of octets.  This is equivalent to a MAX_STREAM_DATA frame
+  ({{frame-max-stream-data}}) being sent on those streams immediately after
+  opening.  In client transport parameters, this applies to streams with an
+  identifier ending in 0x0; in server transport parameters, this applies to
+  streams ending in 0x1.  This parameter defaults to 0 if absent.
+
+initial_max_stream_data_bidi_remote (0x000a):
+
+: The initial stream maximum data for bidirectional, remote streams parameter is
+  equivalent to the initial_max_stream_data_bidi_local parameter, but it applies
+  instead to bidirectional streams initiated by a remote peer.  In client
+  transport parameters, this applies to streams with an identifier ending in
+  0x1; in server transport parameters, this applies to streams ending in 0x0.
+  Thisparameter defaults to 0 if absent.

Missing space.

> +  identifier ending in 0x0; in server transport parameters, this applies to
+  streams ending in 0x1.  This parameter defaults to 0 if absent.
+
+initial_max_stream_data_bidi_remote (0x000a):
+
+: The initial stream maximum data for bidirectional, remote streams parameter is
+  equivalent to the initial_max_stream_data_bidi_local parameter, but it applies
+  instead to bidirectional streams initiated by a remote peer.  In client
+  transport parameters, this applies to streams with an identifier ending in
+  0x1; in server transport parameters, this applies to streams ending in 0x0.
+  Thisparameter defaults to 0 if absent.
+
+initial_max_stream_data_uni (0x000b):
+
+: The initial stream maximum data for bidirectional, remote streams parameter is
+  equivalent to the initial_max_stream_data_bidi_local parameter, but it applies

Having these two be "equivalent to" the first one feels a little odd, since there's nothing particularly special about the first one over the others.  I'd be tempted to either repeat the verbiage in each, or pull it out to an unbulleted paragraph that introduces these three as a related group.

-- 
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/1542#pullrequestreview-135663657

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jul 2018 21:24:41 -0700

@martinthomson pushed 1 commit.

48d054f  Restructure and refactor description

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1542/files/8b1b3259cc85e45c1253b65774c7490b971c17fb..48d054f011ef3b853144b9dd222024bee885ed00

---

From: ianswett <[email-masked]>
Date: Tue, 10 Jul 2018 07:28:31 -0700

ianswett commented on this pull request.

> +  identifier ending in 0x1; in server transport parameters, this applies to
+  streams ending in 0x0.
+
+initial_max_stream_data_uni (0x000b):
+
+: The initial stream maximum data for unidirectional streams parameter contains
+  the initial flow control limit for newly created unidirectional streams opened
+  by the endpoint that receives the transport parameter.  In client transport
+  parameters, this applies to streams with an identifier ending in 0x3; in
+  server transport parameters, this applies to streams ending in 0x2.
+
+If present, transport parameters that set initial flow control limits are
+equivalent to sending a MAX_STREAM_DATA frame ({{frame-max-stream-data}}) on
+every stream of the corresponding type immediately after opening.  If the
+transport parameter is absent, streams of that type start with a flow control
+limit of 0.

Is 0 practical?  Does that mean I can send an stream frame with a 0 byte payload, but nothing else?

-- 
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/1542#pullrequestreview-135851048

---

From: Marten Seemann <[email-masked]>
Date: Tue, 10 Jul 2018 07:40:18 -0700

marten-seemann commented on this pull request.

+  streams ending in 0x0.
+

That's actually the only way to open a new unidirectional stream in that case. I'm not sure if I like it, since it adds another special case to my STREAM frame sending logic, since I usually never send empty STREAM frames, but I **have** to do it in this case.

-- 
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/1542#discussion_r201369330

---

From: MikkelFJ <[email-masked]>
Date: Tue, 10 Jul 2018 07:53:27 -0700

mikkelfj commented on this pull request.

+  streams ending in 0x0.
+

add one to the byte size of each stream packet when computing limits, or any frame contributing to flow control.

-- 
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/1542#discussion_r201374888

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 10 Jul 2018 07:53:34 -0700

LPardue commented on this pull request.

+  streams ending in 0x0.
+

For the HTTP/QUIC case it be more useful to have max data equivalent to 8 bits, so as to enable the creation of a stream with its type. However, I know that is not a general transport feature...

-- 
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/1542#discussion_r201374933

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 11:40:14 -0700

MikeBishop commented on this pull request.

+  streams ending in 0x0.
+

I don't really know that *anything* would be practical here.  If you don't permit streams of this type, it's moot.  If you do permit streams of this type, you want a particular value and will probably send it as part of your settings.  But if you omit it, what is the peer allowed to send?  I don't think the goal is to pick a value that would encourage implementations to skip sending this parameter, just to not have it be undefined.

Zero is fine.  So is 4KB.  So is infinity.  Real implementations will send a value for any stream they intend to open.

-- 
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/1542#discussion_r201451938

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 23:39:14 +0000 (UTC)

MikeBishop requested changes on this pull request.

You'll need to fix the reference to these TPs on lines 1624-1625, too.

-- 
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/1542#pullrequestreview-136048204

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 20:52:30 -0700

martinthomson commented on this pull request.

+  streams ending in 0x0.
+

You can send STREAM_BLOCKED on any stream that you can open, but no otherwise send on.  That has the effect of opening the stream.  You don't have to send an empty STREAM frame.

As @LPardue says, there are values that might be better than others as an absolute minimum.  For instance, knowing the type of unidirectional stream is probably better than knowing nothing at all, but we have to trust that implementations provide starting flow control limits that make sense for them.  They have to deal with the consequences, after all.

0 was a valid value in the past, so we're not dealing with anything new here, except to the extent that defaults matter.

-- 
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/1542#discussion_r201558190

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 21:00:53 -0700

@martinthomson pushed 2 commits.

67278eb  Explaining this was harder than I realized
83a15cd  More fixups

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1542/files/48d054f011ef3b853144b9dd222024bee885ed00..83a15cdd1be5ff3b6f287adf9af2abb96dd7b2ef

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 21:01:30 -0700

Thanks for catching those omissions Mike.  The 0-RTT section was harder than expected, probably more than necessary, but I sorted something out.

-- 
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/1542#issuecomment-404037922

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 22:56:08 -0700

-- 
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/1542#pullrequestreview-136098292

---

From: ianswett <[email-masked]>
Date: Wed, 11 Jul 2018 06:35:07 -0700

ianswett approved this pull request.

-- 
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/1542#pullrequestreview-136240462

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 16:54:16 -0700

Merged #1542.

-- 
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/1542#event-1729167273