Re: Large Frame Proposal

In message <CANV5PPX+3CYiE7JEoc0p9XRWNTBQiVS9mEUKenDc2VkLmnahWQ@mail.gmail.com>
, Nicholas Hurley writes:

>Anyone who cares to see my reasoning against
>jumbo/large/huge/whatever frames is welcome to go back and read the
>archives.

Please notice that this suggested change does not *mandate* use of
large frames, you are perfectly able and in your right to never
transmit or receive a single one of them.

All of the stuff I have found in the archives seems to be totally
blind to network technological developments such as fiber-to-the-home
and 4G, 5G and the recently started murmor about 6G mobile networks.

Limiting the protocol to 16K means it will be outdated almost before
it is ready to be used.

Our proposal is basically to future proof the protocol while retaining
as defaults the number based on the archives.

>This is a HUGE change to the spec in order to make people feel better about
>cases that make up 0.02% of the streams out there. Why are we continuing to
>spend time and energy on this?

Because the currently proposed solution for these 0.02% sucks ?

(NB: This "0.02%" number only covers HEADERS, our proposal also
allows large frames for DATA, which is a significantly larger market
than 0.02% of the traffic)

>If the WG decides to go this route (which I think would be ill-advised),
>there NEEDS to be a minimum on max frame size.

There is: 256 bytes, it's in the draft.  This number was chosen as the
smallest realistic number for highly tailored applications.

-- 
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 Monday, 7 July 2014 19:56:31 UTC