W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

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

From: Adrien W. de Croy <adrien@qbik.com>
Date: Tue, 28 May 2013 23:19:05 +0000
To: "Martin Thomson" <martin.thomson@gmail.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em4e491b19-cd47-4dac-be6a-3d6c6a726721@bodybag>


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

>
Received on Tuesday, 28 May 2013 23:19:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC