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

"John A. Tamplin" <> Wed, 22 May 2013 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECC5011E812E for <>; Wed, 22 May 2013 11:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8IyEqniBBLqM for <>; Wed, 22 May 2013 11:32:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::234]) by (Postfix) with ESMTP id 7483611E812F for <>; Wed, 22 May 2013 11:32:43 -0700 (PDT)
Received: by with SMTP id ar20so5876468iec.39 for <>; Wed, 22 May 2013 11:32:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ko8m7Fn5a7sS+ethsduBqC7LixQCBl69UHTC/XwixPA=; b=b/t1RXODnCxGMfgrofe/tJdd1bcYA/WcFNDBjuCZY6KcBecmC3XxD0RwTcZkrqnm1S hq2cEf693Ttpz1R0OuH2dzb12eNgHeZrS4V6thaFODtW4th4qh3UEV+W8JheNsWJVGr3 QxIlsKwQx8VogCaEU9l64mmTN175UjYM0A5l77DrcoEyWceU9DQKJuWHatLMtilrYzno nJC0POof9kdJ49QMI5qgeL9QmkkY5XMfOwymTbQGAgx99TESRfEAzlqRWbGVfxT1Jy07 f3CpTFVXCrMQXtCEZLehRAFrMdl1FZzhIkdKsw2xbhyyRtIHyG+BNTJD3TZ7yE/tHJeF PeJg==
X-Received: by with SMTP id n9mr7733587icl.47.1369247562895; Wed, 22 May 2013 11:32:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 May 2013 11:32:22 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <> <> <> <>
From: "John A. Tamplin" <>
Date: Wed, 22 May 2013 14:32:22 -0400
Message-ID: <>
To: Tobias Oberstein <>
Content-Type: multipart/alternative; boundary=20cf301cc49298aa2904dd52ca2e
X-Gm-Message-State: ALoCoQklRrmCGhMKv6TXp82haBV6t8CW7egjUT8d1ir9YKqYwQG7CYAdOgta1zz8lj9L3hb6k9D4
Cc: "" <>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
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: Wed, 22 May 2013 18:32:48 -0000

On Wed, May 22, 2013 at 1:39 PM, Tobias Oberstein <> wrote:

> Regarding implementing flow control above TCP (and below app), I found
> this:
> "Multiplexing on top of TCP in overall fails to deliver the advantages it
> is assumed to provide."
> Source:**multiplexing<>
> Do you have an opinion on that?

One thing he doesn't address are resources used to keep lots of connections
open, both at the OS level and in intermediate network nodes (such as load
balancers -- try running tons of long-lived connections through an F5 for
example).  Also, he doesn't address the interaction of TCP slow start with
lots of new connections.  I also don't believe the equivalent of a full TCP
handshake is required to allocate buffer space.

> More important: what problem exactly does multiplexing solve? The current
> mux RFC mentions "scalability", but doesn't go into detail ..

Here is a use-case I envision:  Imagine GMail, G+ sandbar, etc all use
WebSockets heavily.  Many users may have multiple copies of such apps
running in tabs or windows in the browser, and some of these are going to
be separate (such as GMail and the G+ sandbar probably are separate apps
running on the same page and maintain their own connections to their
backends).  Currently, that would mean you have a ton of TCP connections
open to the server.  Servers don't handle tons of long-lived connections
very well (or intermediate load balancers), so you would greatly prefer to
have one connection per browser.  WS MUX lets you do that, by having the
browser aggregate connections to the same backend.  You could do some of it
at the app level, but it is going to be complicated and in many cases these
apps won't all be from the same vendor (for example, some widget on the
page that uses the GData API) and will have separate deploy schedules.

John A. Tamplin