Subject: [quicwg/base-drafts] Prohibiting server-initiated streams for h3 (#2711)

From: Martin Thomson <[email-masked]>
Date: Thu, 16 May 2019 06:39:41 -0700

> HTTP/3 does not use server-initiated bidirectional streams; clients MUST omit or specify a value of zero for the QUIC transport parameter initial_max_bidi_streams.

I don't think that we need the MUST here.  An extension might want to use those streams.  It should be enough to note that these aren't 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/2711

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 May 2019 06:55:12 -0700

Would thescope of this change include adding text on how core HTTP/3 implementation should treat the reception of data on these streams?

-- 
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/2711#issuecomment-493077603

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 May 2019 08:58:19 -0700

It probably has to, yes.  That's something we generally do with most of our MUST statements anyway.

-- 
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/2711#issuecomment-493127757

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 May 2019 18:30:13 -0700

This might be a transport question, but how should a client respond to a server trying to open a server-initiated bidirectional stream?

Assuming that the client's initial_max_streams_uni is zero, a server would send a STREAMS_BLOCKED frame. In response, the client would send a MAX_STREAMS frame with the value set to zero. However, IIUC, this MAX_STREAMS frame merely indicates that the resource is temporary unavailable. That means that the server would be blocked.

To rephrase, the transport does not provide a way for an endpoint to reject a stream, without letting the peer to actually send a STREAM frame. Are we fine with that?

If we think it as a problem, maybe we should change the definition of initial_max_streams TP. For example, we could specify that the omission of the initial_max_streams TP indicates rejection of the corresponding type of streams being opened (instead of interpreting the omission as "zero").

-- 
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/2711#issuecomment-493285947

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 01:02:17 -0700

I don't think the transport should police what streams are opened beyond managing resource consumption. It may well be, in some other app protocol, that a server is free to open bidi streams, but only if they start with a certain header, or none at all. The  app protocol should make both endpoints agree and what is permitted and police accordingly. An application layer could have credits similar to MAX_STREAMS to permit opening certain streams with or without a header. The transport need not deal with this.

-- 
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/2711#issuecomment-493361587

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 May 2019 03:35:10 -0700

Right.  The transport only needs to concern itself with policing stream limits.  The question here is more about how the use of h3 constrains future extension.  As Mikkel says, if there is a use for the server-initiated streams, we shouldn't constrain that.

-- 
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/2711#issuecomment-493407812

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 May 2019 17:57:32 +0000 (UTC)

On the other hand, an extension could modify this requirement, too.  Much of what's in the base spec is for the unextended protocol, and I think this is an instance of that.

However, this is a MUST which we don't permit the server to enforce, which argues for making it a SHOULD instead.  Maybe SHOULD omit/zero, "unless an extension which defines their use is being offered."?

-- 
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/2711#issuecomment-493543718

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 10:59:45 -0700

MUST not accept any bidirectional streams that are not explicitly permitted by extensions.

I'm not sure about stream header formats here - it would be easy to create conflicts across extensions.

-- 
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/2711#issuecomment-493544437

---

From: Victor Vasiliev <[email-masked]>
Date: Thu, 23 May 2019 05:33:55 -0700

I'd suggest we define those to be the same format as client-initiated ones, and use a column in IANA registry for listing which party can be the initiator.  This way, extensions get a uniform way of defining those streams.

-- 
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/2711#issuecomment-495199541