Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits

Currently, my only challenge with this is that, so far, we have not
seen any documented performance metrics for non-browser based uses.
.That said, I don't really have the time currently to put together a
comprehensive set of such metrics so it wouldn't be polite of me to
insist on them ;-) ... perhaps for now we ought to keep the 16-bit
size but include a recommendation about not exceeding 12-bits, then
see what more implementation experience does for us.

On Tue, May 28, 2013 at 7:20 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> 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
>
>

Received on Tuesday, 28 May 2013 16:23:33 UTC