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

["Adrien W. de Croy" <[e-mail]>]

my vote would be to leave it at 16 bits, and actually allow for some 
mechanism to raise it (we don't know what transports we may be able to 
use in future that make 64kB seem too small).

HOL blocking of frames is only one issue.  If a server has to support 
multiple streams it can scale back the frames it sends to achieve better 
responsiveness.  It has that choice.

But there are plenty of single stream bulk transfers out there that 
would not thank you for limiting frame size to say 4kb and increasing 
their workload.

It's not just filling the wire and wire-efficiency and wire overhead.  
Each frame takes a certain amount of processing overhead.  You quadruple 
the number of frames to send 64kB and you quadruple if not more the 
amount of CPU resource taken to process the frames.

So IMO it makes no sense to chisel into stone 12bits in the protocol.


------ Original Message ------
From: "David Morris" <[e-mail]>
To: "'HTTP Working Group'" <[e-mail]>
Sent: 29/05/2013 9:14:40 a.m.
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>
>
>On Tue, 28 May 2013, Patrick McManus wrote:
>
>>  On Tue, May 28, 2013 at 4:12 PM, Roberto Peon <[e-mail]> 
>>wrote:
>>
>>  My sweet-spot number was 16k, as I knew that I could saturate a 10G 
>>nic
>>  > with 16k frames/writes and have enough CPU left over to do some 
>>actual
>>  > work. The amount of overhead goes up more than linearly with the 
>>decrease
>>  > in frame size thanks to contention, etc.
>>  >
>>  >
>>
>>  Given what you've said here and in the other mail (plus of course my 
>>own
>>  previously stated concerns) I'm inclined to suggest a 16KB max (14 
>>bits)
>>  without introducing any kind of max frame size configurable. My point 
>>is to
>>  drive it as small as we can without creating excessive overhead and 
>>you've
>>  put a stake in the ground that 16KB is that level. That's still 4x as
>>  aggressive as the current draft.
>
>I've been working with a product for a number of years which 
>incorporates
>muxed http response streams where 16k chunks per streams seem to work
>well. Our design concern was to keep low speed connections full while
>minimizing HOL blocking. Unfortunately, there is no easy way to test
>alternatives.
>