Subject: Unidirectional stream reservation

From: Lucas Pardue <[email-masked]>
Date: Sat, 9 Jun 2018 14:43:44 +0000

Hi,

The discussion in Kista about unidirectional streams focused on not "grabbing" streams that are reserved for control or QPACK. This relates to PR #1359<https://github.com/quicwg/base-drafts/pull/1359>.

I have an HTTP/QUIC extension proposal [1] that would like to use server-initiated unidirectional streams in a dynamic, ad-hoc manner. With the current design, I hoped that I would be ok if I avoided the reserved streams. Well, while working through an implementation, I've realised that HTTP/QUIC server push effectively "grabs" all non-reserved streams. This means that clients would attempt to parse the first byte of my extension stream data as a Push ID, probably succeed, and subsequently rapidly fail.

Patrick made the point in Kista that this is a nice extension point. My view now is that it is necessary, since we can't realistically reserve other stream IDs at a later point and will lose this extension capability.

Lucas

[1]  - https://tools.ietf.org/html/draft-pardue-quic-http-unbound-server-push-00