Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Takeshi Yoshino <[e-mail]>]

On Thu, May 30, 2013 at 8:28 PM, Tobias Oberstein <
[e-mail]> wrote:

> b) the endpoints need to cut mass data into smaller chunks to reserve
>>
> slots for inserting chatty traffic. e.g. if acceptable delay for chatty
>> traffic is x ms, set the maximum send unit of mass traffic to (current
>> through put) * x.
>>
>> To allow one to control the peer's message scheduling, both per-socket
>> buffer size and ws-mux flow control are insufficient, I think. Needs to
>> exchange ToS info.
>>
>
> I now can see that flow control and priorization are somewhat orthogonal
> issues.
>
> Priorization and ToS is not goal of WS-MUX at all?
>
>
It's again, as I said in reply to Simone's comment above, it depends on
frequency and usage if we should have WebSocket protocol level ToS or
should just do it in JS.

...


>> Traffic for various services would be multiplexed into one TCP. We wanna
>> demultiplex it and forward to designated backends. This means that
>> there're again lots of TCP connections between LB-backends, but we can
>> make any optimization there as we want.
>>
>
> I see. So the load-balancer needs to be a layer-7 one, and not only be
> WS-MUX enabled, but also app/service aware? Something like this:
>
> E.g. user has 2 tabs open which (logically) connect to
>
> wss://google.com/gmail
> wss://google.com/gplus
>
> Both would be transported over 1 physical WS (via WS-MUX).
>
> The LB would demux traffic for logical channel
>
> wss://google.com/gmail
>
> to backend nodes of cluster "GMAIL", while it would demux traffic for
>
> wss://google.com/gplus
>
> to backend nodes of cluster "GPLUS"?
>
>
Yes.


>
>
>>      >Basically multiplexing should be done as close to network as
>>     possible. If it's done in application layer, for example when
>>     compression is used, such a load balancer need to decode the
>>     compression to see the >multiplexing information. That doesn't make
>>     them happy.
>>
>>     This seems to assume that
>>
>>     - either the LB is done above layer 4 and/or
>>     - the logical WS connections contained in the physical WS would need
>>     to be balanced to _different_ backend nodes.
>>
>>
>> Yes. Sorry that we haven't told the story in our mind in detail.
>>
>
> I think it might be helpful to add text to the MUX draft that describe the
> use cases WS-MUX addresses and how it improves thing over alternatives.
> Motivation is always good and helps by providing context and examples.


OK.