
On Tue, Feb 03, 2004 at 11:02:16AM -0500, Leo Bicknell wrote:
While the rate of request is still very low, I would say we get more and more requests for jumbo frames everyday. The pressing application today is "larger" frames; that is don't think two hosts talking 9000 MTU frames to each other, but rather think IPSec or other tunneling boxes talking 1600 byte packets to each other so they don't have to split 1500 byte Ethernet packets in half. Since most POS is 4470, adding a jumbo frame GigE edge makes this application work much more efficiently, even if it doesn't enable jumbo (9k) frames end to end. The interesting thing here is it means there absolutely is a PMTU issue, a 9K edge with a 4470 core.
9k isn't an absolutely necessity, especially for x86. I believe the original reason for 9k as picked by Alteon was to support the 8192 byte page size on the Alpha. As long as there is enough to squeeze an x86 memory page (4096 bytes of payload) plus some room for headers, the important goal of jumbo frames (which is NOT to lower the packet/sec count, this is only a mild by-product for those who are still doing things wrong) is achieved. This would also eliminate the problems of IPSec, GRE, and other forms of tunneling which may or may not be applied breaking things where PMTUD is blocked, since the "standard" payload packet for TCP would only be 4136 octets (leaving plenty for other "stuff"). The 4470 MTU of POS meets this requirement perfectly, and the world of end to end connectivity would be an infinitely better place if everyone could expect to pass 4470 through the Internet. But alas, there are probably too many people people running GigE in the core which doesn't support jumbo frames let alone a standardized size of jumbo frame, due to various vendor hijinks to truly make use of POS's MTU these days. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)