Re: [HSSG] Jumbo frames
The primary reason for not including jumbo frames in 802.3 is that
they don't do any good in the real world, where higher speed links
are used to aggregate traffic from lower speed links. The situation
where they can help is in benchmark tests performed between
compatible systems, in the absence of TCP offload.
FDDI supported frames up to 4500 bytes. Benchmarks running on
systems connected via FDDI yielded higher throughput and lower
CPU utilization when the tests were run with 4500 byte packets
than with 1500 byte packets.
However, as soon as you tried to deploy a server with an FDDI
interface, you quickly discovered that it had to talk to Ethernet
clients via an L2 bridge or an L3 router. Many such devices were
fielded with a claimed ability to fragment 4500 byte FDDI packets
down to 1500 bytes on Ethernet. Few of them worked very well, so
most of the time, you had to throttle the MTU on the server's FDDI
interface down to 1500 bytes. Away went the performance gain from
using jumbo frames. In fact, I would say that the exact frame format
compatibility between Ethernet and Fast Ethernet (including the frame
size) was one of the key reasons why Fast Ethernet displaced FDDI
so rapidly in enterprise backbones, even though FDDI had a head start
of over 5 years in the market.
When we started the Gigabit Ethernet project, several people told us
that we had to add jumbo frames to the standard. We didn't, and the
industry hasn't suffered from our decision. Indeed, I think we saved
ourselves from a lot of interoperability problems, and we learned
how to build servers, switches, and routers that could drive a
Gigabit Ethernet interface at wire speed using 1500 byte packets.
Today, TOEs are much more commonly used than they were in the 1990s,
and with a TOE, as Pat pointed out, jumbos don't give you much if
any benefit, but they do introduce a host of problems.
Various implementations support jumbo frames, and there is nothing
wrong with this. Occasionally, jumbo frames can be employed to good
effect between compatible systems operating under controlled
conditions. However, this is vastly different from writing jumbo
frames into the world's most popular networking standard, with the
attendant implication that they can be used with impunity.
I think it is a healthy exercise to have this discussion, but I am
not aware of any factor that makes this higher speed activity
different from its predecessors insofar as jumbo frames are concerned.
Therefore, I think that our previous conclusion is still valid:
jumbo frames do not belong in IEEE Std 802.3.
From: Brad Booth [mailto:bbooth@xxxxxxxxxxxxx]
Sent: Thursday, August 10, 2006 3:27 PM
Subject: Re: [HSSG] Jumbo frames
I agree with you about jumbo frames. I am glad that Joel mentioned it
though because it is a good discussion to get out of the way. I had a
couple of other thoughts about the issues with jumbo frames and I'd
appreciate your feedback (as the P802.3as chair) and that of others with
more MAC standards expertise (Shimon, Larry, etc.):
1) 802.3as is expanding the Ethernet frame, but this was done in
conjunction with 802.1. Therefore, I would assume that any jumbo frame
project would require the same effort.
2) The 802.3 MAC specification doesn't "buffer" information; therefore,
a change in the MAC would be required to perform this operation to be
compliant with the 802.3 MAC service interface.
3) Would this have impact on other 802 dots (.11, .17, etc.) if
something was done in conjunction with 802.1?
I know that jumbo frames have been brought up in the past. Most
previous projects have rejected doing it, and in my humble opinion, the
primary reason has been that the change is more complex than just
altering the 802.3 MAC frame size.
From: Kevin Daines [mailto:Kevin.Daines@xxxxxxx]
Sent: Thursday, August 10, 2006 2:16 PM
Subject: [HSSG] Jumbo frames
Joel's statement below can be grossly misinterpreted. He states that all
system and silicon vendor supports jumbo frames. That may be true but I
highly doubt it. However, what is not true is that all or the even the
majority of the installed base of Ethernet gear supports jumbo frames.
In addition, many products on the market today do not support jumbo
frames (by products I mean both equipment and silicon). During the
P802.3as Frame Expansion project (soon to complete), UNH IOL kindly
tested hundreds of pieces of gear and combed through hundreds of reports
to determine the maximum frame size supported by Ethernet gear (that had
been submitted to UNH). While not exhaustive, the data indicated a wide
range of maximums from 1515 (not a typo) through 2K, 4K, 5K, and 9K and
Within P802.3as, we discussed jumbo frames at various times. The
following constitutes my recollection of the reasons against
"standardizing jumbo frames" (not ordered):
1) Interoperability with legacy gear
2) Increasing frame size is a slippery slope. Why 9KB? Why not something
larger, like 16KB or 64KB?
3) The network performance bottlenecks change over time. Each major
component of the network/system goes through improvements and upgrades,
which changes the requirements on other parts of the network/system.
4) QoS (frame delay, frame delay variation, etc.) impacts
Chair, P802.3as TF
Note from archive attached below:
* To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
* Subject: [HSSG] Topics for Consideration: Jumbo Frames
* From: Joel Goergen <joel@xxxxxxxxxxxxxxxxxxx
* Date: Wed, 9 Aug 2006 11:23:42 -0700
<mailto:LISTSERV@xxxxxxxxxxxxxxxxx?body=INFO STDS-802-3-HSSG> >
* List-Owner: <mailto:STDS-802-3-HSSG-request@xxxxxxxxxxxxxxxxx>
* Organization: Force10Networks
* Reply-To: joel@xxxxxxxxxxxxxxxxxxx <mailto:joel@xxxxxxxxxxxxx>
* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
If I go to any search engine and input "jumbo ethernet frames chips", I
will see that every system and silicon vendor supports jumbo ethernet
My question is not wether to support jumbos, because we all already do
... my question is should we finally spec it out? I think we should, at
a minimum, provision for it.