Subject: [hybi] MUC: channel ID semantics

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2012 13:51:30 +0200

In Paris just now, Takeshi mentioned that a channel ID could be used
as a service identifier by higher-level apps. Could someone perhaps
explain what that means?

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 28 Mar 2012 15:11:21 +0300

This means using the channel ID to identify the type of the service in the
same way as TCP/IP port numbers. Where the application reserves a specific
channel ID for a special use. E.g. channel ID: 1 - voice , 2 - chat, 3 -
video. This is meant to be used by non-browser apps that build their
protocols based on mux to decrease the number of client connections to the
server.

With best regards,
Arman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Saint-Andre
Sent: Wednesday, March 28, 2012 2:52 PM
To: [email-masked]
Subject: [hybi] MUC: channel ID semantics

In Paris just now, Takeshi mentioned that a channel ID could be used as a
service identifier by higher-level apps. Could someone perhaps explain what
that means?

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2012 14:33:57 +0200

> protocols based on mux to decrease the number of client connections to the

I see. So you're assuming that the client will generate the channel IDs,
right?

/psa

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 28 Mar 2012 15:56:57 +0300

As currently designed, it's the client side that assigns the channel ID when sending an AddChannel request.

However even if it's the server side that assigns the channel ID there are still workarounds that would allow similar functionality.

With best regards,
Arman

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 3:34 PM
To: Arman Djusupov
Cc: [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

On 3/28/12 2:11 PM, Arman Djusupov wrote:
> This means using the channel ID to identify the type of the service in 
> the same way as TCP/IP port numbers. Where the application reserves a 
> specific channel ID for a special use. E.g. channel ID: 1 - voice , 2 
> - chat, 3 - video. This is meant to be used by non-browser apps that 
> build their protocols based on mux to decrease the number of client 
> connections to the server.

I see. So you're assuming that the client will generate the channel IDs, right?

/psa

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 28 Mar 2012 15:09:21 +0200

Please note that I'm not going to make channel ID values to be a new
dimension of WebSocket protocol's interface for its users, but just going
to leave channel ID assignment algorithm up to implementors so that some
non-browser apps may assign channel IDs as they like and give some meaning
as Arman described below.

I won't add any new restriction on intermediaries to ensure that channel ID
values are the same on both endpoints. There's no such guarantee. We're
gonna just make WebSocket available for developers of special application
who want to divert WebSocket+MUX for their own service.

Takeshi

On Wed, Mar 28, 2012 at 14:56, Arman Djusupov <[email-masked]> wrote:

> However even if it's the server side that assigns the channel ID there are
> still workarounds that would allow similar functionality.
>
> With best regards,
> Arman
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 15:09:41 +0200

> still workarounds that would allow similar functionality.

If you consider the channel ID to be hop-by-hop only, you eliminate the
need for assignment and you can still let the client open them in a
preference order (if that matters to some apps).

Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 28 Mar 2012 16:20:06 +0300

Thank you. That's exactly what I would like.

With best regards,

Arman

From: Takeshi Yoshino [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 4:09 PM
To: Arman Djusupov
Cc: Peter Saint-Andre; [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

Please note that I'm not going to make channel ID values to be a new
dimension of WebSocket protocol's interface for its users, but just going to
leave channel ID assignment algorithm up to implementors so that some
non-browser apps may assign channel IDs as they like and give some meaning
as Arman described below.

Takeshi

As currently designed, it's the client side that assigns the channel ID when
sending an AddChannel request.

With best regards,
Arman

-----Original Message-----

/psa

---

From: John Tamplin <[email-masked]>
Date: Wed, 28 Mar 2012 09:48:50 -0400

On Wed, Mar 28, 2012 at 9:09 AM, Takeshi Yoshino <[email-masked]>wrote:

> I won't add any new restriction on intermediaries to ensure that channel
> ID values are the same on both endpoints. There's no such guarantee. We're

I'm really not sure what the benefit is if intermediaries aren't required
to preserve channel assignment (and I agree they shouldn't).  If someone
controls both endpoints and the intervening network so they can enforce
such a mapping, then they can already do what they want and if they want to
use a variant of WS that's fine, but it shouldn't constrain what the WS
spec can do.

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

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 28 Mar 2012 17:02:53 +0300

Yes, using the Channel IDs are not strictly necessary, the client can also
use the protocol or any other header during logical channel handshake as a
criteria to specify the type of the service being requested. 

With best regards,
Arman

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 4:10 PM
To: Arman Djusupov
Cc: 'Peter Saint-Andre'; [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

On Wed, Mar 28, 2012 at 03:56:57PM +0300, Arman Djusupov wrote:
> However even if it's the server side that assigns the channel ID there 
> are still workarounds that would allow similar functionality.

If you consider the channel ID to be hop-by-hop only, you eliminate the need
for assignment and you can still let the client open them in a preference
order (if that matters to some apps).

Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 28 Mar 2012 17:18:27 +0300

I would also like to suggest that we make it possible for an entire set of
channels to be established together during/after the physical channel
handshake. This would speed up the creation of logical channels for all
types of clients.

There are various options how to perform this.

a) Include the request for the set of channels into the physical channel
handshake.

b) Use a more advanced format for the AddChannel request. For example it
could specify the number of channels to create using the same handshake, so
that a single handshake results in creating a range of identical logical
channels.

c) When the application needs to create multiple channels with different
settings (e.g. protocol, compression and so on), it should be able to send a
batch of AddChannel requests at once and then wait for each of those
channels to be confirmed by the server.

With best regards,

Arman

---

From: John Tamplin <[email-masked]>
Date: Wed, 28 Mar 2012 10:36:41 -0400

On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov <[email-masked]> wrote:

> types of clients.****
> ** **
> There are various options how to perform this.****
>
> ** **
>
> handshake.****
> ** **
> channels.****
> ** **
> settings (e.g. protocol, compression and so on), it should be able to send
> a batch of AddChannel requests at once and then wait for each of those

Again, this requires changes to the JS API, which isn't the purview of hybi
but rather WHATWG.  With the current JS API, you can only create one
channel at a time, so the only opportunity for bundling AddChannels
together would be if another tab creates a channel at exactly the same time
(or you delay the first request long enough to wait for another one).

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 28 Mar 2012 15:50:23 +0000

Just a note that the API issues were discussed in the f2f today. If there are any such issues (and during the meeting it did not seem to be the case), the WG will coordinate with the W3C webapps WG, which is the organization we liaise with.

As it turns out, they’re in the process of rechartering:

Web Applications Working Group:

http://www.w3.org/2012/03/webapps-proposed-charter.html

If anybody feels strongly that there is any API impact of either the mux or compression, please support such claims.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tamplin
Sent: Wednesday, 28 March, 2012 16:37
To: Arman Djusupov
Cc: [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov <[email-masked]<mailto:[email-masked]>> wrote:
I would also like to suggest that we make it possible for an entire set of channels to be established together during/after the physical channel handshake. This would speed up the creation of logical channels for all types of clients.

a) Include the request for the set of channels into the physical channel handshake.

b) Use a more advanced format for the AddChannel request. For example it could specify the number of channels to create using the same handshake, so that a single handshake results in creating a range of identical logical channels.

c) When the application needs to create multiple channels with different settings (e.g. protocol, compression and so on), it should be able to send a batch of AddChannel requests at once and then wait for each of those channels to be confirmed by the server.

Again, this requires changes to the JS API, which isn't the purview of hybi but rather WHATWG.  With the current JS API, you can only create one channel at a time, so the only opportunity for bundling AddChannels together would be if another tab creates a channel at exactly the same time (or you delay the first request long enough to wait for another one).

---

From: John Tamplin <[email-masked]>
Date: Wed, 28 Mar 2012 14:08:45 -0400

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <
[email-masked]> wrote:

>  If anybody feels strongly that there is any API impact of either the mux
> or compression, please support such claims.
>

I think there should not be at this point, in either one -- which means
that I think exposing the existing of MUX channels (including being able to
open multiple at a time) should be off the table at this point.

In the long term, I suspect we may want to alter the API to let the
application have better control over compression, but I don't think we want
to do that until we have more experience about exactly what is useful.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 22:06:44 +0200

Hi John,

> use a variant of WS that's fine, but it shouldn't constrain what the WS

I wonder whether you have added one extra negation in your first sentence,
since it sounds awkwards to me.

In my opinion, not being required to preserve the channel ID allows MUXes
to easily concentrate multiple incoming WS connections into one single,
which is the most important purpose. For instance, since channel zero is
the raw socket, you want it mapped to another channel when passing via
the muxer to the origin server.

But maybe that's what you already intended to say, so I won't insist :-)

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Wed, 28 Mar 2012 16:32:31 -0400

> But maybe that's what you already intended to say, so I won't insist :-)

My mistake -- what I meant was that I don't think intermediaries should be
required to maintain any mapping.  Indeed, some of the envisioned use-cases
involve an intermediary muxing or demuxing connections, which would
necessarily require mapping channels (since the client controls channel
allocation and doesn't know about other channels the mux max be handling).

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 23:32:47 +0200

> allocation and doesn't know about other channels the mux max be handling).

OK thanks for clarifying, we're clearly in line :-)

Willy

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 29 Mar 2012 10:07:19 +0300

The JS API is just one of the APIs that uses the WebSocket protocol, there are already multiple Java, .NET, Mono, Python  etc. client and server libraries available for Windows, Android, iOS etc. These obviously have their own APIs that do not depend on browser functionality. It doesn’t really matter what is supported by a particular API, it is fine if that API supports a subset of the functionality. A little back JS didn’t support binary data, but that didn't mean that we shouldn't have introduced binary frames. If the JS API cannot support some specific functionality then let it not, but this functionality should be available to other platforms.

With respect, I don’t agree that we should look at any WebSocket related specs using only “Chrome to Google server pool” point of view.

With best regards,

Arman

From: John Tamplin [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; [email-masked]
Subject: Re: [hybi] MUC: channel ID semantics

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <[email-masked]> wrote:

I think there should not be at this point, in either one -- which means that I think exposing the existing of MUX channels (including being able to open multiple at a time) should be off the table at this point.

In the long term, I suspect we may want to alter the API to let the application have better control over compression, but I don't think we want to do that until we have more experience about exactly what is useful.

---

From: John Tamplin <[email-masked]>
Date: Thu, 29 Mar 2012 12:03:39 -0400

On Thu, Mar 29, 2012 at 3:07 AM, Arman Djusupov <[email-masked]> wrote:

> The JS API is just one of the APIs that uses the WebSocket protocol, there
> are already multiple Java, .NET, Mono, Python  etc. client and server
> libraries available for Windows, Android, iOS etc. These obviously have
> their own APIs that do not depend on browser functionality. It doesn’t
> really matter what is supported by a particular API, it is fine if that API
> supports a subset of the functionality. A little back JS didn’t support
> binary data, but that didn't mean that we shouldn't have introduced binary
> frames. If the JS API cannot support some specific functionality then let
> it not, but this functionality should be available to other platforms.
>

If you don't have the limitations of the browser (ie, it may be executing
attacker-controlled code behind a firewall), I am not sure why you would
choose to use WebSockets over other options.

Assuming you do, I still don't think you want to expose the internals of
mux channels to that API -- instead, the client should create a connection
and if that happens to be muxed over an already-established connection then
great, and if not great.

> **
>
> With respect, I don’t agree that we should look at any WebSocket related
> specs using only “Chrome to Google server pool” point of view.
>

Clearly many of the requirements that fed into the design of WebSockets
came from the browser context where the origination of the WS connection
may be from hostile code, but it clearly isn't Chrome or Google specific.
 In fact if you look at my posts about mux in the past, you will see that I
have pushed for scenarios like a mobile carrier or business deploying an
intermediary mux between their clients and the ultimate servers.

---

From: "Arman Djusupov" <[email-masked]>
Date: Fri, 30 Mar 2012 14:42:15 +0300

Hello John,

If you don't have the limitations of the browser (ie, it may be executing attacker-controlled code behind a firewall), I am not sure why you would choose to use WebSockets over other options.

There is no other IETF standard protocol that offers duplex communication, multiplexing and reuse of existing infrastructure. Using a standardized, efficient and well thought out protocol produced by an open process is definitely a better option than building proprietary solutions. The ability to expose a service to all clients universally, including browser applications as well as mobile and desktop applications, is another indisputable benefit of using WS. And of course there is also the benefit of being able to traverse intermediaries with the same ease as HTTP or at least almost.  My view is that of an implementer of client-side and server-side transport components that are used by others developers to build their own clients and servers that communicate over the Internet and so I have to take into account all sides and all requirements ranging from mobile devices to intermediary boxes to enterprise servers.

Assuming you do, I still don't think you want to expose the internals of mux channels to that API -- instead, the client should create a connection and if that happens to be muxed over an already-established connection then great, and if not great.

General purpose protocol features should be discussed even when they are not currently exposed by its API. There is no need for the API to provide all protocol capabilities right from start, more capabilities can be exposed by the API over time, while upgrading a deployed protocol with more functionality is a much harder challenge. In the particular case we are discussing the JS API currently does not allow the allocation of logical channels in batches, but this does not prevent the underlying browser implementation to transparently preallocate batches of logical channels when it can predict that more than one logical channel will be required soon.

I’m not sure that multiplexing should/can be kept completely transparent to in-browser JS applications. There could be use cases when such applications would require exclusive use of the WS connection. So I would expect the API to have a parameter that allow it to specify whether the mux or compression extensions are desired. The use of mux and compression can also be enabled/disabled by the server endpoint, but I doubt that it will be a solution for all cases.

Clearly many of the requirements that fed into the design of WebSockets came from the browser context where the origination of the WS connection may be from hostile code, but it clearly isn't Chrome or Google specific.  In fact if you look at my posts about mux in the past, you will see that I have pushed for scenarios like a mobile carrier or business deploying an intermediary mux between their clients and the ultimate servers.

The only requirement that was fed from the browser context that comes to mind was payload masking, the remaining parts of the WS spec are common requirements for duplex protocols. Actually we had been looking forward to such an IETF standard for many years. Since it’s not just browser specific, features that are welcome by mobile carriers, intermediaries, servers etc. should be taken into account. We cannot predict all possible use cases for all intermediaries and servers so providing flexibility is never a bad idea. Whether these features should be transparent and how they should be exposed to the API is orthogonal...

With best regards,

Arman

---

From: John Tamplin <[email-masked]>
Date: Fri, 30 Mar 2012 11:17:30 -0400

On Fri, Mar 30, 2012 at 7:42 AM, Arman Djusupov <[email-masked]> wrote:

> General purpose protocol features should be discussed even when they are
> not currently exposed by its API. There is no need for the API to provide
> all protocol capabilities right from start, more capabilities can be
> exposed by the API over time, while upgrading a deployed protocol with more
> functionality is a much harder challenge.
>

True, but that may also lead to adding features that are speculative but
turned out never to be used.  Just as in software development, it is often
better to only add functionality only when it is known to be needed rather
than in case it might be needed.

In the case of MUX, it is itself an extension to an established protocol,
so why couldn't batch channel creation be added if it becomes necessary?

> In the particular case we are discussing the JS API currently does not
> allow the allocation of logical channels in batches, but this does not
> prevent the underlying browser implementation to transparently preallocate
> batches of logical channels when it can predict that more than one logical
> channel will be required soon.
>

As for arguing against it now, I think it greatly complicates the protocol
(some examples: how do you represent the parameters of all the channels,
what happens when one of the channels can't be created as requested, DoS
considerations currently blocked by one creation in flight at a time,
complicates buffer space handling, etc) and provides limited benefits.

Predicting more than one logical channel will be needed soon sounds like it
reduces to the halting problem to me, so I wouldn't hold my breath on
anything better than a raw guess.

> I’m not sure that multiplexing should/can be kept completely transparent
> to in-browser JS applications. There could be use cases when such
> applications would require exclusive use of the WS connection. So I would
> expect the API to have a parameter that allow it to specify whether the mux
> or compression extensions are desired. The use of mux and compression can
> also be enabled/disabled by the server endpoint, but I doubt that it will
> be a solution for all cases.
>

I disagree, but it doesn't matter; at hybi we are only discussing the wire
protocol -- if someone wants to build an API that exposes all of that,
fine.  We already leave it up to the client for the choice of when/how to
use MUX, so if you are building your own non-browser client you can already
do as you wish.