Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits

James M Snell <jasnell@gmail.com> Tue, 28 May 2013 18:52 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 A55A121F91C4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 11:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level:
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 nK9nGIxadSEO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 11:51:53 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F049121F96A4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 11:51:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhOz9-0006LE-KA for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 18:51:03 +0000
Resent-Date: Tue, 28 May 2013 18:51:03 +0000
Resent-Message-Id: <E1UhOz9-0006LE-KA@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 1UhOyx-0006Jh-Sv for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 18:50:51 +0000
Received: from mail-ob0-f169.google.com ([209.85.214.169]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UhOyw-0003fJ-Q5 for ietf-http-wg@w3.org; Tue, 28 May 2013 18:50:51 +0000
Received: by mail-ob0-f169.google.com with SMTP id up14so2966842obb.28 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 11:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2E21cbxxaUDKPFfTbjAD+Ml8Nsz8M0mKpAThI4zeAKI=; b=rdtqrP5wukTxmaF6FVh/gIoZsD04RmlOYgYaf55HaUF3v6D7AylJ6mbTMVnzOm9DpV L5hYUNM3WTCtNKjJVdVD6zksUMB0TYG5FCYfH77jApaaMtNPwsU1qaLeauOJlV2aPZLx DuCk4/q48oBlakOiGsvNfySwX+CyLm7dVdFhkXptmEP1igfMF+cA0zaq+KoYYKHmMAvO dpJPGgmTT0IQDpMJvmTySe3ETf2faSCbPEYPBQCJwiLBQiG0b2RezY5fGrkaZh83Ta26 4htVG4JcKrrvbTA/LFlJp8FzLPqaeCf6O7O9X92p9gGZSz4635OVC4vJlW3s24mQ35Wk XeYA==
X-Received: by 10.60.80.103 with SMTP id q7mr21256551oex.135.1369767024873; Tue, 28 May 2013 11:50:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Tue, 28 May 2013 11:50:04 -0700 (PDT)
In-Reply-To: <CAP+FsNdejY=K4fp6jMh1AzSkMpdxWNd+cCnaF6uw2GPfMVtjAA@mail.gmail.com>
References: <CAOdDvNoAjiRSBv9ue6RgCQJ4wMNQcKBH2a8zVa4_96wbp=g8MA@mail.gmail.com> <CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com> <CAA4WUYgKsDudsSAywWSwz5KVsEV5iUREqjmYVB5sWuc+11ujOQ@mail.gmail.com> <CAP+FsNdejY=K4fp6jMh1AzSkMpdxWNd+cCnaF6uw2GPfMVtjAA@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 28 May 2013 11:50:04 -0700
Message-ID: <CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Will Chan <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.169; envelope-from=jasnell@gmail.com; helo=mail-ob0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.694, 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 1UhOyw-0003fJ-Q5 ed075628a3f9a8b12480b909ee995ed8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <http://www.w3.org/mid/CABP7Rbf6Ls8pBf9Rons9hgLeXjnm-yk6t6kebk1EXcS3bTdf_Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18120
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 Tue, May 28, 2013 at 11:41 AM, Roberto Peon <grmocg@gmail.com> wrote:
> As a reverse proxy, I've seen properties for which 4k writes/reads were too
> small and induced latency increases.
>

I haven't played with this part too much yet but this is my general
suspicion also.

> Admittedly, frame size doesn't have to be the same as read/write size, but
> it certainly does encourage that implementation (which is, I think, the
> point of smaller max frame size that you proposed).
>
> I propose we keep the 16 bit frame size and instead allow the (now
> negotiated setting of) max frame size to default to 12 bits worth, with that
> going upwards out downwards when a settings frame arrives from the other
> side indicating it's max receive size. HK
>

Honestly, I'd prefer to do away with frame size negotiation altogether
because of the potential for path mtu style issues. Keeping the 16-bit
size for now with strong encouragement (SHOULD, perhaps?) for keeping
sizes around 12-bit lengths for the most common cases  seems like the
right approach.

-- James

> This would give the best chance that the code would be written in such a way
> as to adapt with the times as they change.
> -=R
>
> On May 28, 2013 10:01 AM, "William Chan (陈智昌)" <willchan@chromium.org>
> wrote:
>>
>> Can you clarify what you mean by a documented performance metric for
>> non-browser use cases? I don't think Patrick said anything browser specific.
>> He provided some serialization latency numbers and noted that they are high
>> enough to impact responsiveness. And then he provided numbers on overhead.
>>
>> I, for one, find the responsiveness argument compelling for browsers. I'm
>> not completely sure 0.2% is low enough overhead for everyone, but I wouldn't
>> complain about it. And in absence of complaints, I guess I'd support moving
>> forward with only 12 bits for length.
>>
>>
>> On Tue, May 28, 2013 at 9:22 AM, James M Snell <jasnell@gmail.com> wrote:
>>>
>>> Currently, my only challenge with this is that, so far, we have not
>>> seen any documented performance metrics for non-browser based uses.
>>> .That said, I don't really have the time currently to put together a
>>> comprehensive set of such metrics so it wouldn't be polite of me to
>>> insist on them ;-) ... perhaps for now we ought to keep the 16-bit
>>> size but include a recommendation about not exceeding 12-bits, then
>>> see what more implementation experience does for us.
>>>
>>> On Tue, May 28, 2013 at 7:20 AM, Patrick McManus <mcmanus@ducksong.com>
>>> wrote:
>>> > Hi All,
>>> >
>>> > I've been looking at a lot of spdy frames lately, and I've noticed what
>>> > I
>>> > consider a common implementation problem that I think a good http/2
>>> > spec
>>> > could help with. I'm commonly seeing frames large enough to interfere
>>> > with
>>> > effective prioritization. I've seen this from at least 3 different
>>> > servers.
>>> >
>>> > The HTTP/2 draft has a max frame size of 16 bits, which is a huge
>>> > improvement from spdy's 24. I propose we reduce it further to 12. (i.e.
>>> > 4096
>>> > bytes).
>>> >
>>> > The muxxed approach of multiple streams onto one connection done in
>>> > HTTP/2
>>> > has great advantages, but the one downside of it is that it creates
>>> > head of
>>> > line blocking problems between those streams dictated by frame
>>> > granularity.
>>> > With small frames this is pretty manageable, with extremely large ones
>>> > we've
>>> > recreated the same head of line problems that HTTP/1 pipelines have.
>>> > The
>>> > server needs to  be able to respond quickly to higher priority events
>>> > (including cancellations) and once it has written a frame header to the
>>> > wire
>>> > it is committed to the entire frame for how ever long it takes to
>>> > serialize
>>> > it. IMO the shorter that time, the better.
>>> >
>>> > Our spec can help implementations do the right thing here by limiting
>>> > the
>>> > max frame size to 12 bits.
>>> >
>>> > It takes 500msec to serialize 64KB at 1Mbit/sec... 125msec at
>>> > 4Mbit/sec.
>>> > Those are some pretty notable task-switch times. Dropping the frame to
>>> > 4096
>>> > cuts them to 32msec and 8 msec.. that's much more responsive, at the
>>> > cost of
>>> > 120 extra bytes of transfer (< 1msec at 1Mbit/sec).
>>> >
>>> > In general - the smaller the better as long as the overhead doesn't get
>>> > to
>>> > be too large. At 8 in 4096 (~.2%) I think that's acceptable. Its
>>> > roughly the
>>> > same overhead as a VLAN tag.
>>> >
>>> > Obviously this makes a continuation bit for control frames absolutely
>>> > mandatory, but I think we're already in that spot with 16 bit frame
>>> > lengths.
>>> >
>>> > -Patrick
>>> >
>>> >
>>>
>>
>