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

Adam Rice <ricea@google.com> Mon, 10 June 2013 07:12 UTC

Return-Path: <ricea@google.com>
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 1037A21F8B35 for <hybi@ietfa.amsl.com>; Mon, 10 Jun 2013 00:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level:
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001]
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 OOXBcaaBP4IJ for <hybi@ietfa.amsl.com>; Mon, 10 Jun 2013 00:12:09 -0700 (PDT)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D221F86CA for <hybi@ietf.org>; Mon, 10 Jun 2013 00:12:08 -0700 (PDT)
Received: by mail-bk0-f48.google.com with SMTP id jf17so3142476bkc.35 for <hybi@ietf.org>; Mon, 10 Jun 2013 00:12:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtZS0di3GFc7B2mKHiwtKBOBPFQhJ0AS9LAADy5YOic=; b=kBv4yk+ZDtGETFGEJHjHN6xYRtVSbwTHvIGW/WCGTJv5QoLQLcSYJzqfYFjrQtCAYu KgvD0FDxmPxcYBwRMWsUY3m1RosrcVBAev75flxZhw27mHP0LVPBuT7bX6Kl/v9MN0Wp pIqxgulAE36gtkayHmausrv+AQz7Y0Bag1LpckhLQLTmODFRrmGccjvIE+Rszyn64/Us P30mi8ZUcez5+0vghxlQczJ/fr3k71r0BMsCz2pyUkelJeExECH9wb8+7FRXTPlWuQUI guxEYLfKgr7vInL9Ws9tJDFac2+tGe6x5no+KYTuelSZ9zPFGvg+kO2nW2r9kRG53By7 dnYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=rtZS0di3GFc7B2mKHiwtKBOBPFQhJ0AS9LAADy5YOic=; b=luKFuDeialUqLSBcpw3dmew9vV/v6/Y986DjbiUdifeEFW6r2P2Mmu5TiDIQrLfd1i oklVqJAjdLr4NdDwjWs2ZVPw7BRex0YTOEvMMDT8mrP2IDSdDI+kg3q9HVmfDJYQWYv9 GFPbfbIFJuBeXkI2+cqsTktjSvg3oeDVmxU28qn+QVARcfhMJxqdZt/IlP6Be/Jp9gwX IuZ0hHcYn/P8jptB5mKuZjhx6KNsTKchtze0PD0Z9le9jiKzgpiHRZ4GxeUVfkfpo40O 8pGS7bxrqwpqx1rNEOQC/+F0nAwHloDf3iBT/b71x9hBMD3UUnFCOTCobxnM1aNTGsih A3Vg==
MIME-Version: 1.0
X-Received: by 10.204.184.69 with SMTP id cj5mr1264357bkb.60.1370848327349; Mon, 10 Jun 2013 00:12:07 -0700 (PDT)
Received: by 10.204.35.195 with HTTP; Mon, 10 Jun 2013 00:12:07 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net>
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> <CAH9hSJYOPvsFPDXLOa29ASd8xavLdvfRK_cVd=Uc=Vaydz1O=w@mail.gmail.com> <CAFWmRJ2M0Gtoz80+6v+=0Ldm9+xE2brqD2shVcBPuNz+QGiKHg@mail.gmail.com> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJY_f4jS1ks1xzNmJSX5c+BxJv=-cNs5iS4mP2rZvtsvTQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net>
Date: Mon, 10 Jun 2013 16:12:07 +0900
Message-ID: <CAHixhFr39Ymm6wCeMaF_y+VpC7DVDMFKWDaz_WOixQu=HQEsOw@mail.gmail.com>
From: Adam Rice <ricea@google.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=20cf302ad01898356d04dec77f6c
X-Gm-Message-State: ALoCoQkUD+iwq5599dWqXgQvaRzuI2DrbrbvBH4kOeZyk7heagQ7QkBgRELjqXCp8mD7hZpPwvO25uMkW8ufTfLbnRszHjb+esd6p5+avmAsDnUcEH+s7X05O4kjH7ubPKcVEOzEOioldePlb9Di8JiMgHSy0WV+FrboJp1O2V8xuMpnow6GmvSCTZm6B6frvrQrhMGFvyVY
Cc: Simone Bordet <sbordet@intalio.com>, "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: Mon, 10 Jun 2013 07:12:10 -0000

I believe our priority is to finalise a multiplexing specification quickly.
So we should focus on what is essential for multiplexing to be useful.

I think we have general consensus that flow control is essential.

I have not been convinced that prioritisation is essential. In the event
that a single application has both low-latency and high-throughput
channels, the lack of prioritisation in the protocol can be worked around
by using different endpoints (hence different physical channels) for
different traffic types. To make this easier to deploy, I am leaning
towards the idea that wss://a.example.com/ and wss://b.example.com/ should
be considered distinct endpoints, even if the IP address is the same.

This is not ideal, and the low-latency and high-throughput channels will
still fight for bandwidth at the network level, but it is still a win to
have one each of latency-sensitive and throughput-sensitive TCP/IP
connections rather than a dozen of each.

I am not saying that prioritisation is not desirable, just that I don't
think the complexity versus benefit tradeoff makes sense right now.


On 4 June 2013 19:04, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:

> >     Another issue: implementing s.th <http://s.th>. like priority based
> >     scheduling at app level would might require to reinvent some kind of
> >     fragmentation at the app level to be able to schedule according to
> >     priority (otherwise once a very large message on a low prio channel
> >     is started to be sent, it'll block everything else).
> >
> >
> > Yes. The app must be able to send a fragment.
> >
> > But it's a matter of WebSocket API. A server can do that, but if a
> > client want to, it can't for now due to limitation of the API. Hence, it
> > needs application level fragmentation.
>
> The WS client implementation could do auto-fragmentation. The fragment size
> could be chosen by upstream bandwidth and latency target. A WS server
> could do
> the same. Auto-fragment based on downstream bandwidth and latency target.
>
> The app isn't bothered with fragmentation then.
>
> >     Hence I'd like to propose to
> >
> >     1) add an (optional) extension parameter "scheduler" as above
> >     2) use the 3 currently unassigned RSV bits in AddChannelRequest for
> >     channel prio (when scheduler="priority")
> >     3) define appropriate MUST semantics (scheduling should not follow
> >     advisory semantics .. apps should be able to rely on it)
> >     4) probably add a new PriorityControl message to change prio of
> >     existing channels
> >
> >     ===
> >
> >
> > WebSocket API is not ready for such a sophisticated ToS mechanism.
>
> Yes.
>
> Apart from extending the JS WS browser API (which currently only has
> WS URL and protocol for open) with ToS:
>
> var sock = new WebSocket("ws://example.com ", [], {scheduler: "priority",
> priority: 7});
>
> This would assume that logical WS channels eligible to be shared over 1
> physical WS
> not only share same host:port, but also scheduler.
>
> [this API does not provide for 4) - dynamically changing channel prio]
>
> Another option would be to let the server choose based on URL requested
>
> URL 1 : ws://example.com/chat
> URL 2 : ws://example.com/file
>
> If the client connects and speaks MUX, the server can answer (in opening
> handshake)
>
> mux; scheduler=priority; priority=7
>
> for URL 1 e.g.. For the first connection, that would happen on the
> physical WS. For subsequent
> connections, it would happen on logical WS (scheduler needs to be the
> same): MUX is not nested,
> but only the "priority" parameter used by the client WS implementation.
>
> Yet another option would be to "use" URL parameters to hint
>
> URL 1 : ws://example.com?scheduler=priority&priority=1
> URL 2 : ws://example.com?scheduler=priority&priority=7
>
> and let the server make final decision.
>
> >     Example:
> >     An app creates an empty file on some cloud service. Subsequently the
> >     app wants to append to that file.
> >
> >     The first could be a high-prio message, the latter messages low-prio.
> >
> >     The app does not care whether those messages travel over 1 physical,
> >     or multiple different logical WS channels.
> >
> >     However, the app does care that the first "create file" message
> >     arrives before any subsequent "append to file" messages.
> >
> >     So a different design involving per-message prios on a single WS
> >     channel (physical or logical) might allow higher-prio messages to
> >     overtake lower prio-messages, but not otherwise round.
> >
> >
> > I see.
>
> This would definitely require API change
>
> sock.send("foobar", 7); // send message with priority 7
>
> It would provide even richer semantics to an app though ..
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>