Re: Framing and control-frame continuations

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

Received on Wednesday, 6 February 2013 12:46:55 UTC