Resent-Date: Tue, 28 May 2013 23:19:46 +0000
Resent-Message-Id: <E1UhTBC-0000YU-CV@frink.w3.org>
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
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
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

------ 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=20
example.

We're talking about making the field size in the definition of the frame=
=20
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=20
size limits were too small.  I can think of several off the top of my=20
head: DNS, DHCP and BGP

Trying to get widespread deployment of an extension to cope with that is=
=20
an awful mess, and something we shouldn't saddle ourselves with up=20
front.

There are still many DNS implementations that don't understand the size=20
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=20
an HTTP stream from IIS, it was 64kB.  I really don't think we should=20
reduce it.  Servers suffering from HOL issues can always reduce frame=20
size themselves for outbound.  As for inbound, if there is a settings=20
pre-negotiation (which is proposed), why not advertise max frame you=20
will accept?

>