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

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 14:19:27 UTC