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

William Chan (陈智昌) <willchan@chromium.org> Fri, 10 May 2013 19:22 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 9F09D21F9239 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 12:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 T78QIK6qWVXC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 12:22:31 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D31F21F91CE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 12:22:28 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UastM-0005jj-Mz for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 19:22:08 +0000
Resent-Date: Fri, 10 May 2013 19:22:08 +0000
Resent-Message-Id: <E1UastM-0005jj-Mz@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UastB-0005ge-MV for ietf-http-wg@listhub.w3.org; Fri, 10 May 2013 19:21:57 +0000
Received: from mail-qc0-f179.google.com ([209.85.216.179]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1Uast8-0003Az-Lv for ietf-http-wg@w3.org; Fri, 10 May 2013 19:21:57 +0000
Received: by mail-qc0-f179.google.com with SMTP id d1so2415714qcz.24 for <ietf-http-wg@w3.org>; Fri, 10 May 2013 12:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dyna57TDKKgaguLyQtRQKybTym23+jD/brIb4QY5s4Y=; b=K/n2L6a24kglD2Vjqgm8smzZbIyPkUy3gGLD2C8SQRAmlf468ClMtSgCMeqp3ncLlr msGwFcUJE0QneKe/xLS/M2bRC0vsArSHtAMDFbCREYnMGiJlCGUmonkqDli5QBE2dVYh 9TYQUsvpIwzDoau1/LBKvFyu3bIRtVHAJCz1J/QJj5+NFPapK570xVz2kYyZG1npyIv9 K/7Iw7ran0wFY6MBl3LRLU5Elx3R5INByS9Wb7wiRh94Weo6n4jvDOSM4yiNYATWBxjT y1c8CncpZNXr9sKpt39wZJAelOZH67StTWyw+7F9Tvjnk0WAHguH26yVi4Ac3iF9qSGr h7/w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dyna57TDKKgaguLyQtRQKybTym23+jD/brIb4QY5s4Y=; b=M5GRDrqWXNAjHUW/QGwyWZGn9j6OeDRbkFlRsbFaKk1FCK6zn8eDHYMD/czkbXDRXN LOw2r62NjUgIuPfdBCXa6VjMSQ1/y7hcex9jaSmRdcvFdW7YNwjFqjoBPtoO8IaybY9m TfCzV5jWOT4G6Nd1pqj5E0M5a4Mc2bocEjWiw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Dyna57TDKKgaguLyQtRQKybTym23+jD/brIb4QY5s4Y=; b=jeJunduSriHpw/D3XxxRmSZwH4ewROzDTDYd2WfkO/RBHuZSn6c2xV2Wyw+E2+m/1X 5LI4K0zOXsKyQrFdtWfxdq5fk2a7JGWpENn4JZT3XI3PWp4tqPAJzX0XLrlyxPzlFQl3 3mFKVq+qBmIQ85/RrwVwGiXdMt5jZUWVU57KbE6WYq+lGvuA+1gINeBIDTBjvamDs7XJ w99/G+KgvXmAmiADKjTMUPWSuei0W6+AqM2fnfNgOmKyHoVyqD39/dwdcISoq2Ut/MNe nOBsTosWquc9aoqUl0Td2/oUQJSAxrQPhI+xQ2svCP5Fkk+MKEWdFZJHq9BHqZJlCe5G XTkA==
MIME-Version: 1.0
X-Received: by 10.49.61.226 with SMTP id t2mr3610991qer.40.1368211865275; Fri, 10 May 2013 11:51:05 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 10 May 2013 11:51:05 -0700 (PDT)
In-Reply-To: <CABP7Rbdcx6AC+s65x+ELZ=M55GE-3XR8NEFAhQSK-pVw0o7Jmw@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> <CABP7Rbdcx6AC+s65x+ELZ=M55GE-3XR8NEFAhQSK-pVw0o7Jmw@mail.gmail.com>
Date: Fri, 10 May 2013 15:51:05 -0300
X-Google-Sender-Auth: VyqmYroD9fw_iH4fuxVZnbgHiRo
Message-ID: <CAA4WUYhchxp=8tTDbGxsHn1WYhmWwsdZJe=mMfxzUVc8xP-jvw@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
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: multipart/alternative; boundary=047d7bdc103235445c04dc61a697
X-Gm-Message-State: ALoCoQkevn2aLMXZEr94BANqJZFSaTlM29MWGrbRfnlhdkphrz2vcyyGt/uOJ+yzOyTVj/LAEi13FGXOqbi1dHZOmmzUe6siARgJu86FNDsACkTniSIOI5j5MJMKGKTQdUrAFE8CQ1QWGBmGGCXyrGkOnAFvjLBSKjFzg7X48u7/ewUhzAf1GTmVJkP6BjdU+OJgswSn/w5B
Received-SPF: pass client-ip=209.85.216.179; envelope-from=willchan@google.com; helo=mail-qc0-f179.google.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.058, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.315, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Uast8-0003Az-Lv 3fde5a0876ed8f8b63e584d93f4016cd
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/CAA4WUYhchxp=8tTDbGxsHn1WYhmWwsdZJe=mMfxzUVc8xP-jvw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17927
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 2:58 PM, James M Snell <jasnell@gmail.com> wrote:

> 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.
>

I read Roberto's email and this mostly makes sense to me now (I didn't
realize that decompressing would use pointers into the compression context
rather than copying, that was the missing context leading to
misunderstanding here). I think there are some adversarial cases where this
doesn't work, but that's OK.


>
> - James
>