Re: [hybi] Simplify WebSocket multiplexing

Tobias Oberstein <> Thu, 30 May 2013 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA98F21F9473 for <>; Thu, 30 May 2013 03:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.452
X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H4ckGaElQxSu for <>; Thu, 30 May 2013 03:11:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AED7621F91B8 for <>; Thu, 30 May 2013 03:11:36 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Thu, 30 May 2013 03:11:35 -0700
From: Tobias Oberstein <>
To: Takeshi Yoshino <>, "" <>
Date: Thu, 30 May 2013 03:11:38 -0700
Thread-Topic: [hybi] Simplify WebSocket multiplexing
Thread-Index: Ac5dBbQ3WPmIwuLHQzqzW2cnu7PaEQACnkhQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [hybi] Simplify WebSocket multiplexing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 May 2013 10:11:42 -0000

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

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

Is this out of scope rgd WS-MUX?

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