Subject: [quicwg/base-drafts] H3 spec fails to warn about initial_max_stream_data_uni (#2589)

From: Christian Huitema <[email-masked]>
Date: Thu, 04 Apr 2019 02:45:50 +0000 (UTC)

If the transport parameter `initial_max_stream_data_uni` is not set, HTTP 3 will just stall. That's because the HTTP3 implementations are supposed to send the "Settings" before sending any request or response, but they can only do that if there are flow control credits for Uni streams. Of course, the HTTP3 spec says that "Both clients and servers SHOULD send a value of three or greater for the QUIC transport parameter initial_max_uni_streams." But it fails to mention that there should be some sensible value for `initial_max_stream_data_uni`.

The bug was found during interop testing between `picoquic` and `ats`. It really is a spec bug. Section 3.1 of the HTTP3 spec has text stating that _"it is recommended that `initial_max_bidi_streams` be no smaller than 100, so as to not unnecessarily limit parallelism."_ I think that we need similar text in section 3.2.

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 03 Apr 2019 19:50:53 -0700

I agree that we should probably recommend sending a non-zero value, but the connection is not supposed to stall in either case. If a peer sends 0 in the transport parameters, it will have to grant flow control credit via MAX_*DATA frames.

-- 
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/2589#issuecomment-479729884

---

From: Christian Huitema <[email-masked]>
Date: Wed, 03 Apr 2019 19:58:37 -0700

@marten-seemann the problem is that if the number of credit is zero, the peer cannot even open the stream. It is not supposed to send a null length stream frame. And if the stream is not even open, the generic transport has no way to know that it should send a MAX_STREAM_DATA frame on stream 2 or 3. An H3 conscious transport might know that, but a generic one not so much -- you don't need credits on stream 2 or 3 for HTTP 1.x or for DNS over HTTP. It seems much preferable to just mandate non zero values in the transport parameters.

-- 
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/2589#issuecomment-479731160

---

From: Marten Seemann <[email-masked]>
Date: Wed, 03 Apr 2019 20:00:36 -0700

@huitema Why can't you open the stream? There's nothing preventing you from opening a stream that you don't have flow control credit for.
You could send a zero-length STREAM frame, or even better, you could send a STREAM_BLOCKED frame.

-- 
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/2589#issuecomment-479731512

---

From: Christian Huitema <[email-masked]>
Date: Thu, 04 Apr 2019 03:17:55 +0000 (UTC)

@marten-seemann I suppose you could send a zero length STREAM frame, although I am pretty sure one of spec says that nodes should not send zero-length stream frames because DOS attacks. STREAM_BLOCKED has a different meaning -- it does not actually open the stream. I suppose that STREAM_DATA_BLOCKED would work. In any case, asking for a sensible initial limit seems much simpler.

-- 
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/2589#issuecomment-479734401

---

From: Marten Seemann <[email-masked]>
Date: Wed, 03 Apr 2019 20:24:46 -0700

STREAM_DATA_BLOCKED is what I meant, sorry. Too many \*_BLOCKED frames. STREAM_BLOCKED doesn't even exist...

I think this is a general issue with either picoquic or ats, and not H3 specific. No matter what the application protocol, a peer can send you 0-values for stream counts and for flow control limits, and the protocol should still work (although slower, since the MAX* frames need to be exchanged). There should never be a deadlock (unless the peer is refusing to grant credits, even at a later point in time).

-- 
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/2589#issuecomment-479735486

---

From: Christian Huitema <[email-masked]>
Date: Wed, 03 Apr 2019 20:45:53 -0700

It is not a "dead" lock. If picoquic does not have credits, it will just wait. If the peer somehow wakes up and provide credit, transmission will resume. In my mind, the transmission of the various "BLOCKED" frames is just optional.

-- 
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/2589#issuecomment-479739149

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 04 Apr 2019 07:55:23 +0000 (UTC)

This is slightly related to #2559 and #2529. IMO there is no easy fix because even if you grant some initial values, there is nothing forcing the endpoint to use the first available unidirectional streams for control streams. The temptation is to set these transport limits quite high in order to just avoid the issue but that prevents the sending endpoint from overwhelming the receiver with a lot of data. An alternative is to set a conservative value for `initial_max_stream_data_uni`, say 8 bytes. This would allow the sender to open a uni stream with a type, the receiver can use this to determine if/how to grant further credits.

-- 
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/2589#issuecomment-479791232

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Apr 2019 18:26:16 +0000 (UTC)

Closed #2589 via #2612.

-- 
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/2589#event-2286542285