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

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.

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

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.

On Mon, Jul 14, 2014 at 7:18 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <0356EBBE092D394F9291DA01E8D28EC201187F1409@SEM002PD.sg.iaea.org>, K.Morgan@iaea.org w
> rites:
>>On Monday,14 July 2014 11:21, phk@phk.freebsd.dk wrote:
>>> Why should we force applications for whom 256 is plenty to use something
>>> higher ?  Who gains anything by us doing so ?  And if we insist on some lower
>>> limit which is onerous for tiny devices, do you think they are going to spend 8
>>> times more for their microcontroller or ignore what we say ?
>>
>>I think the issue can be broken down as follows:
>>
>>1) What, if anything, is required if an endpoint's peer advertises a
>>   MAX_FRAME_SIZE *greater* than 16K?
>>
>>2) What, if anything, is required if an endpoints' peer advertises a
>>   MAX_FRAME_SIZE *smaller* than 16K?
>
> Substitute "whatever this endpoint prefers" for 16K, since 16K isn't magic either.
>
> Answer:  Send frames no larger than the smaller of the two endpoints wants.
>
> There can only ever be an issue with the first request, which is
> typically sent before the peers SETTINGS arrive.
>
> If this is a brand new contact, the client and server has never
> seen each other before, the user typed a FQDN in the addressbar:
> The request is "GET /" and the 256 byte limit is not a relevant
> limit in practice, since it would take a FQDN that compresses
> Host: to around 200 bytes before it fails.
>
> If this is a brand new contact, the client followed a link on some
> web-page:  There is a strong presumption that a "GET $url" will
> fit in the servers MAX_FRAME_SIZE, otherwise the link is effectively
> dead for everybody.
>
> If the client has previously been in touch with another server in
> the same domain cookies may be sent.
>
> But if so, there is a very strong presumption that all the servers
> of the domain will announce frames big enough to accept the cookies,
> otherwise they would be dead for the world at large.  (This is
> an adminstrative variant of the FQDN issue above.)
>
> If the browser has contacted this server previously, it may have
> cookies and other state (URL from bookmarks etc.)  here is also
> every reason in the world to belive that this will fit in whatever
> MAX_FRAME_SIZE the server tells us in a RTT:  That's how we got
> the contact state in the first place.
>
> If the first request on a connection is a PUT/POST or other request
> with an entity-body, there is a valid question about what size of
> DATA frame to send the entity body with ?
>
> The answer is:  Send max(HEADERS.length, 256) byte DATA frames until
> the SETTINGS have arrived from the other end.  The only cost is a
> slightly higher transmission overhead for the first RTT (but better
> multiplexing with other parallel requests).
>
> So while there is a theoretical problem of a client connecting to
> a server point blank and dumping XXkB frame on it, in practice that
> only happens if the server has prevously revealed that it handles
> that or if the client has hostile intent.
>
> So no, all we need is a smallest MAX_FRAME_SIZE.
>
> But do note that I also proposed that all implementations SHOULD
> be configurable to 16KB.  People will probably take that as
> strong clue for their defaults.
>
> --
> 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:19:10 UTC