[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

750.0. "IP Fragmentation on the DECbridge 620" by CTOAVX::BEAULIEU () Fri Oct 16 1992 12:14

    
        Hi,
    
    	My customer has replaced all his AT&T/NCR bridges with DECbridge
    	620's and because the AT&T bridges do not handle IP fragmentation that
    	well, the Sun servers were throttling the packet size at the server,
    	before sending it out on the net. Now they want to set the MTU at 
    	it's max and they are wondering will they see any degradation on the 
    	DECbridge 620's? The have a smaller ring and have tested the max 
    	packet size on that ring and the bridges have worked like a champ. 
    	They are just a little concerned before they do this 
    	globally (60+ SUN servers).
    
    	Is there need for concern? Anybody got a good description on how the
    	DECbridge 620 does IP Frag?
    
    	Thanks, Mike Beaulieu

T.R Title User Personal
Name Date Lines

750.1 LEVERS::ANIL Anil Rijsinghani Fri Oct 16 1992 16:28 23

T.R	Title	User	Personal Name	Date	Lines
750.1		LEVERS::ANIL	Anil Rijsinghani	`Fri Oct 16 1992 16:28`	23
	We spent a great deal of time ensuring that fragmentation of FDDI packets and their forwarding occurs as fast as the forwarding engine can handle it. (I should know, I implemented it :-) In fact, I remember when we did interoperability testing with some of the first FDDI adaptors (at Apollo I think) when they used an application to transfer large chunks of data between an FDDI and Ethernet with tftp and ping: there was a very noticeable difference in speed when the full FDDI packet size was used as opposed to the full Ethernet size. As far as how we do it: there are various fields in the IP header that are used to fragment packets. We have a separate 68020 which handles the FDDI to Ethernet path. (The actual forwarding lookup and transmission are handled elsewhere.) Thus in addition to performing the translation, all this processor needs to do is parse the header and create smaller packets. Consider the partitioning of the work, the fact that work done on a large FDDI packet is distributed across multiple resulting Ethernet-size packets, and the fact that it is easier to saturate an Ethernet with large rather than small size packets, and you'll see why the bridge's performance in this area is good. Anil

    We spent a great deal of time ensuring that fragmentation of FDDI
    packets and their forwarding occurs as fast as the forwarding
    engine can handle it.  (I should know, I implemented it :-)
    In fact, I remember when we did interoperability testing with
    some of the first FDDI adaptors (at Apollo I think) when they
    used an application to transfer large chunks of data between
    an FDDI and Ethernet with tftp and ping: there was a very
    noticeable difference in speed when the full FDDI packet size
    was used as opposed to the full Ethernet size.
    
    As far as how we do it: there are various fields in the IP header
    that are used to fragment packets.  We have a separate 68020 which
    handles the FDDI to Ethernet path.  (The actual forwarding lookup
    and transmission are handled elsewhere.)  Thus in addition to
    performing the translation, all this processor needs to do
    is parse the header and create smaller packets.  Consider the
    partitioning of the work, the fact that work done on a large
    FDDI packet is distributed across multiple resulting Ethernet-size
    packets, and the fact that it is easier to saturate an Ethernet
    with large rather than small size packets, and you'll see why
    the bridge's performance in this area is good.
    
    Anil