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

responses inline


On Tue, May 28, 2013 at 5:22 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
>
> ------ 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 was easy. We didn't think about too much and had decided that 24 bits
was fairly large. :) We knew that we needed some flags, and decided that
doing that byte aligned was the easy thing. Thus, 32 bits of length became
8 bits of flags and 24 bits of length.
Later we discovered the problems with implementations in the wild abusing
the maximum frame size and screwing up the multiplexing (by using too-large
frames which preclude good muxing).


>
> 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.
>

Then they (implementors who primarily care about simplicity and sacrifice
latency to it) should stick with HTTP/1. No joke. If you're not doing
multiplexing and prioritization right, you may be better off from a latency
perspective using HTTP/1 and sticking to the heuristics.
If, because of implementors who've done a poor job, browsers must
heuristically delay as they do today, then the entire ecosystem suffers
negative latency implications.


>
>
>   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.
>

I believe the intent was to say that this is the first version, and one of
the things we're doing is making it substantially easier to rev the
protocol. ALPN is the think which makes that easy, and which will thus make
this potentially easy.


>
> 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.
>

Agreed. I can read and fill a 10G nic at line at 16k frame size with plenty
of CPU left over for other things, so I'm not worried about them.  :)


> 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.
>

I already know what happens with that frame size-- we get page loads which
can actually be slower than that of HTTP/1.


>
>  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?
>>
>>
>>>
>>
>>
>