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

William Chan (陈智昌) <willchan@chromium.org> Tue, 28 May 2013 17:00 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 1A02C11E80E6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 10:00:58 -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 0SmkHWSAnBQ9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 10:00:39 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6318111E80E3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 10:00: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 1UhNEg-0007ru-3Y for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 16:58:58 +0000
Resent-Date: Tue, 28 May 2013 16:58:58 +0000
Resent-Message-Id: <E1UhNEg-0007ru-3Y@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 1UhNET-0007r6-Ty for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 16:58:45 +0000
Received: from mail-qe0-f44.google.com ([209.85.128.44]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UhNES-0008Jr-18 for ietf-http-wg@w3.org; Tue, 28 May 2013 16:58:45 +0000
Received: by mail-qe0-f44.google.com with SMTP id 6so4505995qeb.31 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 09:58:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8Z3Kh69Ir5kv2D5446amUaPT1WhRBOkNGe+/LN95mbE=; b=LzMMzWb7u7+bjR8cG6fJXe0XwUBXbzL94L6c1ERJzdniQaC1XA/cuHBEyWAjS7hB6w /sl434UISwAXUWD9ispIwHt2QauTOA7nNQq0r0s8A0OczER6imCs2wvei8PLn3M77n4z 4Ceb5PLMbKlsdLzCMVYG29g9AnjzbAUdHTserPXlsepfLBq5OJ/V/M+sS/liZJakfMac IunK3e+DtibI9VZdFho/rTOeVDWjyDNBaxgITG1Orxw+7Nlvv4fC/FR6hwV5dw/GgXCi L8AHoCopbVVh9V/ORkG7oEje4S9v9xx9YNAcKLBavbddjZmLNsuLH5WX1xTJZSLYaC+1 Cqxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8Z3Kh69Ir5kv2D5446amUaPT1WhRBOkNGe+/LN95mbE=; b=DOPDoicbig4CP7/L5ZReQURVyARhRuLiz0jYzw4MiGIW6MwvjtLDCtUjIECAd1XpAt MH8WiAR/VHaMbk4OtBq+0w4ByLqQ377sT2D9TWgkgT/ImCXxC/0CfYp4KPJXxg8Ys++I 9FtyJiTeI9VgQcubatAuTbZ/QKqSVSNDKqBqk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=8Z3Kh69Ir5kv2D5446amUaPT1WhRBOkNGe+/LN95mbE=; b=ANwjSiCoL6yTRjUh60VxBV4+0+We3dInHPcfm1MN8pCU79cMNnnGa/3PzWfw6XQpId pqwWmTlkW6Q8tMjsOSn2xuOW2cNgamA+bWWVsMeWV3SKtiA8Edp7KzFCI9f+ZJJVCYaw pLY9Z7aGgSKlNiKQp9q0rayGQBygeojY8S95zrxuQbxb+80LoVLdnI0IBTlqfAvvD1wK Px4cXwjdLaFdRlP4PtJ3E9jmuANgWUkNfBziYbpwYlRZDEoFCofuVGCtjdMPugeeZQtb Ha5n0U5aaWTGVjtceKyYix3ORc4LELXzOakDfLrKe4ozWxBm2Q0xqdWMGV7IysR7RHvO EnLQ==
MIME-Version: 1.0
X-Received: by 10.229.164.79 with SMTP id d15mr3944985qcy.3.1369760298348; Tue, 28 May 2013 09:58:18 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.62.133 with HTTP; Tue, 28 May 2013 09:58:18 -0700 (PDT)
In-Reply-To: <CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com>
References: <CAOdDvNoAjiRSBv9ue6RgCQJ4wMNQcKBH2a8zVa4_96wbp=g8MA@mail.gmail.com> <CABP7Rbefh0HxT7Pui_F8viNvu8232O3Qt=VaR6SgsL1DQarVSA@mail.gmail.com>
Date: Tue, 28 May 2013 09:58:18 -0700
X-Google-Sender-Auth: tfCtG9WEu2MIwCr3Li-_oTGeUZ0
Message-ID: <CAA4WUYgKsDudsSAywWSwz5KVsEV5iUREqjmYVB5sWuc+11ujOQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=14dae9c0963a02cf7f04ddca2c07
X-Gm-Message-State: ALoCoQkM+VoEARMfSMhPCOg7yWDo/1rKgJJGkU6TkSbgw8SAFnbI6XbCAOPB4wzIAP2xH/F19MDN96Segss8mJKR4vKf/C6M2TfuSNulQZR7uoeRhXfqPuCBtc9pby5RjLrObPrOEYFupHQ3/qSHZlsJsXdhICKkr+VPoxEtjV2ATbioq1KNdEvWpRKYn+SoCumezXGKrmQm
Received-SPF: pass client-ip=209.85.128.44; envelope-from=willchan@google.com; helo=mail-qe0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.200, 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.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UhNES-0008Jr-18 75829235e16bf50f1ba2e0dabab4ab32
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/CAA4WUYgKsDudsSAywWSwz5KVsEV5iUREqjmYVB5sWuc+11ujOQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18116
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>

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