Subject: [hybi] Channel ID encoding of multiplexing extension

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 29 Mar 2012 10:00:00 +0200

In the latest mux extension draft, we're using a new 4-mode integer
encoding for channel ID field.
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03#section-6

ID : field length
0 - : 1 octet
128 (2^7) - : 2 octet
16384 (2^14) - : 3 octet
2097152 (2^21) - 536870912 (2^29 - 1) : 4 octet

It's designed and put in the spec by John considering that distribution of
channel ID would have distribution different from payload.

In the f2f meeting yesterday, Gabriel showed concern about introduction of
a new variable length encoding as we already have 1 a bit complicated
encoding for the payload length.

Here I want to call for opinions and alternative suggestions on this
specific point. Thoughts?

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 29 Mar 2012 10:05:42 +0200

And, John, could you provide some text to explain reasoning to choose this
encoding which we can put in the spec?

Data / thoughts on the expected distribution of the number of concurrent
logical channels are also welcome.

---

From: John Tamplin <[email-masked]>
Date: Thu, 29 Mar 2012 11:51:57 -0400

> logical channels are also welcome.

The idea was simply that many uses would require a small number of
channels, so we wanted a variable-length encoding that made that case as
efficient as possible.  For the upper end, it wasn't clear how many to
support, but with a variable encoding supporting much higher channel ids
has only a tiny cost, as it will likely be represented as a 32-bit int in
implementations anyway.  IIRC, SPDY only supports 4096 channels and I have
no information about how often that became a limitation, but my guess would
be very rare.

Regarding a new variable-length encoding, I initially planned on using the
same length encoding as frame lengths, but I couldn't think of a use for
the unused bit and it has a steep jump when going from 125 channels to 126
channels (1->3 bytes overhead) -- that is a range which seems likely to
achieve in browsers with lots of open tabs, each containing independent
modules with their own connections.

If others would prefer a different encoding, I have no objection.

-- 
John A. Tamplin
Software Engineer (GWT), Google