Re: [HSSG] Jumbo Thursday
Joel-
After all the noise, we may be in agreement here.
Specifically, your comment:
I'm
not so much interested in specifying jumbo frames as I am in an objective
or motion that allows for an interface implementation that does not
preclude the use of jumbo frames. No plot, no hidden agenda ... I
just wanted those of us that have to deploy frame extension a mechanism
to do so.
It is just that it seemed to me that we seemed to be going off the deep
end as to whether or not to include Jumbo Frames, per se, in the
project.
I can certainly support an objective that says something like:
- PHYs and physical layer specifications shall not be done in any way
that precludes transmission of frames up to XX Kbytes in length.
It is clear that some noticeable portion of the bulk transport
market wants to implement that with Jumbo Frames over private networks.
To cut those folks out would be dumb in terms of broad market
potential.
Hopefully we can all agree on the above two paragraphs without having to
much further.
Best regards,
Geoff
At 10:45 AM 8/11/2006 , Joel Goergen wrote:
Wow,
I guess it really doesn't pay to take a day off! Yesterday should
go down as 'Jumbo Thursday'.
Rather then respond to individuals, thought I would sum it all up and hit
each item.
1. Latency
2. Betrayal and inappropriate use of the process
3. Kevin, Brad, Geoff, Shimon, and maybe Howard say 'no' to jumbos in
HSSG
4. Research Community asks for clarification of the question ... to jumbo
or not to jumbo ...
1. Latency : Do Jumbos add latency in a store and forward
implementation?
To some degree, I agree with Pat on this issue. In a small scale
system or merchant silicon application, latency is a problem with jumbo
frames and does increase with usage.
In a high density core or edge implementation with specific memory
techniques deployed in a network application engineered for jumbo frames,
no .... any latency added is negligible. Check out available
statistics for high end core implementations.
2. Betrayal and inappropriate use of the process
WOW ... not sure where that came from. I thought this was a forum
for discussion around HSSG. Are we going to accuse everyone of
this? If we are, it sure is going to make things difficult.
3. Kevin, Brad, Geoff, Shimon, and maybe Howard say 'no' to jumbos in
HSSG
Good for you all! It so happens that I agree with you in
principle.
I didn't ask the question to be the one that brings it up every few
years. I asked the question for very relevant reasons ... the least
of which is every customer technical discovery I am involved in, the RFQ
always contains "Jumbo Support ... check YES or NO".
I also worry about compatibility .. I don't want to see anyone have to
redesign systems or silicon because of what I perceive a documentation
procedure.
4. Research Community asks for clarification of the question ... to jumbo
or not to jumbo ...
My original question:
My question is
not whether 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.
Menachem, Michael,
and Marcus ... thanks for giving me the benefit of the doubt and asking
to expand on my point of view. As a research scientist, I greatly
appreciate it!
In 10Gbps and higher speeds, there are many of us that need to support
jumbo frames for various customer engineered applications. In some
ways, it's like MPLS in that most don't need it but still want it or want
to use it in some application specific area in their network.
Shimon eluded to this in his comments.
If I look at the data pipe from the input of the PMD to the input of the
NPU for 10Gbps implementations, there are four basic interfaces used:
XAUI, XFI, XGMII, and SFI. The last three interfaces have no
physical implications or limitations to jumbo frames. XAUI (no
disrespect intended as it is a great interface and I fully support it ),
because of the alignment concept, may drop a frame after the fifth
extended frame when deployed in an async environment. The XAUI
interface was never intended to support extended frames, but can be used
to do so when careful of the clock distribution. But it doesn't
always work in all extended frame implementations..
My question comes about because there are many people within HSSG
considering an architecture composed of multiple Nx10Gbps links in some
phy aggregation concept to give us higher speeds. I'm not naive
here. A serial 100Gbps pipe, end to end, is not likely for a few
years ... just like XFI took a bit of work before it's debut. What
I worry is that 'IF' we deploy a XAUI like concept across this phy
aggregation concept, none of us will be able to supply extended frames to
our customers in the fashion we do so today - out of bounds of the
standard, but easy to do so because three of the four interface available
allow for it.
I'm not so much interested in specifying jumbo frames as I am in an
objective or motion that allows for an interface implementation that does
not preclude the use of jumbo frames. No plot, no hidden agenda ...
I just wanted those of us that have to deploy frame extension a mechanism
to do so.
-joel