Subject: [quicwg/base-drafts] Applications and Stream IDs (#910)

From: Mike Bishop <[email-masked]>
Date: Sat, 11 Nov 2017 08:07:16 +0000 (UTC)

@nibanks previously proposed a QUIC API that didn't expose specific Stream IDs to applications.  That doesn't actually work for HTTP/QUIC as currently defined, but there are only two places where the HTTP/QUIC implementation needs to reference a Stream ID.

- PRIORITY frames reference requests by Stream ID.  The solution to this would be to expand #701 to use a Request ID for client-initiated requests as well as Push ID.  (At first glance, these don't need to be throttled since QUIC MAX_STREAM_ID effectively controls this.)
- The long-lived control stream is a specific stream ID.  This could be eliminated by putting a stream header (again, &agrave; la #701) on unidirectional streams that identifies them as control streams.  We still need the control stream to be unique to support order-dependent frames like PRIORITY.

If HTTP goes this direction, there's an associated question for the abstraction design team as to whether we want to explicitly recommend that the Stream ID is always an internal property of the transport.  (This would make it easier to make changes to Stream IDs and how they work in future versions, incidentally.)

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

---

From: Nick Banks <[email-masked]>
Date: Sat, 11 Nov 2017 15:32:45 +0000 (UTC)

I'd like to qualify my proposal to say that the `stream = connection.OpenNewStream(type)` API would just internally create a new stream with the next available ID for the given type (unidirectional or bidirectional) and wouldn't indicate the Stream ID to the application by default. But instead there would just be a helper function on the Stream to query the ID, `stream.GetID()` for instance.

Would this be enough? Essentially that API would only support creating stream in order, as far as the ID space goes.

-- 
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/910#issuecomment-343672959

---

From: Mike Bishop <[email-masked]>
Date: Sat, 11 Nov 2017 20:23:31 +0000 (UTC)

I think that would be enough to implement HTTP/QUIC now, provided that the HTTP layer ensures the first created unidirectional streams are for the control streams.  So the question becomes whether there's a desire for more isolation than that in HTTP.

-- 
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/910#issuecomment-343691598