|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Please see below:
Is there anything in the current state of the standard that prevent Jumbo frames from being utilized?
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.
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.
Take care and thanks for all the hard work. The stuff you folks design works wonderfully,
Jumbo frames (with the exception of 1522
bytes for vlan tags) are not
If my understanding is correct, the
support of Jumbo Frame is not currently
Many thanks in advance for your help....