Subject: [hybi] Simplify WebSocket multiplexing

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 30 May 2013 16:16:38 +0900

(Branching from the thread "Call for interest: multiplexing dedicated for
WebSocket")

It seemed that we had rough consensus on accelerating WebSocket dedicated
multiplexing by simplifying it if we keep working on it.

I'd like to hear your opinion on this in this separate thread. Below listed
some points we could drop/simplify including both ones suggested in the
thread and some I came up with now.

1) Header delta encoding in AddChannelRequest
2) Header delta encoding in AddChannelResponse
3) Channel slot
4) Only one mux control in one message
5) Use the length encoding for encoding mux channel ID
6) Drop flow control

----

My opinion is to do 1, 2 and 4.

---

From: Martin Sustrik <[email-masked]>
Date: Thu, 30 May 2013 10:13:03 +0200

> 6) Drop flow control

Without flow control, pushback on one channel will block all other 
channels, which defeats the whole point of multiplexing. Not a good idea 
IMO.

Martin

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 30 May 2013 03:11:38 -0700

>I'd like to hear your opinion on this in this separate thread. Below listed some points we could drop/simplify including >both ones suggested in the thread and some I came up with now.
>

+1 for dropping: 1, 2, 4

rgd. 5: an implementation needs code for such encoding already for base WS. And it's trivial anyway. So IMHO no gain in dropping.

rgd. 3: no opinion right now .. I need to look further into the draft.

rgd. 6: without flow-control, the whole MUX effort is IMHO not worth the efforts anymore. John already said that, and I agree. 

==

However, my current thinking is this:

WS-MUX might be designed with the following features:

a) no flow-control and no priorization (QoS)
b) flow-control, but no priorization (QoS)
c) flow-control _and_ priorization (QoS)

=>

a) Not worth the effort.

b) I am still struggling with understanding the exact situations under which WS-MUX will improve things over whats possible today with stuff like shared Web workers, per-socket TCP autotuning and layer-4 load-balancers.

- An app served from a single origin can have all it's WS connections (from multiple tabs etc) shared over a single TCP using a shared Web worker approach.

- An app where all WS traffic for a given frontend can be processed at a single backend can efficiently scale-out using a layer-4 LB that distributes traffic based on consistent hash of source IP.

- An app that wants max. compatibility with network infrastructure will use WSS and hence intermediaries (other than MITM proxies) won't be able to look into the traffic anyway.

As Takeshi pointed out, there are 2 situations where above is insufficient:

i) a single app served from different origins ("widgets") => cannot use shared Web workers

ii) different apps from same vendor where the connections from the different apps need to go to different backend nodes ("services") => needs an app/service/WSMUX-aware layer-7 LB
 
Given i) and ii) "only" (are there more?), we (for our use cases) probably would have troubles justifying the efforts of doing WS-MUX ..

c)
Is this out of scope rgd WS-MUX?

Priorization/ToS: this is where we see use cases for us.

/Tobias

---

From: "Arman Djusupov" <[email-masked]>
Date: Thu, 30 May 2013 17:38:02 +0300

Agree on dropping 1,2, 4.

Flow control (6) cannot be removed, mux would not work without it.

I would also simplify the initial handshake by removing the quota from the
handshake. Let the server be required to send the first set of channel slots
right after replying to the HTTP handshake, this will not cause any delays
and there will 

be a unified initial quota mechanism for all channels including first
logical channel. So the client sends a handshake requesting the mux
extension, as reply it gets an HTTP response confirming the handshake and
the set of new channel slots in the first frame.

Another part of spec to simplify is the DropChannel close codes. There are
too many codes that cover protocol violations. Since we are not designing a
unit-test framework for bad implementations I think most of those are not
needed. Any protocol violation should result in dropping the physical
connection, there is simply no reason to continue communicating with a pier
that does not adhere to the protocol and obviously is not compatible. Polite
behavior in such cases can only be abused by a DoS attacker, where a
malicious client keeps violating the protocol to force the remote endpoint
to send "error reports", wasting its time and I/O threads.

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Thursday, May 30, 2013 10:17 AM
To: [email-masked]
Subject: [hybi] Simplify WebSocket multiplexing

3) Channel slot

6) Drop flow control

----