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

------ Original Message ------
From: "Patrick McManus" <mcmanus@ducksong.com>
Subject: Re: Proposal - Reduce HTTP2 frame length from 16 to 12 bits
>
>On Tue, May 28, 2013 at 7:19 PM, Adrien W. de Croy <adrien@qbik.com> 
>wrote:
>>
>>
>>take a look at any protocol where after a while people decided that 
>>the size limits were too small.  I can think of several off the top of 
>>my head: DNS, DHCP and BGP
>>
>I don't think those are good comparisons here because those protocols 
>have maximum atomic message sizes of one sort or another, while here we 
>are discussing the size of the atom in a format that already takes 
>multiple atoms - not the size of the message.

understood.  I'm just talking about framing overhead in terms of burden 
on CPU and stack.

Why do we think there are jumbo frames in ethernet?  Because 1514 turned 
out to be too small in some cases.  How widespread are jumbo frames?  
How hard is it to deploy something that relies on them?
>I think you make a better argument for getting rid of FRAME_TOO_LARGE.
FRAME_TOO_LARGE is required if the field width allows a size bigger than 
you are willing to accept.  So I think it needs to stay.

>There aren't any streams that can be expressed with 24 bit frame sizes 
>that can't be with 16, 14, or 12. Its just a matter of various forms of 
>overhead and responsiveness.
exactly. And what is the priority problem to solve.

My point is if we focus too much on HOL blocking of frames, in the 
context of

* today's link technologies
* today's transport layer protocols
* today's requirements (resource sizes etc)

and use that to set a size limit on a frame by way of field width of the 
frame size field, then we will probably create problems down the track 
which we could actually avoid now.

My expectation is that

* resource sizes will increase over time
* links will get faster
* buffers will get bigger (yes buffer bloat is an issue) and transports 
will eventually evolve with larger windows


I would be interested in the discussion that led to SPDY being 24 bits.

It's one thing to choose how big a frame to send, it's another to limit 
it in protocol.  I can choose to send a 4kB frame if the frame size 
field is 12, 16, or 32 bits.  If you reduce the width though you take 
away choice.  You're talking about reducing it because you don't like 
the choices some people made implementing SPDY.  If you're to take away 
peoples' choice, you better make the right one for them.

the spec could allow for bigger frames (as opposed to messages) in the 
case where that makes sense, but with caveats about use of sizes.

If google servers NACKed frames over 4kB, people would stop sending 
them.  But the agents should maybe know how to and be capable of 
processing larger frames.

>
>I brought this to the working group because I believe in running code 
>and the experience I have gotten here so far tells me most 
>implementations so far haven't gotten this right. (I've seen at least 3 
>different one so far that will write the whole document in 1 frame if 
>they can fit it in spdy's 24 bits - even though that's just as bad as 
>http/1 pipelines)
bad or good is from a point of view.  The implementors probably thought 
it was good.  Simplicity can be good.

>and a good spec can generate good implementations. Implementation 
>advice is fine, but its better if it just does the right thing.. and in 
>this case imo a responsive protocol requires smallish frames.
I understand and agree that in the cases you're talking about, smallish 
frames are good.  But there are other cases which we sacrifice for this 
one goal that we decide is the most important.  On what basis do we 
decide this is the most important problem?

ALPN and Negotiate are not an answer to this.

What about something like a default max size, so unless something is 
advertised, the max is whatever (I'd suggest at least still 16 or 32k, 
and the IIS guys might still want 64k).  A FRAME_TOO_BIG response if you 
really don't want to receive anything bigger, but the field size is 16 
and extensible.  So that at any stage implementations have the choice to 
go bigger if their application requires it.

There are many applications other than just serving.

For instance something that aggregates messages/frames across some other 
network might like to coalesce frames from the same message into larger 
ones.  You set the size to 12 or even 16 bits and you limit these 
options as well.  So actually I'd be keen to see 24bits.  Costs 1 more 
byte, but don't expect to be able to send more than some default value 
(e.g. 16kB) without it getting bounced, unless you know you can.

  Adrien
>
>
>
>>Trying to get widespread deployment of an extension to cope with that 
>>is an awful mess, and something we shouldn't saddle ourselves with up 
>>front.
>>
>>There are still many DNS implementations that don't understand the 
>>size extensions.  Look at the contortions DHCP took to try to reclaim 
>>space.
>>
>>As for 64kB.  Last time I counted TCP stream bytes between PSH flags 
>>on an HTTP stream from IIS, it was 64kB.  I really don't think we 
>>should reduce it.  Servers suffering from HOL issues can always reduce 
>>frame size themselves for outbound.  As for inbound, if there is a 
>>settings pre-negotiation (which is proposed), why not advertise max 
>>frame you will accept?
>>
>>>
>>
>>
>