ENSS FDDI MTU

Fri Feb 12 03:47:06 UTC 1993

> From Vince Fuller:
> 
> At what point in the future are you planning to raise the FDDI MTU on
> the ENSS from 4000 bytes to the default value of 4470 bytes? It has
> recently come to my attention that we, and any other regional which
> uses a cisco router on FDDI to peer with an ENSS, may be taking an
> enormous performance hit by using the non-standard MTU - it seems that
> the FDDI fast-switching path on a cisco router is automatically
> disabled if the interface is configured with other than the default
> MTU. This may explain some of the problems we have been having
> recently with high CPU utilization levels on our routers which peer
> with the NSFNET over FDDI.

From: Vimal Solanki, Curtis Villamizar, Jordan Becker 

Draft Standard RFC-1188 states that "the MTU of FDDI networks shall be
4352 octets".  At present, the IBM routers temporarily violate this
as explained below.

Currently we have 4000 byte MTU paths among all FDDI ENSSs.  This is
due to the fact that buffers are allocated in the current software
such that the RS/960 T3 card can not support larger than a 4000 bytes
MTU.  Packets received larger than 4000 bytes are fragmented on the
FDDI card (with the first fragment being 4000 bytes).  This will be
fixed when AIX 3.2 is deployed (scheduled for March).  The MTU will
will then increase to 4352 bytes on both the T3 and FDDI cards.  We
will still be able to *receive* packets up to 4470 bytes in size, and
fragment them (with first fragment being 4352 bytes).  However we will
not *send* packets of size larger than 4352 bytes.

> Can someone estimate for me the impact on an ENSS of fragmenting >4000
> byte packets? Given the relative scarcity of full-FDDI-MTU paths
> through the Internet, the likelihood that packets larger than 4000
> bytes will need to be fragmented by an ENSS seems very low to me, so
> unless an ENSS does something extremely stupid (such as drop packets)
> when faced with such a fragmentation decision, my guess would be that
> we will want to optimize the common case and run with default MTUs on
> our FDDI cisco routers. In fact, as a Friday-night experiment, I have
> reset the MTUs on all of our FDDI cisco routers with no apparent ill
> effect. Is this likely to cause problems for the NSFNET?

The FDDI card will handle the maximum possible fragmentation at the
maximum possible bandwidth without any performance problems.  In other
words, if every single packet needs to be fragmented, the FDDI card
can still handle it without dropping any packets for 22.5 Mbps
full-duplex data stream between itself and the T3 card.  This was
tested with an ENSS router equipped with FDDI and the 22.5 Mbps
HSSI/T3 card.  While we did not run this specific test in the presence
of T/960 Ethernet, T1 cards, or the new full T3 cards, the performance
should still be good.

Looking at ENSS128, there are no requests for buffers denied.  There
have been no errors at all in card-to-card, or card-to-system
transfers which is where one would expect to see a problem due to
fragmentation.

> Please advise.

We suggest that you set your MTUs to 4470 since this will ensure
autonomous switching on your Cisco.  When we go to AIX 3.2 we will use
4352 bytes MTU.  This will still ensure almost zero fragmentation
since almost all traffic will be sinked/sourced from end hosts.

			---------------------

RFC 1188              IP and ARP on FDDI Networks           October 1990

MAC Layer Details

   Packet Size

      The FDDI MAC specification [4] defines a maximum frame size of
      9000 symbols (4500 octets) for all frame fields, including four
      symbols (two octets) of preamble.  This leaves roughly 4470 octets
      for data after the LLC/SNAP header is taken into account.

      However, in order to allow future extensions to the MAC header and
      frame status fields, it is desirable to reserve additional space
      for MAC overhead.

      Therefore, the MTU of FDDI networks shall be 4352 octets.  This
      provides for 4096 octets of data and 256 octets of headers at the
      network layer and above.  Implementations must not send packets
      larger than the MTU.

      Gateway implementations must be prepared to accept packets as
      large as the MTU and fragment them when necessary.  Gateway
      implementations should be able to accept packets as large as can
      be carried within a maximum size FDDI frame and fragment them.