Re: Framing and control-frame continuations

At 64k, the framing overhead is 0.00012, which is pretty close to
negligible.
Arguably, if we're worried about payload efficiency at this size, then we
should be far more worried about compression efficiency, as it will have an
orders-of-magnitude greater effect on efficiency than changing the length
field here.

The idea of a 16 bit field is that it is small enough to require
implementors to get the continuation case correct because it is will occur
infrequently, as opposed to larger values where implementations are likely
to skimp and/or suffer from backup-generator style problems where the
codepath is exercised so rarely that bugs in it are not found and fixed.
Additionally, with a 16bit field a naive implementation is more likely not
to completely screw things up w.r.t. allowing interleaving in response to
new requests or streams.

In any case, if/when we implement and there are real performance
bottlenecks, we can rev the protocol-- indeed, we'll be doing this many
times as we develop HTTP/2, hopefully, as the version negotiation
mechanisms are (imho, at least) a significant work-product.
It is certainly possible that, after some implementation experience with 16
bit frame sizes we all decide that it needs an upward rev, with some
features designed to ameliorate the particular problem at hand

-=R


On Wed, Feb 6, 2013 at 4:46 AM, Roland Zink <roland@zinks.de> wrote:

> The framing overhead can be saved when combining  several frames into one.
> This seems to be 8 Bytes per 64k (full frame). The processing overhead per
> frame can also be saved. Another question is how the lower level get a
> packet with a big payload if all what is delivered is in a frame. Nagle's
> algorithm to fill the MTU can cause delays.
>
> Adding 2 bytes to the frame header for a 32bit length (instead of 16bit)
> does add some overhead for smaller frames but is more flexible. Using a
> maximum frame size of 64k may reduce the memory management cost over
> arbitrary values, but the maximum frame size can be negotiated, couldn't it?
>
> The window size needs to be larger than 64k to fully utilize such links.
>
> Roland
>
>
>
> On 06.02.2013 13:07, Martin Thomson wrote:
>
>> I might just be dense, but I'm not seeing the connection.  I can see
>> how path MTU affects network performance at the lowest layers, but I'm
>> not seeing how that affects application layer protocols.  How is one
>> big frame different from multiple smaller frames at this layer?
>>
>> On 6 February 2013 06:40, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> --------
>>> In message <C6B30EDB-32FB-4093-AD74-**4B596FC4F0D2@mnot.net<C6B30EDB-32FB-4093-AD74-4B596FC4F0D2@mnot.net>>,
>>> Mark Nottingham wri
>>> tes:
>>>
>>>  I don't think this is good enough.
>>>>>
>>>>> You'd need ~20k of these frames a second to fill a 10GB ethernet,
>>>>> and a very large fraction of present day web-objects would require
>>>>> more than one frame already.
>>>>>
>>>> Could you please spell out why you think that's a problem?
>>>>
>>> As I said before:  If we cannot demonstrate HTTP/2 on a 10GE
>>> media and argue plausibly that it can be handled on 1Tbit/sec,
>>> we're writing a standard for the past and not the future.
>>>
>>> Matt Mathis has been pushing similar agenda for IP MTU for years now:
>>>
>>>          http://staff.psc.edu/mathis/**MTU/<http://staff.psc.edu/mathis/MTU/>
>>>
>>> --
>>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>>> FreeBSD committer       | BSD since 4.3-tahoe
>>> Never attribute to malice what can adequately be explained by
>>> incompetence.
>>>
>>>
>
>