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

Takeshi Yoshino <> Mon, 27 May 2013 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD7C421F8C1A for <>; Mon, 27 May 2013 01:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmNMEfC1QAuw for <>; Mon, 27 May 2013 01:26:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22e]) by (Postfix) with ESMTP id E626E21F9371 for <>; Mon, 27 May 2013 01:25:38 -0700 (PDT)
Received: by with SMTP id c10so1346616wiw.13 for <>; Mon, 27 May 2013 01:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xVFCHKO75zM1Iw/Sb3hQJsmKWDJLqj6fMiIHzKGyhOQ=; b=hRPrOsPToaK2Nr26q+lDvV4rYW+mvbjGIax6epZYsYcjuPLYMrRliZWMlD1ZTPYV/b GXaPpZ6CiL1CAfrn1mAlelEGG7yyQbMAnT9/qlVkHLyygJ2D5naoxuDfDf1IVfuLYmvc si5sKb1iaCFWgeKvBqt2wxEe6F8RMnmc43gQlD0mkFn5/RWope9jq8QXftlKL/O7rdy4 vzS3H6daTTtsJcmh/TKXzh1ZJgwWU795xJAzAZSDo/XgNlhIgAJSHl4A0rYMHHF3s1H0 3BTeWM8ng8Xi0dapF++nMZZJU43Wu5PATHlt2FZGuRMXAi5PLjUuMXfe84uIjA78QcrS m6Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xVFCHKO75zM1Iw/Sb3hQJsmKWDJLqj6fMiIHzKGyhOQ=; b=neZpnU6GoYmYpIuUHIhbD3J9frnLjCoSp3FYNpEtmFrrdVUl2BpPLELq1937qru9Qq sZp3VSDJqQoKmLayqnaClJUS0hc9nZKRqhq/VyFNSXjaeGsZFM9J3zBcp0pZoE0XtqVB KSXxZxczz/86Ci3o4HBzoBVdQ5RfiEO/qgFZ+p6Xji6iZY2PFngrJdlwVgtpZXJjwrHN SyCMKhOAlT7afumzkQVZNqrXv2bEPC12WERuvLEyHNmDwqbIZczhnnhfK/nz52yOWV1Q unVIKdu+rXKj7P8tZhv6UaTEwUvN0zmX+W8otZ+l3NU9xN2SdK2CMREgqT/w75TRkcgW gieg==
X-Received: by with SMTP id gz3mr7582201wib.0.1369643138136; Mon, 27 May 2013 01:25:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 May 2013 01:25:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <> <> <> <>
From: Takeshi Yoshino <>
Date: Mon, 27 May 2013 17:25:18 +0900
Message-ID: <>
To: Simone Bordet <>
Content-Type: multipart/alternative; boundary=e89a8f3b9b69b7d45204ddaee481
X-Gm-Message-State: ALoCoQnsXjZwUX1l16Yz9h/6/R10O5Rr/mMqd0/iNCdaA2+YXi0MuSxakX6xAIJ+855ntb5g2hXyDjT48nHO49m/LK4Si3xtWZZsYzpgXMIs+OISf6kQVn+1inMdrJqxWL7zdihbvSpxyBmgyazHI0BptAjHdmVDti3oOnGTtFHiJF7Ht4oE+Fr+ui6u64+V3gwePDg0xX1n
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: Mon, 27 May 2013 08:26:08 -0000

On Thu, May 23, 2013 at 1:48 AM, Simone Bordet <> wrote:

> On Wed, May 22, 2013 at 6:26 PM, John A. Tamplin <> wrote:
> > I agree -- without flow control, there is very little benefit, and almost
> > nothing that an app couldn't easily do themselves by just adding a simple
> > framing layer inside WS messages (perhaps just the first byte is a
> logical
> > channel number).
> In SPDY, the flow control had an initial window of 64k. This proved way
> too small for uploads/downloads, which resulted in a 3x or more slowdown.
> So there needs to be in ws a mechanism to configure this window (which
> SPDY has).

NewChannelSlot can do this. I don't think adding SETTINGS is simpler than

Instead of dropping NewChannelSlot, I'd rather suggest dropping "N mux
control in 1 message" format, "Handshake size" field in AddChannelRequest,
AddChannelResponse, "Reason size" in DropChannel.

> So "simple mux" looks like an oxymoron to me, and makes me wonder what
> useful could be a ws mux solution that does not do dynamic channel
> prioritization.
A typical use case Joakim presented to me was to tune video download rate
> in a websocket server: a big priority initially to download faster than the
> client video player plays, to make some buffer, and then reducing the
> priority to a steady state with the video player's speed, or reducing
> priority to almost zero if the user pauses the play.

Isn't it in-app priority? Can't script and server address that problem? If
only the client knows current priority, the client can tell the priority to
the peer servlet using a WebSocket message. If the server know priority for
each position, it can just control transmission speed.

Even if we need help by the server, the servlet would call some special
function to tell the server about priority.

Different from HTTP/2.0's case, we don't need to provide a special field in
mux protocol to pass priority, I think.