Re: [hybi] Flow control quota

"Arman Djusupov" <arman@noemax.com> Wed, 13 June 2012 12:17 UTC

Return-Path: <arman@noemax.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 3CDB321F863B for <hybi@ietfa.amsl.com>; Wed, 13 Jun 2012 05:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 F8+4uswzyr1b for <hybi@ietfa.amsl.com>; Wed, 13 Jun 2012 05:17:18 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 52EA521F85D0 for <hybi@ietf.org>; Wed, 13 Jun 2012 05:17:18 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; t=1339589832; x=1340194632; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=WKnzoV4sWNhSqU8G3oYmPaIWLKc=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=5WT8fISg9kNzMP7MA0WoNj5pS2T/1EblIYrVQBIvvB3pCwp/hI8W477sl2DKTOudoyQjJZ/ZzTS9vaZPhmJeCvt8lJIdYcoixmY/cYnv5ZKXli5CokiiqDPM4pGQLGBNvDNiVtV+1OX6qg9Yrd0G9VL30IaJjpOAxsTfp3ZhCsE=
Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.1) with ASMTP (SSL) id XSE77311; Wed, 13 Jun 2012 15:17:11 +0300
From: Arman Djusupov <arman@noemax.com>
To: 'Martin Sustrik' <sustrik@250bpm.com>, 'Takeshi Yoshino' <tyoshino@google.com>
References: <001a01cd3e69$4a221c10$de665430$@noemax.com> <4FC732DC.3000308@250bpm.com> <000e01cd3f1c$af15ad40$0d4107c0$@noemax.com> <4FC880A7.9070007@250bpm.com> <CAH9hSJaWrUX6gFNLT4xkXLYKHSUH5+Y7AvqN9cD_CwekvsNu3A@mail.gmail.com> <001001cd4000$fe2c82c0$fa858840$@noemax.com> <4FCCAE6B.1010306@250bpm.com> <002d01cd4262$747957b0$5d6c0710$@noemax.com> <20120607022312.GA26406@jl-vm1.vm.bytemark.co.uk> <000e01cd449d$1c0ed220$542c7660$@noemax.com> <CAH_y2NE6+3r_9pkYXhMOiRWfGJXGauEYCqg-8GvtOoCT9Ch0mA@mail.gmail.com> <000401cd4566$d5f6bb70$81e43250$@noemax.com> <CAH9hSJY9d3dS_2vTZ-AXwuX0WnJuwZXrFyJtWik5SoKnQ3kWmw@mail.gmail.com> <4FD85D7C.3000902@250bpm.com>
In-Reply-To: <4FD85D7C.3000902@250bpm.com>
Date: Wed, 13 Jun 2012 15:17:01 +0300
Message-ID: <000c01cd495e$751e5cd0$5f5b1670$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDnHEYxNcL9Xb2UVJoRm1lbL/BkAQFoH3KRAV1ppa8CZ6BgXAIpbgj4AsMo47wDBdtyYwH7TrBAAdzt12oB94xqWAGEGWmHAlGfbXgB++MmyQHjTxijl+9gaoA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Flow control quota
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, 13 Jun 2012 12:17:19 -0000

We can resolve the problem with per-frame compression by aligning
compression to the message boundary. 

But by doing so we dodge the problem with non fragmentable frames that might
be produced by any future extension that is unknown to the intermediary. For
example we may need a reliable streaming extension that numbers all the
frames and adds the frame number in the extension data so that it can resume
sending the message if the connection fails. Such an extension would not
support fragmentation so it would set the RSV bit of each frame to prevent
it from being fragmented by intermediaries. As long as the parent
specification allows extensions to place their data at the beginning of the
frame payload, this extension's data would not be recoverable if the frame
is fragmented, so such an extensions would be incompatible with mux.

It's ok if some extensions are not compatible with mux intermediaries, since
the WebSocket specification allows intermediaries to refuse extensions that
are not known to them. But ideally mux should be transparent to all
extensions, so that mux intermediaries can be unobtrusively introduced at
any point of the communication path without placing any restrictions on the
extensions that may be used and the type of payload being exchanged.

So I think we should take a bit more time to think on how we can resolve the
problem with mux without changing per-frame compression. The second problem
is that changing per-frame compression so that it is applied on the message
boundaries would create an issue if it is applied after mux. Since after mux
there are no message boundaries any more as message frames are intermixed,
the compression would have to be applied on each frame separately. So
effectively per-frame compression extensions would have two modes of
operation, which would be very hard to define in a specification. It would
practically make it a requirement that this per-frame compression extension
be aware that mux is being used. IMO having such coupling between extensions
would be a bad design.

It's preferable that we define a clean/final solution to the problem, so
that whatever extensions are in use in 2050, " good old mux" is still
applicable. I'm trying to work out Jemie's suggestion to let mux be
transparent to intermediaries but haven't figured out any cheap way of
enveloping the frame fragment yet.

With best

-----Original Message-----
From: Martin Sustrik [mailto:sustrik@250bpm.com] 
Sent: Wednesday, June 13, 2012 12:30 PM
To: Takeshi Yoshino
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: [hybi] Flow control quota

On 13/06/12 08:50, Takeshi Yoshino wrote:

> It's also an option that we give up frame-level extensions other than mux.

That makes sense IMO. Fragmentation is an integral part of multiplexing. 
Using it for other purposes is just asking for trouble.

Martin