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

Tobias Oberstein <tobias.oberstein@tavendo.de> Wed, 22 May 2013 20:44 UTC

Return-Path: <tobias.oberstein@tavendo.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4F811E8106 for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 13:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level:
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAm6HKdKRuWK for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 13:44:33 -0700 (PDT)
Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABA21F961B for <hybi@ietf.org>; Wed, 22 May 2013 13:44:33 -0700 (PDT)
Received: from [192.168.178.39] (87.79.136.230) by smtpx20.serverdata.net (206.225.164.33) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 22 May 2013 13:44:32 -0700
Message-ID: <519D2E2D.4080809@tavendo.de>
Date: Wed, 22 May 2013 22:44:29 +0200
From: Tobias Oberstein <tobias.oberstein@tavendo.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "John A. Tamplin" <jat@jaet.org>
References: <CAH9hSJZxr+aG7GZa4f-dUOTGj4bnJ+3XxivUX4jei5CMyqN4LQ@mail.gmail.com> <CAH9hSJZUG1f+3Uk=t2=A5i4O9=wPvAisspM=pgmGEH9emTL9-Q@mail.gmail.com> <CAH9hSJZai_UuxW4O6mZcEJT2DJoURtLo16XNci1qkYVWv4HVdg@mail.gmail.com> <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <CAM5k6X9WmO80hiQZ6_GqK66PAd3of=2ZRi9=VrWj52apA1+=5g@mail.gmail.com> <519D02E7.6040009@tavendo.de> <CAM5k6X8Z-JxrgTy3NAc-wC7zK_AfsWAhqzNKaEY_yZzmz=pZcQ@mail.gmail.com>
In-Reply-To: <CAM5k6X8Z-JxrgTy3NAc-wC7zK_AfsWAhqzNKaEY_yZzmz=pZcQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 20:44:38 -0000

Am 22.05.2013 20:32, schrieb John A. Tamplin:
> On Wed, May 22, 2013 at 1:39 PM, Tobias Oberstein
> <tobias.oberstein@tavendo.de <mailto:tobias.oberstein@tavendo.de>> 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: http://www.250bpm.com/__multiplexing
>     <http://www.250bpm.com/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

He does not address intermediaries, yes. But he does address memory 
consumption at endpoints: when running multiple TCPs between a given 
pair of endpoints, send/receive buffers reside in kernel space, whereas 
multiplexing over a single TCP requires send/receive buffers (per 
stream) in user space (to avoid TCP pushback). Hence he calls it a draw.

However, thinking about it: having send/receive buffers in kernel space 
requires one to decide how big buffers should be for the complete 
machine (TCP send / receive buffer size is usually a kernel tunable).

Having those buffers in user space (in app) allows one to tune the 
buffer size _per stream_. Thus, we can have large buffers for streams 
that carry mass data, and small buffers for chatty streams. Thats a real 
advantage.

Rgd load balancers: yep, L7 LBs will have a problem with massive numbers 
of connections. But L4 LBs that e.g. distribute connections to backend 
cluster nodes based on consistent hash of source IP not .. since they 
dont need to maintain state per connection. A L4 LB should be able to 
scale to millions of TCPs.

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

So to make the proposed advantage explicit: the per-stream handshaking 
that happens with mux consumes less resources than full TCP handshakes.

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

How about having a shared Web worker in the background that handles all 
messaging for the app over a single WS?

> connections very well (or intermediate load balancers), so you would

Async servers running on top of modern APIs like epoll/kqueue/IOCP have 
no issue with massive numbers of long-lived connections. I have run 180k 
WebSocket connections on a single-threaded server running on a 2 core 
4GB Ram VM (with small TCP send/receive buffers configured).

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

I agree, MUX at app level is probably less than ideal.

>
> --
> John A. Tamplin