Proposal - Reduce HTTP2 frame length from 16 to 12 bits

Patrick McManus <> Tue, 28 May 2013 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7CD521F8EC1 for <>; Tue, 28 May 2013 07:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p3ETe0Nief-u for <>; Tue, 28 May 2013 07:22:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7ADEE21F8E76 for <>; Tue, 28 May 2013 07:22:38 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UhKlu-0006vu-9U for; Tue, 28 May 2013 14:21:06 +0000
Resent-Date: Tue, 28 May 2013 14:21:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UhKlb-0006sb-IF for; Tue, 28 May 2013 14:20:47 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UhKlS-0001Co-4x for; Tue, 28 May 2013 14:20:47 +0000
Received: by with SMTP id h1so10147809oag.11 for <>; Tue, 28 May 2013 07:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Rdc0fFUnBncO/1mLDUN+munjGyT+/9UM37kCqLgaltw=; b=RdgIBV0gsz9x7HA/RBNb9jKwnWxBqYvexJjhTj4QVQmZCARpwtIYTyfjnz7zatI4Tc vxX7++dT4mmyzOEHcOd3V3MQPdEjvpxIzig4QsKjdaigFSZylcWrsrJtgquuABzD8FqE pD1Bt1sjone7+L9yKlweBC2Lz55tOhLoSMPBGRNrRZEQR/LYmaZtGpmJ7ZNqRK+9iCHK 1PyLXCJZjU9vXGY0XITQrxylaoDTYEq9SgMNhY1fBIqjegoLzXvyZO9/HOWvUNwgP1lS 2yneTo0eAW9kJoUdKljLAd8/tW7e5MQoz9ed/G1ibseviBpnv4ncxIHweXdwaZF9AKPk Pvag==
MIME-Version: 1.0
X-Received: by with SMTP id ol8mr1263016oeb.104.1369750812031; Tue, 28 May 2013 07:20:12 -0700 (PDT)
Received: by with HTTP; Tue, 28 May 2013 07:20:11 -0700 (PDT)
Date: Tue, 28 May 2013 10:20:11 -0400
X-Google-Sender-Auth: vZxy-P_rL-_ebnYP9_sCmDHBnhQ
Message-ID: <>
From: Patrick McManus <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=089e013cb85c95019f04ddc7f6be
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.706, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UhKlS-0001Co-4x 7e9e8fa5eb1e72e069a86b9b360f1760
Subject: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
Archived-At: <>
X-Mailing-List: <> archive/latest/18112
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.