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

Takeshi Yoshino <tyoshino@google.com> Tue, 04 June 2013 10:07 UTC

Return-Path: <tyoshino@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 22DD221F9BEE for <hybi@ietfa.amsl.com>; Tue, 4 Jun 2013 03:07:32 -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_52=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 I5QpdvOyCs5O for <hybi@ietfa.amsl.com>; Tue, 4 Jun 2013 03:07:20 -0700 (PDT)
Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A549421F9B79 for <hybi@ietf.org>; Tue, 4 Jun 2013 02:04:40 -0700 (PDT)
Received: by mail-ea0-f177.google.com with SMTP id j14so2071080eak.8 for <hybi@ietf.org>; Tue, 04 Jun 2013 02:04:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F/jfU/mAIw15lP+VhA9idn40OVVbhn3ZFPxNeYROKAo=; b=LNFsetyQ+WjDlS7xcF5vtjcqfFEktwnqJqXcLzy+dcEQqXwBr5kmIJhVuvPp6S7tQ/ f7BflrxKZjC/Q9tV/GIfN1fL/EY/vrQ6LLjP2XKN3oOt8fxq3EXrihSSycnHZl0Rn02n HexExzlQUgWSEAuoplXs9u5zzUGY5SkgnXBUSxpusKRiXv370mxwoGTIMChewlq5A45L 2BeGojf0pNcugzsviUlew+9UALPWkvnquEEVFXKiMAYw4yWNUXbZKkKWtEbps3GM1gkO f7rJtVoawnobJ7v4Z3kwby7Fve4gV0GauFOLVPvxSKGtAzWmjOLh2pzN7DVgI2V7tQqu +MNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=F/jfU/mAIw15lP+VhA9idn40OVVbhn3ZFPxNeYROKAo=; b=mw+6KWiSnfBpPnsbZdgHJss5Jg9EExUNNHpPV/xdEobROHyOhXBKH2kbybkSL6Df1R y9Cn6djm/JRGgWwPruAQYzqyf6mkG50REUrEGVB81OPTAnNVXrH+qneW993xzn+yQ0dK UgstSA3YQT5dFhGLXG7jS/0cPkvq7tRluoi7rjq2nMYejit8btRXsdcxd5GMq55S2RNh gCfEtz/cReyqPl0ft/lQq9pHwgcvFo7k20wAudP67y7Ttm91yN1k9M35yj20fK6JqG5H Su5wiog5UU34G9A3tupZ+i1bIFp9OUlT6n0lfEvO/QH6PPRNHvU5ekTI1CA1pbTdfR8w Hp0g==
X-Received: by 10.14.225.66 with SMTP id y42mr40910eep.129.1370336674824; Tue, 04 Jun 2013 02:04:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 02:04:13 -0700 (PDT)
In-Reply-To: <51A737E6.2090707@tavendo.de>
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> <519D02E7.6040009@tavendo.de> <CAM5k6X8Z-JxrgTy3NAc-wC7zK_AfsWAhqzNKaEY_yZzmz=pZcQ@mail.gmail.com> <519D2E2D.4080809@tavendo.de> <CAH9hSJZw7sLhQH6i2O9-rRKc88Bmh0EaJEcpxSB5kUKprP6YyQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422C3DA775@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJYms5rPSvDDNeMYoZ19UmRLJUd7YM7d98ONUkB4YZnM=Q@mail.gmail.com> <51A737E6.2090707@tavendo.de>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 4 Jun 2013 18:04:13 +0900
Message-ID: <CAH9hSJbAi153h1ZYKJY2gCDunO8-79FRFhKrTCCFKMqEtxv6rg@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=047d7b670997ba0e0204de505ed5
X-Gm-Message-State: ALoCoQkiTkJT5qu4UcjDxqLMo2kQZ4RxRHTGoagKva5dtzs1bw8HcbvLVlzcDQr8HW/fVV4kG3mUV8H9jgYKfpSKZosihsfP2ojeZlZcBXK08CLLnY7L2uihqP42teQJ+223iE0xgJk+6YWrqkcuLm1FT7yHoGMsMFN7W1wSoRxIJAqYz4jYh51wysqvV81J8T8i7KlEwxoG
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: Tue, 04 Jun 2013 10:07:32 -0000

On Thu, May 30, 2013 at 8:28 PM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> b) the endpoints need to cut mass data into smaller chunks to reserve
>>
> slots for inserting chatty traffic. e.g. if acceptable delay for chatty
>> traffic is x ms, set the maximum send unit of mass traffic to (current
>> through put) * x.
>>
>> To allow one to control the peer's message scheduling, both per-socket
>> buffer size and ws-mux flow control are insufficient, I think. Needs to
>> exchange ToS info.
>>
>
> I now can see that flow control and priorization are somewhat orthogonal
> issues.
>
> Priorization and ToS is not goal of WS-MUX at all?
>
>
It's again, as I said in reply to Simone's comment above, it depends on
frequency and usage if we should have WebSocket protocol level ToS or
should just do it in JS.

...


>> Traffic for various services would be multiplexed into one TCP. We wanna
>> demultiplex it and forward to designated backends. This means that
>> there're again lots of TCP connections between LB-backends, but we can
>> make any optimization there as we want.
>>
>
> I see. So the load-balancer needs to be a layer-7 one, and not only be
> WS-MUX enabled, but also app/service aware? Something like this:
>
> E.g. user has 2 tabs open which (logically) connect to
>
> wss://google.com/gmail
> wss://google.com/gplus
>
> Both would be transported over 1 physical WS (via WS-MUX).
>
> The LB would demux traffic for logical channel
>
> wss://google.com/gmail
>
> to backend nodes of cluster "GMAIL", while it would demux traffic for
>
> wss://google.com/gplus
>
> to backend nodes of cluster "GPLUS"?
>
>
Yes.


>
>
>>      >Basically multiplexing should be done as close to network as
>>     possible. If it's done in application layer, for example when
>>     compression is used, such a load balancer need to decode the
>>     compression to see the >multiplexing information. That doesn't make
>>     them happy.
>>
>>     This seems to assume that
>>
>>     - either the LB is done above layer 4 and/or
>>     - the logical WS connections contained in the physical WS would need
>>     to be balanced to _different_ backend nodes.
>>
>>
>> Yes. Sorry that we haven't told the story in our mind in detail.
>>
>
> I think it might be helpful to add text to the MUX draft that describe the
> use cases WS-MUX addresses and how it improves thing over alternatives.
> Motivation is always good and helps by providing context and examples.


OK.