Subject: [quicwg/base-drafts] initial_max_stream_data_bidi_remote is a very capable foot gun (#1720)

From: Christian Huitema <[email-masked]>
Date: Tue, 04 Sep 2018 18:53:55 -0700

Draft 14 splits the definition of "initial_max_stream_data" into two parameters, "initial_max_stream_data_bidi_local(0)" and "initial_max_stream_data_bidi_remote(10)". In early interop tests, we observed an interesting failure to communicate between the picoquic client and the winquic server because of that. Winquic server did not provide a value for the initial_max_stream_data_bidi_remote parameter, which meant that for client initiated streams like stream 0 the initial value of was 0. As a result, picoquic did not send any data on stream zero, the stream zero was not opened, winquic did not send back any update for the stream 0 MAX_STREAM_DATA value, the server did not receive any request from the client, and after a suitable period of silence the connection was closed.

I would suggest two fixes:

1) Explain that servers that expect to receive messages such as HTTP requests from clients SHOULD send the "initial_max_stream_data_bidi_remote(10)" parameter and set it to a reasonable value.

2) Explain that if a client wants to open a stream but initial_max_stream_data_bidi_remote value is 0, it SHOULD send an empty STREAM frame to open the stream -- and give the server a chance to send back MAX_STREAM_DATA update for that stream.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Sep 2018 19:32:19 -0700

Not sure if this belongs in http or transport.

-- 
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/1720#issuecomment-418579808

---

From: ianswett <[email-masked]>
Date: Tue, 04 Sep 2018 19:55:51 -0700

I'd say the first suggestion should become a MUST in the http draft.  Not advertising a reasonable value for initial_max_stream_data_bidi_remote should not be allowed, though I realize there's a wide range of what 'reasonable' is.  Possibly 1024 bytes is a bare minimum?

-- 
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/1720#issuecomment-418583335

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Sep 2018 20:54:06 -0700

Any of these settings could be 0 if the intent is to update immediately after connection or stream establishment.  Values might be updated based on SETTINGS, for instance.  But 0 is rarely the right choice if that type of stream is intended to be used.

-- 
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/1720#issuecomment-418591346

---

From: Mike Bishop <[email-masked]>
Date: Mon, 10 Sep 2018 21:01:56 +0000 (UTC)

The HTTP layer on the client is presumably offering bytes to the transport, so the transport should handle this like normal, no?  If it has bytes it can't send, it sends STREAM_BLOCKED to signal that state.  So I'd be inclined to recommend that rather than the empty STREAM frame, though I think the state machine effect is the same either way.

-- 
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/1720#issuecomment-420059730

---

From: Christian Huitema <[email-masked]>
Date: Fri, 14 Sep 2018 15:18:17 -0700

Sending the STREAM_BLOCKED frame facilitates diagnostic, but it does not solve the issue. Stream blocked frames are informational, and many implementations just ignore them.

-- 
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/1720#issuecomment-421498732

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Sep 2018 08:19:55 -0700

I do not have a strong opinion on the issue, but let me note that the same issue exists with max_stream_id_*.

-- 
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/1720#issuecomment-422057174

---

From: Mike Bishop <[email-masked]>
Date: Fri, 28 Sep 2018 14:51:27 -0700

Closed #1720 via #1806.

-- 
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/1720#event-1874534350