W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Call for Consensus: Frame size (to address #553)

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 14 Jul 2014 15:21:44 +0000
To: Jeff Pinner <jpinner@twitter.com>
cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, ynir.ietf@gmail.com, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <260.1405351304@critter.freebsd.dk>
In message <CA+pLO_hTyehQXNdk5YNTmb_fTx5WAUnEigoBn+U97PSPeUDpLw@mail.gmail.com>, Jeff Pinner writ
>With a 10 byte header (to fit a 32-bit length field), setting the
>MAX_FRAME_SIZE to 256 is almost a 4% !! overhead in the transmitted
>bytes just for framing the data.
>I can't imagine I would do anything other than send a GO_AWAY and
>close the connection.

And that's fine, if you're sure you'll never download new firmware
to "intelligent lightbulbs" etc.

>Can we just keep the minimum frame size the same as today and use
>settings to increase only?

Because that would force anybody with a small microcontroller to
be non-compliant for no good reason.

>The argument against doesn't make sense to me, embedded clients
>already have to deal with a 16-bit IP length field so the idea that
>they can't handle a 14-bit HTTP length field seems absurd.

They typically only have to deal with a single packet of their
chosen transport.  The rest can be held as state.

Please understand that the 256 is there to avoid people implementing
smaller limits, not larger limits.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 14 July 2014 15:22:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC