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

Tobias Oberstein <tobias.oberstein@tavendo.de> Wed, 22 May 2013 20:49 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 9877C11E80A2 for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 13:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level:
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
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 zkSHVLDvTOxu for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 13:49:05 -0700 (PDT)
Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id DBA4621F9195 for <hybi@ietf.org>; Wed, 22 May 2013 13:49:04 -0700 (PDT)
Received: from [192.168.178.39] (87.79.136.230) by smtpx20.serverdata.net (206.225.164.37) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 22 May 2013 13:49:03 -0700
Message-ID: <519D2F3E.3000609@tavendo.de>
Date: Wed, 22 May 2013 22:49:02 +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: Simone Bordet <sbordet@intalio.com>
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> <CAFWmRJ2Hbe0x5FeV2T7Gkp3WEsxQHe2=YPBTgvHYLcus3A4rBQ@mail.gmail.com>
In-Reply-To: <CAFWmRJ2Hbe0x5FeV2T7Gkp3WEsxQHe2=YPBTgvHYLcus3A4rBQ@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:49:09 -0000

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

Interesting. And yep, being able to dynamically tune the priority of a 
stream from the app seem desirable. The buffer/window size in this use 
case would probably be relatively large and fixed.

May I add another user experience centric use case where an app might 
want to tune both priority and buffer size?

Say I wanna run something like chat while also doing file transfers over 
WS. Different QoS. I don't want to increase the latency on the chatty 
stream by running a mass data stream. However, this probably requires 
both flow control _and_ message/frame priorization.

The current mux RFC reads:

" The sender MUST use a fair mechanism for selecting which logical
channel's data to send in the next WebSocket message.  Simple
implementations may choose a round-robin scheduler, while more
advanced implementations may adjust priority based on the amount
or frequency of data sent by each logical channel.
"

This seems to imply that the app has no control over QoS per stream 
(i.e. "chatty" vs "mass data").

IMHO the app should be able to control that (ultimately effecting buffer 
sizes and priorization/scheduling). If the app has no control chances 
are that people will invent something at the app level. IOW: this is 
something where MUX could really deliver added value (better UX), even 
if you are not a big G and concerned about infrastructure resource costs 
and world scale apps.

Do you think the current MUX addresses a chat+file transfer use case?

What about the proposed SPDY/HTTP2.0 multiplexing?

Are there even any plans for exposing tunables to apps?

/Tobias

>
> --
> Simone Bordet
> ----
> http://cometd.org
> http://webtide.com
> http://intalio.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> Intalio, the modern way to build business applications.