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

"Adrien W. de Croy" <adrien@qbik.com> Tue, 28 May 2013 23:20 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 A05B521E8086 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 16:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 QYI014br5+K9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 May 2013 16:20:11 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79821F90E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 May 2013 16:20:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UhTBC-0000YU-CV for ietf-http-wg-dist@listhub.w3.org; Tue, 28 May 2013 23:19:46 +0000
Resent-Date: Tue, 28 May 2013 23:19:46 +0000
Resent-Message-Id: <E1UhTBC-0000YU-CV@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UhTB0-0000VJ-F8 for ietf-http-wg@listhub.w3.org; Tue, 28 May 2013 23:19:34 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UhTAz-00075n-JD for ietf-http-wg@w3.org; Tue, 28 May 2013 23:19:34 +0000
Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4556)) with SMTP id <0019740441@smtp.qbik.com>; Wed, 29 May 2013 11:19:06 +1200
Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4555)) with SMTP id <0000213857@SCREECH.qbik.local>; Wed, 29 May 2013 11:19:06 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "Martin Thomson" <martin.thomson@gmail.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Date: Tue, 28 May 2013 23:19:05 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <CABkgnnUcNqqvNJpBbP8REJRrWYz+45-Side5iBr6nUZHgWMATQ@mail.gmail.com>
Message-Id: <em4e491b19-cd47-4dac-be6a-3d6c6a726721@bodybag>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.18025.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.836, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UhTAz-00075n-JD 390f4584fb8a2a4130c0f6b8fdf31a9d
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/em4e491b19-cd47-4dac-be6a-3d6c6a726721@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18130
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>

------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 29/05/2013 11:11:01 a.m.
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>On 28 May 2013 15:50, Adrien W. de Croy <adrien@qbik.com> wrote:
>>  it makes no sense to chisel into stone 12bits in the protocol.
>
>Not to pick on Adrien, but this isn't stone.
>
>Say we do go with 12 bits. That doesn't prevent a future extension to
>the protocol that enabled the negotiation of larger frame sizes. It
>doesn't prevent the use of a new protocol that had 37bits dedicated to
>frame sizes. The only cost is period of suffering where the 12 bit is
>the effective limit until various affected parties move to 37.
IME this simply doesn't happen.  Look at DHCP and/or DNS if you want an 
example.

We're talking about making the field size in the definition of the frame 
header be 12 bits long.

If that isn't setting it in stone I don't know what is.

>
>Fact is, none of resembles stone on anything but the shortest of
>timescales.
are you a geologist? :)

>You might (reasonably) say that the cost of suffering
>times the duration of suffering is excessive, but then you have to
>make that case. Impress upon us the magnitude of that pain, and/or
>provide reasoning for why that pain would be prolonged.

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

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?

>