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
- Re: [hybi] Flow control quota Martin Sustrik
- [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Martin Sustrik
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Martin Sustrik
- Re: [hybi] Flow control quota Greg Wilkins
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Jamie Lokier
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Greg Wilkins
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota John Tamplin
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Martin Sustrik
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Jamie Lokier
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Martin Sustrik
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Takeshi Yoshino
- Re: [hybi] Flow control quota Arman Djusupov
- Re: [hybi] Flow control quota Takeshi Yoshino