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

James M Snell <jasnell@gmail.com> Fri, 10 May 2013 18:30 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 91D2821F85C3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 11:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.417
X-Spam-Level:
X-Spam-Status: No, score=-10.417 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 ukVYIwEsgXiH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 11:30:45 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 30B4821F9021 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 11:30:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uas4n-0002bN-QF for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 18:29:53 +0000
Resent-Date: Fri, 10 May 2013 18:29:53 +0000
Resent-Message-Id: <E1Uas4n-0002bN-QF@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1Uas4d-0002ZD-HI for ietf-http-wg@listhub.w3.org; Fri, 10 May 2013 18:29:43 +0000
Received: from mail-oa0-f53.google.com ([209.85.219.53]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1Uas4Y-000447-I3 for ietf-http-wg@w3.org; Fri, 10 May 2013 18:29:41 +0000
Received: by mail-oa0-f53.google.com with SMTP id g12so5357313oah.12 for <ietf-http-wg@w3.org>; Fri, 10 May 2013 11:29:12 -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=BBj+5C7CbsbOY2akeUuCv9l2s0ojT3hpFk0cEgExPw0=; b=XzPmDU1kTOZAJF8ip7LftTGLurtvrujTSqdptfmbBIlpZH4Q8/CXBCdcEyup8DKh4s h6nbkIf9/WkQtuujzuA54jXS6YFrHsBI818XRixCDaYl4C3IzFWeg1i5ZJ9PvLK9BHWR hDWhX4MjUpvTczDvVQjmFhCLiLh3wfYq28rezYQxGFTNtly4EyYPE+ZBtBaHySz4P0Jm VWpDtNchIbML/Rat0EvJdsn/114FKrEXep03N7MgzeTtR+gJ1ggQFGXfw9Wi9/6TJEX8 fYq6ypENv7tQxB1WFngxYKe1+MMsVS8E95G3aVhMjgvrpzCmMdnIYBZcH2O5T3IarXCg nOdw==
X-Received: by 10.60.55.231 with SMTP id v7mr7410796oep.135.1368208724423; Fri, 10 May 2013 10:58:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Fri, 10 May 2013 10:58:24 -0700 (PDT)
In-Reply-To: <CAA4WUYgfu=rcji-bdxNPsE9KCE4T67+vN9b0iojnvycx5R-StA@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>
From: James M Snell <jasnell@gmail.com>
Date: Fri, 10 May 2013 10:58:24 -0700
Message-ID: <CABP7Rbdcx6AC+s65x+ELZ=M55GE-3XR8NEFAhQSK-pVw0o7Jmw@mail.gmail.com>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Roberto Peon <grmocg@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.53; envelope-from=jasnell@gmail.com; helo=mail-oa0-f53.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.669, 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: maggie.w3.org 1Uas4Y-000447-I3 8967b2a9b5facbd077efc999022c4340
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/CABP7Rbdcx6AC+s65x+ELZ=M55GE-3XR8NEFAhQSK-pVw0o7Jmw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17923
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 10:40 AM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> Personally, I'm not sure if there's enough "rough" consensus here yet to
> commit anything. Just my two cents there.
>

Agreed. I created a branch and the pull request to track to proposal.
I will keep the branch up to date as we go until there is either a
consensus to commit or an alternative is accepted.

> On Fri, May 10, 2013 at 2:07 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> This is now pull request #92: https://github.com/http2/http2-spec/pull/92
>>
>> On Thu, May 9, 2013 at 2:20 PM, James M Snell <jasnell@gmail.com> wrote:
>> > On Thu, May 9, 2013 at 2:01 PM, William Chan (陈智昌)
>> > <willchan@chromium.org> wrote:
>> >> I discussed this with Roberto and Hasan. Here are some thoughts on
>> >> including
>> >> header blocks within flow control:
>> >>
>> >
>> > Note that my proposal does not explicitly state that the header blocks
>> > would be put covered by flow control, only that the current window
>> > size be used to limit the maximum allowed size of those frames.
>> > Whether or not headers count towards the flow control limits is a
>> > separate (but definitely related) question... with that in mind, some
>> > responses below...
>
>
> Thanks for the clarification, I did indeed misunderstand that. What's
> supposed to happen when the initial per-stream window is set to be smaller
> than what's necessary for a HEADERS+PRIORITY frame? We just never send the
> HTTP message then? Or are we going to move forward with the frame
> continuation bit?
>

The limit only effects individual frames, so the option here would be
to go with the continuation bit.

>>
>> >
>> >> * In the proposed text, it appears that only the compressed header
>> >> block is
>> >> counting towards the window. Is that really what's desirable in order
>> >> to
>> >> properly control memory? Processing the header block requires
>> >> decompressing
>> >> it, and that's what will be kept in memory buffers until drained by the
>> >> sink.
>> >
>> > Yes, I think it is desirable. The memory management for the
>> > decompressor state is separate from the notion of how much data the
>> > receiver is willing to accept over the network. It's likely, for
>> > instance, that the data in a DATA frame could be compressed as well.
>> > It would not really make sense to count the decompressed bytes there
>> > towards the flow control limits.
>
>
> I'm trying to figure out if I'm misunderstanding you or you're
> misunderstanding the concern. Let me give a concrete example, an HTTP/2
> proxy. When forwarding DATA frames, it doesn't have to decompress unless it
> wants to inspect the payload for some reason. It just forwards onward to the
> sink, unless the sink is not ready, in which case it buffers the frame
> (agnostic of whether or not it's compressed). On the contrary, for a
> HEADERS+PRIORITY frame, and IIUC, it *has* to decompress the header block to
> update the compression context appropriately without introducing HoL
> blocking with other things using the compression context. And if the sink is
> not ready to accept the headers, and then it most likely has to keep the
> decompressed header block around. That's my understanding at least, what did
> I miss?
>

The decompressor state is going to have it's own limit that is
independent of the frame size. I'm understanding what you're saying
but what I'm saying is that what you're describing is a different
issue.

- James