Subject: (IPng 6485) Re: Host Fragmentation

From: Richard Draves <[email-masked]>
Date: Wed, 16 Sep 1998 16:34:42 -0700

I hate to inject reality into this entertaining discussion, but I asked
someone who was involved with this test, and in fact the jumbo-frames were
used end-to-end between the client and the server. The switch was not doing
any fragmentation.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 16, 1998 5:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: (IPng 6477) Re: Host Fragmentation
> 
> 
> In a message dated 9/15/98 3:07:45 PM Eastern Daylight Time,
> [email-masked] writes:
> 
> > [email-masked] writes:
> >  > Not true.  The following paragraph has been left out.
> 
> >  >   The tests were conducted using a single-processor Intel 400-MHz
> >  >   Xeon-based server and four 333-MHz Pentium II clients. 
> An Alteon
> >  >   Gigabit Ethernet server switch connected the servers 
> and clients.
>  
> >  > The Alteon Gigabit Ethernet server switch is a fragmenting
> >  > gigabit/10/100Mbps switch or extruder, but it could
> >  > just as well have been a fragmenting gigabit 10/100Mbps
> >  > router.  The point is that server performance goes
> >  > up if the server does not do the fragmentation but
> >  > instead the fragmentation is off-loaded to an intermediate
> >  > packet switch.
> 
> >  Read the damned datasheet, please.  The Alteon Gb Ethernet switch
> >  supports jumbograms on BOTH the Gb Ethernet ports AND the 
> 100Mb ports.
> >  Without question, that's what this test was using.  That's why they
> >  mentioned the types of cards in the clients.
> >  	http://www.alteon.com/pdf/ace110.pdf?124,174
> 
> So?  The device apparently uses the same ASIC on every port, and I
> suppose if the Alteon Gigabit adapter is used in 100Mbps fallback mode
> on a 10/100 Mbps port, it makes sense to transceive jumbograms on the
> 100Mbps medium.  But such is not the situation here.
> 
> The article only mentions the use of a single Gbps jumbogram capable
> adapter card only in the server.
> 
>   Microsoft officials said they achieved 920Mbps throughput 
> on a server
>   using the AceNIC 180, a Gigabit Ethernet network interface card from
>   Alteon, which also supplied the proprietary jumbo-frame technology.
> 
> I just checked the 82558/82557 and 21140 manuals.  The common
> 10/100Mbps adapters do not support jumbogram.  While I do not have a
> 21143 manual here, it is unlikely that this part supports jumbograms.
> I have to assume that the tests were run as we run similar tests and
> as described in Alteon white papers: the clients were using some
> common 100 Mbps adapter cards, which do not support
> jumbograms. Otherwise one would think that that the article would have
> stated something like the following.
> 
>   Microsoft officials said they achieved 920Mbps throughput 
> on a server
>   using the AceNIC 180, a Gigabit Ethernet network interface card from
>   Alteon, which also supplied the proprietary jumbo-frame technology
>   when that server communicated with four clients all of which used
>   the same AceNIC 180 adapter in jumbo-frame mode.
> 
> In point of fact all throughout the Alteon white papers and
> documentation the standard described configuration is 
> 
> *) a server on one of the gigabit ports,
> 
> *) perhaps another server on the other gigabit port and
> 
> *)10/100 Mbps clients (using standard 10/100 Mbps non-jumbogram
> supporting adapters -- Alteon does not sell a jumbogram capable 10/100
> Mbps adapter card for clients) attached to the 10/100 Mbps ports.
> 
> The performance test that Alteon sees using WindowsNT servers is about
> the performance that we see with Alteon cards in Compaq Alpha Servers
> that run Unix.  Clients with 32bit busses and 100 Mbps ethernet
> adapter cards support a throughput of approximately 240Mbps.  We find
> that 64 bit buss clients with 64 bit adapter cards can support
> approximately 450 Mbps.  When a 64 bit server is used with jumbogram
> technology where the Alteon switch performs the dreaded network
> fragmentation, the server can support a throughput over 900 Mbps,
> essentially doubling the number of clients that can be supported.
> 
> Thus the use of jumbograms at the server with network fragmentation
> doubles the number of clients that the server can support.  The
> designers of IPv6 have for no obvious reason chosen to ban
> configurations that can provide tremendous performance wins.  The much
> touted PMTU procedures would completely thwart the benefits that the
> Alteon technology provides.
>   
> >  That I'm even replying shows how much the tie I'm wearing today has
> >  severely constricted the blood flow above the neck.
> 
> And has apparently affected Carlson's ability to read as well.
> 
> I have to admit that Alteon is perhaps being a little bit obscure with
> regard to their exact procedures with all this discussion in the white
> papers of VLANs, intranets and P802.1q.  But in the face of the
> irrationality of the anti-network fragmentation point of view that we
> see in this forum, I am hardly surprised.
> 
> >  *Plonk*  Must remember to add this thread to the kill file.
> 
> Understandable given the apparent reading disability.
> 
> BTW, I obtained a copy of Mogul's fragmentation paper.  Briefly
> skimming, practically every point refers to technological problems
> that existed 10 years ago and that are essentially irrelevant today.
> If this sort of analysis provides the foundation of IPv6, IPv6 should
> be described as "The Protocol of Tomorrow, Designed to Address the
> Problems of Yesteryear."  I will try to provide a critique of the
> paper later today or tomorrow.
> 
> Joachim Martillo
> <A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A>
> 
> 
>   
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------