Subject: [quicwg/base-drafts] Maximum stream number (#108)

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jan 2017 21:50:34 -0800

QUIC currently permits up to 32 bits of stream number.  This could be increased to 64.

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

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Jan 2017 18:01:18 -0800

+1. Stream ID length is currently represented by 2 bits that encode 8, 16, 24, or 32. We could make this 8, 16, 32, 64.

-- 
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/108#issuecomment-272593056

---

From: ianswett <[email-masked]>
Date: Sat, 14 Jan 2017 11:18:04 -0800

Agreed, we've already come up with a use case for 64 bits of stream ID.

-- 
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/108#issuecomment-272646326

---

From: Mike Bishop <[email-masked]>
Date: Sat, 14 Jan 2017 15:12:00 -0800

HTTP frames will need to update accordingly.

-- 
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/108#issuecomment-272660353

---

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 15 Jan 2017 14:30:35 -0800

@ianswett 

> we've already come up with a use case for 64 bits of stream ID

I think I missed out on something, so could you describe the use case in here (or direct me to where this is described)?

-- 
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/108#issuecomment-272743238

---

From: ianswett <[email-masked]>
Date: Mon, 16 Jan 2017 06:28:02 -0800

The first use case I've discussed(not sure on what list) was WebRTC, where a proposed mapping is to use a stream per audio or video frame.  At that rate, we calculated we'd run out of stream ids after about a day.  Admittedly, we could also just reconnect at that point, so it's not a high priority use case.

-- 
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/108#issuecomment-272874559

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 19 Jan 2017 13:06:02 -0800

Some more explanation from the WebRTC perspective:

With both audio and video at high frame/sample rates and simulcast (multiple resolutions), and then add some high frequency data channel messages, you can easily be in the "500hz" combined territory, which if you're conservative and assume 1B stream IDs available, you end up with:

1B / (500 * 60 * 60 * 24) = 23 days

Which doesn't sound too bad, until you want some realtime data streaming for more than 23 days.

I admit it is an edge case.  Most uses of WebRTC will not be using so many streams, and even if they  did, we could do things like use a new connection ID or re-use stream IDs.  But if it's easy enough to add a few more optional bits of stream IDs, then we can avoid this possibility altogether and leave the flexibility open.  If it's difficult to add those optional bits, then perhaps it's not worth the tradeoff.

-- 
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/108#issuecomment-273898495

---

From: krasic <[email-masked]>
Date: Thu, 19 Jan 2017 13:35:06 -0800

Would it be crazy to just use [HPACK's integer representation](https://tools.ietf.org/html/rfc7541#section-5.1)?

-- 
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/108#issuecomment-273905797

---

From: ianswett <[email-masked]>
Date: Thu, 19 Jan 2017 17:14:43 -0800

@krasic That's a possible option, but we still need to decide if the max stream number is 32 or 64 bits.

-- 
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/108#issuecomment-273949250

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 21 Jan 2017 00:47:16 -0800

SPDY and HTTP/2 use 31 bit stream ID space, and it can be expressed in 32 bit signed integer.
Some languages don't have unsigned types (e.g., Java), so if fully 32 bit space is used, they are forced to use larger data type (e.g., 8 bytes long).
Also there is concern in API compatibility.  I'd like to use the same higher level interface with HTTP/2 and HTTP/QUIC.  Some existing implementations use 32 bit signed int for stream ID (e.g., nghttp2, and netty, possibly more?).  If we go for larger ID space, we need to define different high level APIs for QUIC.
QUIC's 0 RTT connection really makes connection establishment penalty less effective.  Why we need larger ID space?

-- 
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/108#issuecomment-274249056

---

From: ianswett <[email-masked]>
Date: Sun, 22 Jan 2017 08:55:50 -0800

I don't think this issue has much effect on QUIC's HTTP mapping.  It's relatively easy to layer a smaller stream ID space(ie: 31 bits) onto a larger one(ie: 64 bits), and it seems likely the HTTP mapping for QUIC will consume 2 QUIC streams per HTTP stream, so even 32 bits is only 31 for HTTP.

One thought(not sure if it's a good one yet): Allow 64 bit stream ids and use 8, 16, 32, 64 bits in the framing, but negotiate the max stream ID for a given connection in the handshake.  For over 99.9% of connections, more than 32 bits is overkill, but there may be use cases it's really helpful.

-- 
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/108#issuecomment-274342892

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 17:07:48 -0800

Note that at 64-bits, we now have more streams available for use than we have packet numbers.

-- 
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/108#issuecomment-274670056

---

From: ianswett <[email-masked]>
Date: Mon, 23 Jan 2017 17:20:19 -0800

Packet numbers are 64 bits, there's just a bizarre quirk that we can't currently encode the full packet number's 64 bits, only 48 bits of it.  

-- 
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/108#issuecomment-274672170

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 22:41:23 -0800

My point was that some packet numbers can be lost, whereas we require that all stream numbers be 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/108#issuecomment-274722734

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 24 Jan 2017 21:36:57 -0800

I will note that you can easily have more streams than packets -- consider a situation where you send relatively short (100-200 bytes) messages in individual 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/108#issuecomment-275023847

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 22:54:00 -0800

Closed #108.

-- 
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/108#event-937342007

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 22:54:00 -0800

As discussed in Tokyo, we need to make sure that the design of QUIC can support many streams of small objects, but increasing the number needs a more concrete motivation

-- 
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/108#issuecomment-275319691

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jan 2017 22:36:03 -0800

Just to add to this so I don't forget.  Stream numbers could become part of the state commitment that an endpoint makes.  If we increase the space, we also need to account for that in other places.  I'm thinking about nascent QPACK work here, which might need to save stream numbers.  There might be other places where we store stream numbers in addition to the obvious changes to the wire format in mappings.

-- 
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/108#issuecomment-276286521