Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] Jumbo frames

Kevin-

Thanks for your contribution.

A decision to support an project that mandates support of jumbo frames would, in my opinion, take the study group into a quagmire. This would be an effort towards a goal that was not even mentioned in the Call For Interest nor mentioned in the discussion leading up to the vote on forming the Study Group.

To go here would, I believe, be a betrayal of the trust laid on the group by 802.3.

Having said that, I do not believe that there is any reason why:
        - Folks shouldn't build HSSG hardware in a manner that supports Jumbo Frames
        - Folks shouldn't (again) bring the topic up in 802.3
They just should not try to glue that requirement to this project rather than use the appropriate process in 802.3.

There isn't anything inherently "wrong" with jumbo frames and there isn't any reason why links and MACs shouldn't be able to transmit and receive them. The issue comes when you try to integrate them into the existing world. If you have a world of streets and railroad crossings (sorry, I grew up in a railroad town) lots of folks will scream bloody murder when you go from 50 car trains to 250 car trains. It is the integration with other traffic at switch points that is the the problem.

If folks want to build homogenous jumbo frame networks, more power to them. We have never quite figured how to put that in the standard without it seeming like we were trying to integrate them with legacy networks.

Bottom line. This is an entirely different discussion from what we are supposed to be doing which is higher speed.

I would request that those who want to jumbo frames set up their own discussion forum on a different distribution list.

Geoff Thompson

At 02:16 PM 8/10/2006 , Kevin Daines wrote:
All,
 
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 beyond.
 
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
 
Kevin Daines
Chair, P802.3as TF
 
 
 
Note from archive attached below:
Title:
All,

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 frames.

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.

-joel