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

Roberto Peon <fenix@google.com> Mon, 03 June 2013 18:18 UTC

Return-Path: <fenix@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 E643C21F85B4 for <hybi@ietfa.amsl.com>; Mon, 3 Jun 2013 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 SOulzLvk+yYT for <hybi@ietfa.amsl.com>; Mon, 3 Jun 2013 11:18:14 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 69FFC21F8746 for <hybi@ietf.org>; Mon, 3 Jun 2013 11:15:39 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id gw10so1316945lab.2 for <hybi@ietf.org>; Mon, 03 Jun 2013 11:15:38 -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=D7+QPr7Dvd5GsrlbLP7b9pfI1qB/AkR6WDSWILE+nEQ=; b=ok3F8YHbHdStLecllqioD8mIfmiES17eIVf9+rfaY+pv+zRFxO/g6hERt4FmJZWuM7 k5K2lmxV22/juP1dnoshccSJFb2Mtrt+xflx2EVJ256ZnkHg0v+USea0QXp2KnPg5W8f k23iMEQJ5lbFA0XbmZ24BhcmOihN6AXLuOW08WGIqqHD90co6EMhlf5wu8LjcuQfWkJn gUNJ4cL42ROyRIFjAgTWxRxr5H21SeQnQ3j8lXlPNkvQ7cvROqW5Ql6ISTgos8w1zHop yRWLzrF/Y46ezu3PyLRatZGtbU286CCc/c552VISVs38V/tocLLotNjAaQGIpHp6a+YF x/HA==
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=D7+QPr7Dvd5GsrlbLP7b9pfI1qB/AkR6WDSWILE+nEQ=; b=Tlt4rVEkTeCNeqZ2NNaq7NT+61oc2o81JaYaaZBqaWEpK6ao9noFVPCNX5tRGOya+z tPTUTAtHS4BigyDM1xCPl/sMsFPkjUK0cAsX5AJFGKU5iwxwxdydyRf/IrY+jMtOAOp4 HCl7ODtXVxFWW4wS0vSekNiGLD6eqXtHLHTIV+q9GQSNE8wbdvXZFlC1W9sjO3ea5KPt OvbI3yOKbPdkYBT26ZVj+3hOvVAw1cqs305qsJbM9nNMyPsnhKSHOI5FZcWxonvpviQY jUKM+Cbj4yXdKigLflz82Kq2Wh0bL9OrK7jAYlhI+f4tsxEFtTq6jViNFSFAVzDRhK94 nVBg==
MIME-Version: 1.0
X-Received: by 10.112.134.34 with SMTP id ph2mr11430790lbb.112.1370283338330; Mon, 03 Jun 2013 11:15:38 -0700 (PDT)
Received: by 10.112.76.231 with HTTP; Mon, 3 Jun 2013 11:15:38 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D4422DC20DAA@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>
Date: Mon, 3 Jun 2013 11:15:38 -0700
Message-ID: <CAGzyod7o8AR2WxNrkZ-WWb5nc3zAJMvWhpfNVaW26sregESyjQ@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=047d7b3a8c0c9f8a7a04de43f325
X-Gm-Message-State: ALoCoQlZTZwWbskrzdVF8I3Nu1XOVoW3xQAD/gM+22OaCw3N51Ww+4fCrmOfkgjdYaIdoGDSWUrBCyIE2hyKml+CNX+fcYZRoc94I04dpCkzrifiX3CIEDshoDvCZqebnAw5vVJprg6MoCGs/7CMKo4Tr4unvFNa9NVx8ZBw3g7Jc1j08jNxl0Vk2gj8U4yKkVsE6TtJtGcR
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, 03 Jun 2013 18:18:26 -0000

imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the
complexity of muxing, security, prioritization, flow-control,
liveness-checking, stream initiation, and compression, only once.
-=R


On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> > On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino <tyoshino@google.com>
> > wrote:
> > > 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.
>
> If intermediaries are no preserve a per-channel priority based scheduling,
> then they might need to know the channel priority.
>
> >
> > Sure, but then you force every application to reinvent this mechanism on
> top of
> > WebSocket mux.
> > At that point, one could argue that application messages could have
> their own
> > "channel_id" in their messages, and applications can do mux themselves,
> if
> > they need it.
>
> Yep, agree.
>
> Scheduling integrated with MUX has another advantage:
>
> e.g. when doing per-channel priority based scheduling the scheduling could
> not only consider channel priority, but also the quota.
>
> A high priority channel with data outstanding to be sent but not quota to
> send would otherwise block a lower priority channel with data _and_ quota.
>
> Another issue: implementing 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).
>
> One way to look at this is:
>
> WS fragmentation < WS multiplexing < WS scheduling | APP
>
> where "<" means "builds on", and everything up to "|" is provided by an WS
> implementation, hence does not need to be reinvented at app level, and WS
> aware infrastructure can optimize / do their thing.
>
> ===
>
> It seems that HTTP/2 likely will have "request priorization" (I don't know
> about "response priorization").
>
> If we (in a pure WS land) don't have priorization, that's a potential
> disadvantage and source of discussion.
>
> ===
>
> A per-channel scheduling could work according to different policies:
>
> 1. Round-Robin scheduling
> 2. Priority scheduling
> 3. Fair Bandwidth scheduling
> 4. First-Come, First-Serve scheduling
>
> The policy mechnism could be selected for the whole physical WS (and
> communicated for intermediaries), e.g.
>
> Sec-WebSocket-Extensions: mux; scheduler="round-robin"
>
> Only with 2. there is a need to select and communicate a per-channel info
> (during channel creation), e.g.
>
> Sec-WebSocket-Extensions: mux; scheduler="priority"
>
> and then
>
> AddChannelRequest with the 3 RSV bits (currently unassigned) containing a
> priority 0-7 for the channel.
>
> [This does not yet answer how to re-prioritize an existing channel]
>
> 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
>
> ===
>
> Above is a kind of per-channel scheduling. One might argue that it lacks
> in at least 2 respects:
>
> - an app is not able to control e.g. prio on a per-message basis
> - there are no ordering guarantees between messages on different channels
>
> 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.
>
> /Tobias
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>