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

James M Snell <jasnell@gmail.com> Tue, 28 May 2013 16:25 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 9547221F984E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 09:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.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 thAvcYb13B0e for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 09:25:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B121F986F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 09:25:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhMgm-0004qp-7f for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 16:23:56 +0000
Resent-Date: Tue, 28 May 2013 16:23:56 +0000
Resent-Message-Id: <E1UhMgm-0004qp-7f@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 1UhMgP-0004p1-E5 for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 16:23:33 +0000
Received: from mail-oa0-f46.google.com ([209.85.219.46]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UhMgJ-00077P-Sm for ietf-http-wg@w3.org; Tue, 28 May 2013 16:23:33 +0000
Received: by mail-oa0-f46.google.com with SMTP id h2so10285146oag.33 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 09:23:02 -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; bh=kPLRrkPBgyIWfa9+0wIjkNSLaxlyG4EoOruXf5dUfYc=; b=tMs/SCGFhdbLlF6EZiBTraUx0kfD2u1Q4/KxHfKPwqlyH/NyoclLWrQVvx5JUeCQCr m1ZFX0wfgEOJbQZN+InX6EirGL2h31om9Q1ZX0QURsL+nkn5s20YfKqMO/xgWYKvxp+B D8Zyc72wDs/yhvvz2Y7FY01x29zyLsqHZZ/nt44o3q940CF6vgZhlXQHdXBqCg3a6wAP 1L9rn9HNzuUZqUIXtgem08keY0Ol/yM/PbZjaKPYows3cPqjOkTrFO0wktLkqghoOV/x asV0HZxLsfKljP4yXbWAScRqC99MIOHvTnJ7iP9NzbQzMA4ofKxbyNSE7qen62UI1GEY 8Rtw==
X-Received: by 10.60.102.178 with SMTP id fp18mr21055067oeb.35.1369758182044; Tue, 28 May 2013 09:23:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Tue, 28 May 2013 09:22:41 -0700 (PDT)
In-Reply-To: <CAOdDvNoAjiRSBv9ue6RgCQJ4wMNQcKBH2a8zVa4_96wbp=g8MA@mail.gmail.com>
References: <CAOdDvNoAjiRSBv9ue6RgCQJ4wMNQcKBH2a8zVa4_96wbp=g8MA@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 28 May 2013 09:22:41 -0700
Message-ID: <CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.219.46; envelope-from=jasnell@gmail.com; helo=mail-oa0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.703, 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 1UhMgJ-00077P-Sm 56017f9cb351a177af135389afe54b9a
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/CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18115
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>

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