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

[Tobias Oberstein <[e-mail]>]

>     Given above, how would the following 2 approaches compare?
>
>     a)
>     - Client 1 <=> Server 1 connected with 2 TCP connections.
>     - TCP autotuning on both client and server OR manually set buffer
>     sizes: small for TCP-1, and large for TCP-2
>     - First TCP _only_ carries "chatty" traffic, and second TCP carries
>     "mass data" traffic.
>
>     b)
>     - Client 1 <=> Server 1 connected with 1 TCP connection
>     - TCP autotuning OR large buffers set system wide
>     - multiplexing done over the single TCP that carries both "chatty"
>     and "mass data" traffic and
>     - the multiplexing is further optimizing buffer size (app level) and
>     does priorization of traffic (chatty = high-prio, mass = low-prio):
>
>     "Compare": I am mostly interested in the end-user experience:
>
>     i) Is the chatty traffic still low-latency, even in the presence of
>     concurrent mass-data traffic?
>
>
> a) it depends on process scheduler and network queue design of the
> server and client, I think. I don't know much about per-socket buffer
> autotuning, but it probably just improves memory usage and throughput
> but doesn't have much effect on latency of chatty traffic?

Improving memory, but not necessarily latency: yep, plausible.

>
> 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?

>
>     ii) Is the throughput of mass-data traffic concurrently to the
>     chatty traffic still (nearly) as high as when only doing mass data
>     transfer?
>
>
> I think minimum delay requirement for the chatty traffic determines
> fragmentation on mass-data traffic regardless it's done in OS's network
> stack or ws-mux code.

Makes sense. The lower the latency requirement, the more fragmentation, 
and the less efficiency on mass data.

>
>      >>How about having a shared Web worker in the background that
>     handles all messaging for the app over a single WS?
>      >One restriction of Web Worker is that we cannot share a worker
>     between webapps with different origins while WebSocket can connect
>     to a host different from its origin.
>
>     Ah, right. Same origin policy. Thus, with WS-MUX, there is _more_
>     potentially TCP sharing than whats possible with shared WebWorkers.
>
>     However, for a given single app (from a single origin) running in
>     multiple browser tabs, the shared WebWorker seems not so bad. Works
>     today. No need for WS-MUX or HTTP 2.0 MUX + WS over HTTP 2.0.
>
>
> Yes. Thanks for reminding us about shared worker approach. We haven't
> evaluated it well.
>
>      >For load balancer vendors, it's better that multiplexing is
>     standardized than each service provider develops its own.
>
>     I don't have experience running G scale infrastructure. However, I'd
>     like to understand why LBs need to have a look into WS at all .. why
>     not Layer-4 LB? Doing balancing based on hash of source IP?
>
>
> 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"?

>
>      >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.

/Tobias