Proposal - Reduce HTTP2 frame length from 16 to 12 bits

Hi All,

I've been looking at a lot of spdy frames lately, and I've noticed what I
consider a common implementation problem that I think a good http/2 spec
could help with. I'm commonly seeing frames large enough to interfere with
effective prioritization. I've seen this from at least 3 different servers.

The HTTP/2 draft has a max frame size of 16 bits, which is a huge
improvement from spdy's 24. I propose we reduce it further to 12. (i.e.
4096 bytes).

The muxxed approach of multiple streams onto one connection done in HTTP/2
has great advantages, but the one downside of it is that it creates head of
line blocking problems between those streams dictated by frame granularity.
With small frames this is pretty manageable, with extremely large ones
we've recreated the same head of line problems that HTTP/1 pipelines have.
The server needs to  be able to respond quickly to higher priority events
(including cancellations) and once it has written a frame header to the
wire it is committed to the entire frame for how ever long it takes to
serialize it. IMO the shorter that time, the better.

Our spec can help implementations do the right thing here by limiting the
max frame size to 12 bits.

It takes 500msec to serialize 64KB at 1Mbit/sec... 125msec at 4Mbit/sec.
Those are some pretty notable task-switch times. Dropping the frame to 4096
cuts them to 32msec and 8 msec.. that's much more responsive, at the cost
of 120 extra bytes of transfer (< 1msec at 1Mbit/sec).

In general - the smaller the better as long as the overhead doesn't get to
be too large. At 8 in 4096 (~.2%) I think that's acceptable. Its roughly
the same overhead as a VLAN tag.

Obviously this makes a continuation bit for control frames absolutely
mandatory, but I think we're already in that spot with 16 bit frame lengths.

-Patrick