Subject: [QUIC] Stream ID: 32 or 31 bits?

From: "Aron ." <[email-masked]>
Date: Tue, 22 Nov 2016 10:09:12 -0500

Hello,

Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01]
states:

Streams are identified by an unsigned 32-bit integer, referred to as the
> StreamID.

Section 5.1.1 (p. 21) of RFC 7540 says that

Streams are identified with an unsigned 31-bit integer.

The format of frames QUIC uses on Stream 3 is the same as in HTTP/2,
seemingly creating a conflict.

Is this a conflict?  If so, how do we resolve it?

Thanks,

  Aron.

---

From: Ian Swett <[email-masked]>
Date: Tue, 22 Nov 2016 12:43:05 -0500

I think that is something for the HTTP2 mapping document to answer.  As
long as QUIC has more than enough stream ids to represent the full 31 bit
space, I don't anticipate any problems.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Nov 2016 18:41:20 +0000

Only somewhat – there are QUIC streams that will never be referenced by the current mapping, but since the reverse isn’t true, that’s merely sub-optimal.

In my opinion, we fix that by getting rid of the HTTP/2 muxing layer entirely and updating the other frames that reference streams to match the size of QUIC streams.  But we'll need to discuss that.

Sent from my Windows 10 phone

From: Aron .<mailto:[email-masked]>
Sent: Tuesday, November 22, 2016 10:09 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [QUIC] Stream ID: 32 or 31 bits?

Hello,

Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01] states:

Streams are identified by an unsigned 32-bit integer, referred to as the StreamID.

The format of frames QUIC uses on Stream 3 is the same as in HTTP/2, seemingly creating a conflict.

Thanks,

  Aron.