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: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 28 May 2013 19:59:18 -0400
Message-ID: <CAOdDvNo=Zi+W7tF9-J=aTtXzRE_pOW-tV+kDTYz_8V7LMoHmAw@mail.gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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:
> 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?
Received on Tuesday, 28 May 2013 23:59:45 UTC

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