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

Tobias Oberstein <> Tue, 11 June 2013 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3A2B21F9A00 for <>; Tue, 11 Jun 2013 08:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9Xx2L0q6NYi for <>; Tue, 11 Jun 2013 08:35:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A3DEC21F9A39 for <>; Tue, 11 Jun 2013 08:35:57 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Tue, 11 Jun 2013 08:35:56 -0700
From: Tobias Oberstein <>
To: "John A. Tamplin" <>
Date: Tue, 11 Jun 2013 08:35:53 -0700
Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket
Thread-Index: Ac5mtVXlYwcFav5eRhS96qdjfnyzIwAAMXpw
Message-ID: <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Simone Bordet <>, "" <>
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: Tue, 11 Jun 2013 15:36:04 -0000

>     3. single app with multiple communication requirements with
>     different  TOS (low-latency/mass..)
>     might need MUX+flow-control+priorization.
> In the case of a single app, it can always do its own prioritization, so 

The app then needs to implement app-level fragmentation, where the
draft already requires fragmentation for mux.

> I do not think it essential for this case.

For a single instance (tab) of the app, the can reinvent fragmentation
and implement it's own priority scheduling.

This seems to be highly inefficient.

For multiple instances (tabs) of the app, it's essential, since the app cannot
implement itself.

>     I think with a little more work we could prepare for more advanced
>     scheduling
>     schemes in the future and allow implementations to experiment today
>     without
>     breaking interoperability.
> I don't see much value in providing the extension mechanism in this 
> draft without actually requiring an implementation, and requiring a 

The draft already requires the implementation to use a "fair scheduler", but
leaves the exact mechnism open.

> priority implementation means adding a lot of extra work.  The only way 
> I would support this would be if the text were basically "the 
> application can provide an indication of priority, and the server is 
> free to use or ignore this information as it sees fit".  In that case, 
> would anyone bother to use it?

A client can only hint, but _if_ the server sets priority on a channel, the
client _must_ schedule accordingly.

For a implementations not supporting priority scheduling, the proposal
essentially only relaxes the allowed parameters in Sec-WebSocket-Extensions
header for client-to-server:

priority-enabled client => non-supporting server:

c2s: mux; priority=scheduler; mux
s2c: mux

Change: skip mux configurations not supported instead of failing the handshake.

non-supporting client => priority-enabled server:

c2s: mux
s2c: mux

No change at all.