Re: Large Frame Proposal

In message <>
, Martin Thomson writes:

>My one big reservation is with the addition to WINDOW_UPDATE.  I think
>that it's unnecessary complexity.  The other changes you make are
>well-enough supported, but this seems like feature creep to me.

Actually I suspect this will be a much more efficient way to
prioritize multiple competing streams than the complex priority
scheme currently proposed.

So feature creep ?  Well, yes.  But if it appears to make all the
priority stuff surplus to requirements, then it's a feature shaving
and much simpler to explain and implement.

>I think that the setting for maximum header block size needs to cover
>PUSH_PROMISE (we already have settings that govern PUSH_PROMISE).

Good catch!

>Any why 16384 rather than 16383?

Because computers have VM pages that are sized 2^n and many hardware
facilities work best in entire words.

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, 7 July 2014 19:49:17 UTC