| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Corey: Please see
below: -----Original
Message----- Mike, 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. 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 -----Original Message----- Tricci: Jumbo frames (with the exception of 1522
bytes for vlan tags) are not Regards, Mike Mike Bennett
-----Original Message----- Hi all, If my understanding is correct, the
support of Jumbo Frame is not currently Many thanks in advance for your help.... |