Re: Jumbo Frames in 10GbE?

["Simon L. Sabato" <simons@xxxxxxxxxx>]

"W. R. Wing" wrote:
> 
> At 1:24 PM -0700 6/21/99, Bruce_Tolley@xxxxxxxx wrote:
> >Let us not be too hasty about concluding that the market "obviously"
> >is going to
> >jumbo frames.
> >
> >Only one switch vendor has actively promoted jumbo frames to date.  An
> >examination of market share numbers from such firms as Dell'Oro
> >Group shows that
> >there is no evidence that the end user market is going to jumbo frames.
> >
> >Bruce Tolley
> >3Com
> >408-326-5950
> >bruce_tolley@xxxxxxxx
> 
>    As a long time lurker on this list, I finally feel compelled to speak
>    out.  I'm a USER of the equipment.  I see the advantages of jumbo frames
>    from view point of the end equipment, but I see the disadvantages (both
>    from the inter-operability point of view and burstiness point of view)
>    of jumbos out in the network.  It seems to me the real answer is to fix
>    the problem of the end equipment *at* the end equipment.  Surely it
>    would be possible these days to build a smart NIC, possibly one that was
>    IP aware.  Give it LOTS of on-board hardware buffering, and let the
>    OS hand it a buffer full.  It would perform the Ethernet equivalent
>    of an ATM SAR operation, slice the buffer up into standard Ethernet
>    frames, put headers on them, and ship them out.  The network would
>    get all the benefits of standard frames, the end equipment would get
>    the benefits of big buffers and low interrupt rates.
> 
>    Let me repeat.  As a user, I value backwards compatibility.  I see
>    no point in asking the network to solve an end equipment problem.
> 
>                         Thanks for letting me vent,
>                         Bill
> 
> William R. Wing    wrw@xxxxxxxx   (423) 574-8839
> Network Architect for the Oak Ridge National Lab


I have also been listening to this and have succumbed to the urge to
reply.  As a DESIGNER of the equipment (switches now, NICs in the past)
I also think that increasing the maximum frame size is not the thing to
do.  It doesn't help the load on intermediate switches, and can
complicate their design.  It would be easy (and natural, given the
latest initiatives in distributed I/O) to have the NIC perform flow
segmentation and reassembly.  You don't even need larger hardware
buffers, just some more gates, since the NICs pull data out of the
system memory already.  This would provide a larger performance increase
than Jumbo, and it will add differentiation in the NICs, which means it
will arguably happen anyway (much like a desire for differentiation is
prompting *this* discussion).  A smarter NIC would be completely
transparent to the network administrator, it would exist completely
within current standards, and it would work regardless of the media and
speed.  Do we soon want to be left with the cost of supporting large
frames when the reason for having them is obsolete? 

The IEEE shouldn't waste time working with larger frames until it can
answer all the relevant questions (such as how to encapsulate large
frames, how bridges should handle these packets, what new stats will be
required, market desire versus complexity, etc.)  These are not issues
for the HSSG.  If we find that we *could* support larger frames for
little or no extra cost with option A versus option B, fine, we'll
select option A in case Jumbo gains more support.  This reflector should
limit discussions to something closer to: is there a way to cost
effectively ensure that a future Jumbo standard would run over this
media? 

Ethernet has become the success that it has by delivering 1000%
performance steps with practically no added complexity, certainly
nothing like *not enabling transmission* of certain packets on certain
links.  I certainly wouldn't enjoy explaining to a network administrator
why he can't mirror packets from a server to a protocol analyzer. 

I would've asked for an informal show of hands to see the actual
interest level on both sides but I think that we already did it
officially in Idaho. 

-Simon L. Sabato
-Level One Communications