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

RE: Question on Jumbo Frame support on 10 GbE



Title: RE: Question on Jumbo Frame support on 10 GbE
Jumbo, runts, giants whatever.  People the world awaits for your deliverable
 
 
God Speed to you all!
 

John A. Nau
Senior Manager,
Information Technology Practice
Xceed Consulting, Inc.
1207 East Carson St.
Pittsburgh, PA 15203

(412) 488-7441, extension 19
johnn@xceedconsulting.com

Set aggressive goals and meet them with aggression......


-----Original Message-----
From: Mike Bennett [mailto:mjbennett@lbl.gov]
Sent: Friday, May 18, 2001 9:23 PM
To: McCormick, Corey; Tricci So; stds-802-3-hssg@ieee.org
Subject: RE: Question on Jumbo Frame support on 10 GbE

Corey:

 

Please see below:

 

-----Original Message-----
From: McCormick, Corey [mailto:Corey@citgo.com]
Sent: Friday, May 18, 2001 4:18 PM
To: Mike Bennett; Tricci So; stds-802-3-hssg@ieee.org
Subject: RE: Question on Jumbo Frame support on 10 GbE

 

Mike,

Is there anything in the current state of the standard that prevent Jumbo frames from being utilized? 


Well, technically yes since we agreed to keep MaxFrameSize at 1518 octets.

I mean no offense Mike so please note that this is not directed personally at you.  There would be no more of an issue with backward compatibility than there was with GigE supporting it following 100Mb...  There will always be issues such as these, when improving on deficiencies in older standards, but that is how we make progress.  

None taken. 

In our environment that has already been tuned with features like TCP Checksum Offloads, Large RFC-1323 scaled TCP windows, etc...  Making no other changes other than 1500 MTU -> 9000 MTU reduces our large data transfer times by ~35% with a similar drop in CPU overhead.

While there are many reasons to support Jumbo, other than a lack of knowledge of or experience with Jumbo, I have not yet been presented with *any* (IMHJ of course ;-) ) sound reason not to add it.  Deciding "since it is not there already it should not be supported", is only a self-fulfilling prophecy.  Jumbo is a great thing when used correctly (like most tools) and causes us no trouble at all.  TCP MTU discovery takes care of much of what we need, and we can work around other issues just fine.

The question is why would we need to standardize jumbo frames?  The reason would be so we can reasonably assured that if vendors comply with the spec, there would be no interoperability problem when using jumbo frames.  In your environment, do you run jumbo frames between different vendor’s equipment?  While I haven’t personally done interoperability testing for that feature I would be very surprised if there is an interoperability issue there now.  The next question is in which standard do we include them?  802.3ae (too late now I believe)? Previous versions (not even sure how we do that, perhaps a maintenance revision)?  Now, I agree that none of these questions raise a sound technical reason not to do it, but there are logistical reasons why it may not be worth the effort to do it.  One technical point, albeit a minor one these days, is that bridging between a segment that is not jumbo-frame enabled and one that is puts additional burden on the bridging/switching device to fragment the frames at a 6:1 ratio in the case of a 9K framesize.  Nonetheless, if there really is a strong feeling that jumbo frames should be standardized, then someone should do a Call For Interest to have a jumbo frames study group to see if there is enough interest to standardize the frames for all of Ethernet.   

I am not in any way implying or suggesting that it is or is not this committee's responsibility and/or scope to add it to the standard, just that it would serve the industry as a whole to not preclude the future use of Jumbo frames with on-going or future standards efforts.

As far as I know, every time there is a new Ethernet standards activity the issue is raised and so far has not made its way into the standard.  I’m sure it will continue to be raised, but I don’t believe it will get support unless it is proposed to be done for all Ethernet standards.    It’s a pleasure to discuss this, but I’m going to let it die on the reflector, as it doesn’t pertain to the completion of the 802.3ae standard.

 

Best Regards,

 

Mike

 

 

 

 

 

Take care and thanks for all the hard work.  The stuff you folks design works wonderfully,

 

Sincerely,

Corey 

 

Corey McCormick
CITGO Petroleum Corp.

 

 -----Original Message-----
From:   Mike Bennett [mailto:mjbennett@lbl.gov]
Sent:   Friday, May 18, 2001 5:07 PM
To:     Tricci So; stds-802-3-hssg@ieee.org
Subject:        RE: Question on Jumbo Frame support on 10 GbE

 

Tricci:

Jumbo frames (with the exception of 1522 bytes for vlan tags) are not
specified in any 802.3 standard.  There would have been a serious problem
with backward compatibility with other than 10 GbE equipment if we had
included support in 802.3ae.  Since jumbo frames would have to have been
standardized throughout 802.3 it was declared outside the scope of 802.3ae.

Regards,

Mike

 

Mike Bennett
Lawrence Berkeley National Lab



-----Original Message-----
From: owner-stds-802-3-hssg@majordomo.ieee.org
[mailto:owner-stds-802-3-hssg@majordomo.ieee.org]On Behalf Of Tricci So
Sent: Friday, May 18, 2001 11:40 AM
To: stds-802-3-hssg@ieee.org
Subject: Question on Jumbo Frame support on 10 GbE

 

Hi all,

If my understanding is correct, the support of Jumbo Frame is not currently
within the scope of 10GbE.  May I ask what is the rationale behind this
intent?

Many thanks in advance for your help....
Tricci
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.