Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)

James M Snell <jasnell@gmail.com> Fri, 10 May 2013 21:11 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5CD21F8930 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 14:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.402
X-Spam-Level:
X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 eeI1xXfdxlaT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 14:11:11 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9D10C21F85EB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 14:11:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UauZe-0005Od-NP for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 21:09:54 +0000
Resent-Date: Fri, 10 May 2013 21:09:54 +0000
Resent-Message-Id: <E1UauZe-0005Od-NP@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UauZT-0005NW-Uf for ietf-http-wg@listhub.w3.org; Fri, 10 May 2013 21:09:43 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UauZK-0001jQ-BI for ietf-http-wg@w3.org; Fri, 10 May 2013 21:09:43 +0000
Received: by mail-oa0-f52.google.com with SMTP id h1so5570168oag.11 for <ietf-http-wg@w3.org>; Fri, 10 May 2013 14:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=u03KkFhGqa+aUQqLlxaT3U/ttEdz9bY7Ajpb1F2P4Gg=; b=StDKDrnatSWgs7vGB7w4fEgvQg9JJhkGWw63WkpyXV/75DWWVZMCIeSTtmmo9xFSGx HN+gHZy6HEuvr8FEK/F/M8Cl4NknRtl/LIXXoLe5R/RXZ1HLJ7TtS/qP07du7YdZqV75 aZVfRlVVBoUGIgZghU49BmX2gmKKC3WK6LOCoaEx2atcFl22CIOZsNIJe9rkb5dY+om+ ggd/3upIEgfYZT5Txn4/05ZqqEa1Z7NStg8AG/36LssxUMNtbPd4Ei7hmOznCB8JADfT aHg9acrb80mdovgFtE3lFmj5iQI4K2JLMv/wFWHTp3cajlnwyNJGeknZ0wzO6l72WL10 1kDg==
X-Received: by 10.60.141.226 with SMTP id rr2mr7854845oeb.35.1368220148358; Fri, 10 May 2013 14:09:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Fri, 10 May 2013 14:08:48 -0700 (PDT)
In-Reply-To: <CAA4WUYjFgJ28O5Jb58a5eodJMWe+CSe18Ow1wpETWJcjmedXRQ@mail.gmail.com>
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com> <CAA4WUYiwNSzvrY1LF_Sex_82TSDwMbTvYqo7LyKfBAOu0j4pfQ@mail.gmail.com> <CABP7RbdqnH0JK-UaMiaR5rLvZo8txywEcXXSUXa_y95hrLC5yA@mail.gmail.com> <CABP7Rbd-VfTFYurZ-JEKjHKOeKvZCKoYLGMXf+0mi-_wbdKYqA@mail.gmail.com> <CAA4WUYgfu=rcji-bdxNPsE9KCE4T67+vN9b0iojnvycx5R-StA@mail.gmail.com> <CABkgnnX=AemYGrBzWGX1VEUgKKrk+hR6YV0jg9qVMSdPiimBAA@mail.gmail.com> <CAFA1p16FHaSf7b1=mhe_Cb=ZqV1m0HVwkQNdW+pkJ0OkA9L-5A@mail.gmail.com> <CAP+FsNdifoF3aqQLB-EZjYqL3O2_uNEmNJ_+zAktu9zapKmT7w@mail.gmail.com> <CABP7RbcF3VXuhvP5StN9hHVj4K-2WMvBr37ur3iHmH-=2WAbHw@mail.gmail.com> <CAA4WUYgFccqU5-65mFPF_3i4OOROZQCdS+tEUeDMk4HP4JJX5Q@mail.gmail.com> <CABP7RbcQMEhu9ciuTQoR1dRw3UiUB=E_AeMjaNrhFgMPmmi+EQ@mail.gmail.com> <CAA4WUYjFgJ28O5Jb58a5eodJMWe+CSe18Ow1wpETWJcjmedXRQ@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Fri, 10 May 2013 14:08:48 -0700
Message-ID: <CABP7RbdnnCiDSDt5CwPfRYx-BGgz8eoMUDa2J4xaWztHkCbe+w@mail.gmail.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Hasan Khalil <hkhalil@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.52; envelope-from=jasnell@gmail.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.691, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UauZK-0001jQ-BI 6434310c58c2765ee230b40dc077c1c8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)
Archived-At: <http://www.w3.org/mid/CABP7RbdnnCiDSDt5CwPfRYx-BGgz8eoMUDa2J4xaWztHkCbe+w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17939
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, May 10, 2013 at 1:00 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
[snip]
>>
>> I do not presume the Window to be static at all.  In fact, quite the
>> opposite,  I expect it to be quite variable.  I do not want header frames
>> that are beyond an endpoints ability to process at any given point in time.
>> It's conceivable that if the widow size is 0, the receiver really doesn't
>> want the sender to initiate any new requests or to send arbitrarily large
>> blocks of headers.
>
> I don't get it. Then what does a halfway stance buy you? If you really want
> to prevent them from sending data, say that headers are included in flow
> control. If you're only shrinking the max frame size, but we can use a frame
> continuation bit, or there's a lower-bound on the frame-size, then the
> receiver isn't able to prevent the sender from sending arbitrary amounts of
> header data, but it's just forcing the sender to break it up into smaller
> frame sizes.
>>

It's not about preventing the data from being sent at all, it's about
breaking it up into smaller, more manageable chunks that are easier to
preempt and deal with incrementally.

If an endpoint says that it's only capable of handling 10k of data at
a time, whats the utility in sending a single frame containing 64k of
compressed header data that could potentially expand significantly
once decompressed?

- James

>> >>
>> >>
>> >> - James
>> >>
>> >> > I don't see any real benefits for limiting control frames to anything
>> >> > having
>> >> > to do with the window size as compared to sending a SETTING and
>> >> > having the
>> >> > default before there and having it completely decoupled from window
>> >> > size,
>> >> > and I do see a number of complications and ewws :/
>> >> > -=R
>> >> >
>> >> >
>> >> > On Fri, May 10, 2013 at 10:58 AM, Hasan Khalil <hkhalil@google.com>
>> >> > wrote:
>> >> >>
>> >> >> While I love the idea of limiting frames to 65535B, I hate the idea
>> >> >> of a
>> >> >> continuation bit.
>> >> >>
>> >> >>     -Hasan
>> >> >>
>> >> >>
>> >> >> On Fri, May 10, 2013 at 1:54 PM, Martin Thomson
>> >> >> <martin.thomson@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> On 10 May 2013 10:40, William Chan (陈智昌) <willchan@chromium.org>
>> >> >>> wrote:
>> >> >>> > [...] are we going to move forward with the frame
>> >> >>> > continuation bit?
>> >> >>>
>> >> >>> I think that this was implicit in our decision to limit frames to
>> >> >>> 65535 bytes (or less).
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>