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

Patrick McManus <mcmanus@ducksong.com> Wed, 29 May 2013 00:01 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 924A311E80DE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 17:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1s7PisfjbZS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 17:01:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39B11E80E2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 17:01:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhTo6-0002yt-3p for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 23:59:58 +0000
Resent-Date: Tue, 28 May 2013 23:59:58 +0000
Resent-Message-Id: <E1UhTo6-0002yt-3p@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1UhTnt-0002wm-GV for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 23:59:45 +0000
Received: from mail-ob0-f176.google.com ([209.85.214.176]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1UhTns-0006JJ-Jt for ietf-http-wg@w3.org; Tue, 28 May 2013 23:59:45 +0000
Received: by mail-ob0-f176.google.com with SMTP id v19so2422512obq.21 for <ietf-http-wg@w3.org>; Tue, 28 May 2013 16:59:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=Avdgkb89RfZNcVNq0jytcz1UmBHQP0rq0AbvgpqRYdc=; b=H4ufUvTAI8T3FpqQ5dekzxdTXMW/bCFt555Ogo2JGk+rOf3MXQJD8V2457hgSRPAgg uiQfD9iz10mTyxCdqdRsw1UEBGQjoZPvlXsKHyKzLpxoyj+VOMJyAY/8+CpBBb0hfPp2 EAF+kyiKCHbfB58kUCxmbls53KzdMdEoC4w6wp3rBaPk+Ya5qofQoTQjmUEJGQdeOCoM lhepiT/vV+ns6F2tytDJOiT0+H1qISKVBXD+oGtANRXa4fbVKiT9pqv0baBbm1nPYcjH H1bI6fZOiDznzlXi80AP6GTvarjrSifLRaC3Avo/hCJC41/oAqs0kXDPp1ZhuqoNU2qA PI9w==
MIME-Version: 1.0
X-Received: by 10.60.41.101 with SMTP id e5mr77516oel.112.1369785558348; Tue, 28 May 2013 16:59:18 -0700 (PDT)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.105.230 with HTTP; Tue, 28 May 2013 16:59:18 -0700 (PDT)
In-Reply-To: <em4e491b19-cd47-4dac-be6a-3d6c6a726721@bodybag>
References: <CABkgnnUcNqqvNJpBbP8REJRrWYz+45-Side5iBr6nUZHgWMATQ@mail.gmail.com> <em4e491b19-cd47-4dac-be6a-3d6c6a726721@bodybag>
Date: Tue, 28 May 2013 19:59:18 -0400
X-Google-Sender-Auth: B42SDnkA4kxe7y5SZU4t5h9dzjY
Message-ID: <CAOdDvNo=Zi+W7tF9-J=aTtXzRE_pOW-tV+kDTYz_8V7LMoHmAw@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e013cc4289fb97f04ddd00d28"
Received-SPF: pass client-ip=209.85.214.176; envelope-from=patrick.ducksong@gmail.com; helo=mail-ob0-f176.google.com
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: maggie.w3.org 1UhTns-0006JJ-Jt f7d6fa767732d91e764c0d84496e1f84
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/CAOdDvNo=Zi+W7tF9-J=aTtXzRE_pOW-tV+kDTYz_8V7LMoHmAw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18133
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 7:19 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
>
> take a look at any protocol where after a while people decided that the
> size limits were too small.  I can think of several off the top of my head:
> DNS, DHCP and BGP
>
> I don't think those are good comparisons here because those protocols have
maximum atomic message sizes of one sort or another, while here we are
discussing the size of the atom in a format that already takes multiple
atoms - not the size of the message. I think you make a better argument for
getting rid of FRAME_TOO_LARGE. There aren't any streams that can be
expressed with 24 bit frame sizes that can't be with 16, 14, or 12. Its
just a matter of various forms of overhead and responsiveness.

I brought this to the working group because I believe in running code and
the experience I have gotten here so far tells me most implementations so
far haven't gotten this right. (I've seen at least 3 different one so far
that will write the whole document in 1 frame if they can fit it in spdy's
24 bits - even though that's just as bad as http/1 pipelines) and a good
spec can generate good implementations. Implementation advice is fine, but
its better if it just does the right thing.. and in this case imo a
responsive protocol requires smallish frames.




> Trying to get widespread deployment of an extension to cope with that is
> an awful mess, and something we shouldn't saddle ourselves with up front.
>
> There are still many DNS implementations that don't understand the size
> extensions.  Look at the contortions DHCP took to try to reclaim space.
>
> As for 64kB.  Last time I counted TCP stream bytes between PSH flags on an
> HTTP stream from IIS, it was 64kB.  I really don't think we should reduce
> it.  Servers suffering from HOL issues can always reduce frame size
> themselves for outbound.  As for inbound, if there is a settings
> pre-negotiation (which is proposed), why not advertise max frame you will
> accept?
>
>
>>
>
>