Re: [hybi] Multiplexing extension spec draft 03

[Takeshi Yoshino <[e-mail]>]

Hello Arman,

On Fri, Mar 23, 2012 at 18:38, Arman Djusupov <[e-mail]> wrote:

> Currently the specification does not make it clear which side assigns a
> channel ID when an AddChannel control message is sent. I think this could
> be made flexible; for example if Objective Channel ID is set to 0 then this
> means that the client prefers the server to select the channel ID, if it is
> greater than 1 then the client requests a specific channel ID.
>
> **
>
> ** **
>
> Giving the client the option to select the channel ID can facilitate the
> use of application-specific channel IDs, where the predefined logical
> channel ID is reserved for a specific role, e.g. 1 - Video channel, 2 -
> Voice channel, 3 - Control channel, 4 - Subtitles channel (optional).
>
Some people were discussing intermediaries with mux capacity which
bundle/unbundle logical channels. Here, your proposal seems to try to use
channel ID values as service identifier (like port number of TCP/UDP). It
doesn't go together with such intermediaries. To make this work, we need to
ensure in the spec that channel ID is preserved between endpoints.

IMO, channel IDs should be hidden to application level and resource or
Sec-WebSocket-Protocol should be used for such mapping instead as well as
WebSocket w/o mux.

Are you also going to use mux to provide multiple channels (e.g. video,
voice, ...) but keep them grouped for one session (e.g. video conference
session consists of them)? If so, we need to ensure in the spec that
logical channels must not be unbundled into separate physical channels.

These new restrictions enables the usage as you described, but also
complicates the spec. For me as one of browser developer, they're
unnecessary. The current mux extension's goal is to provide logical
equivalent of normal WebSocket connections in one TCP connection. Your
proposal is beyond that. I'd like to get more opinions on these points.

> ****
>
> ** **
>
> It is also worth mentioning in the spec that the protocol specified by the
> Sec-WebSocket-Protocol header MAY define a default set of logical channels
> that are considered as being implicitly established when the mux extension
> is agreed. Some protocols, as mentioned above, may require a fixed set of
> channels with predefined IDs. Negotiating the same set of channel IDs using
> an AddChannel request<->response every time a new connection is established
> would not be efficient.
>
Providing a way to open multiple logical connections at once is
interesting. As I said above, basically I prefer to realizing it by adding
some way to issue AddChannel commands (different resources may be used to
tell which service each logical channel wants to access) on handshake.

How about this, for example?

C->S Sec-WebSocket-Extensions: mux; preopen="vc-video, vc-voice,
vc-control, vc-subtitle"
(each comma-separated element in preopen parameter's value means value of
Sec-WebSocket-Protocol)

S->C Sec-WebSocket-Extensions: mux; preopen="vc-video=1, vc-voice=2,
vc-control=3, vc-subtitle=4"
and the server sends back 4 AddChannel responses.

We don't have to pay additional RTT though change on request headers is
limited to Sec-WebSocket-Protocol.

We may also add some grouping annotation.

(OT. I don't want core specs to say that Sec-WebSocket-Protocol has
capability to change WebSocket protocol's behavior. Such modification
should be made using extension framework. Also, for now,
Sec-WebSocket-Protocol is an attribute for each logical channel. I'm
disinclined to invite headers other than Sec-WebSocket-Extensions to
determine physical channel (mux extension)'s behavior.)

> It should be permitted for the “protocol” to imply a default set of
> channels that don’t need to be negotiated (at least this should not be
> against the specification).****
>
> **
>
I don't object to make it able to define/use such preset. Maybe useful.

> **
>
> As an example, when Sec-WebSocket-Protocol set to “smart-playback” would
> mean then once the mux is negotiated the following logical channels are
> considered already established: 1 - Video, 2 - Voice, 3 - Control,  4 -
> Subtitles.****
>
> ** **
>
> I think this would make the specification much more versatile.
>