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

James M Snell <> Tue, 28 May 2013 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9547221F984E for <>; Tue, 28 May 2013 09:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id thAvcYb13B0e for <>; Tue, 28 May 2013 09:25:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB3B121F986F for <>; Tue, 28 May 2013 09:25:02 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UhMgm-0004qp-7f for; Tue, 28 May 2013 16:23:56 +0000
Resent-Date: Tue, 28 May 2013 16:23:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UhMgP-0004p1-E5 for; Tue, 28 May 2013 16:23:33 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UhMgJ-00077P-Sm for; Tue, 28 May 2013 16:23:33 +0000
Received: by with SMTP id h2so10285146oag.33 for <>; Tue, 28 May 2013 09:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id fp18mr21055067oeb.35.1369758182044; Tue, 28 May 2013 09:23:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 May 2013 09:22:41 -0700 (PDT)
In-Reply-To: <>
References: <>
From: James M Snell <>
Date: Tue, 28 May 2013 09:22:41 -0700
Message-ID: <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
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: 1UhMgJ-00077P-Sm 56017f9cb351a177af135389afe54b9a
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <>
X-Mailing-List: <> archive/latest/18115
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 <> 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