Conference 7.286::fddi

1992.0. "DECbridge620 and RFC1191 conformity" by 42033::F_MCANDREW () Thu Mar 21 1996 17:05

                                                        
                                                        Decbridge 620
                                                            --
                                                      _    |  |
                Token                                 |    |  |      fddi ring
   PC            Ring                                 |    |  |        /\
  -----           /\                                  |    |  |       /  \
 |     |         /  \     Cisco               Cisco   |----|  |----- /    \
  -----         /    \      --                  --    |     --      /      \
    |          /      \    |  |                |  |   |            /        \
 --------     /        \   |  |   kilostream   |  |   |           /          \
|        |---/          \--|  |-------- link   |  |   |          /            \
 --------    \          /  |  |       /--------|  |---|          \            /
 Novel        \        /   |  |                |  |   |           \          /
 TCP/IP        \      /     --                 |  |   |        --- \        /
 Stack          \    /                          --    |       |     \      /
                 \  /                                 |       |      \    /
                  \/                                  -     ------    \  /
                                                  Enet     | UKA  |    \/
                                                Segment    | Vaxes|       
 DARTFORD                                                   ------  STEVENAGE
                                                           


                  000--------------------------------000
                                                         
                 
I received the following problem report from Glaxo today. The report claims 
a DECbridge 620 does not conform to a RFC spec. Is this correct?

Rgds,

Frank.

                 000----------------------------------000

Created: 18-Mar-1996 02:31pm

    The Problem

    The reason for the poor ALL-IN-1 performance seen by users at
    Dartford has been identified.  It is the result of a complex
    interaction and is *not* any of the following:

        - Bugs in the Novell LAN Workplace IP stack
        - A general WAN performance, capacity or congestion problem
        - A capacity or performance problem with UKA

    Four components are combining to exhibit this problem:

        * Unusual but legitimate behaviour of Novell LAN Workplace
        * The presence of Ethernet between between UKA and Dartford
        * The IP stack on UKA attempting legitimate link optimisation
        * A DECbridge 500 that does not fully implement RFC1191

    The Decbridge 500 could be looked on as being the main cause of the
    problem.  However this device is a bridge and not a router.  Its
    RFC1191 implementaion is only a partial one, under most circumstances
    this is sufficient.

    The IP stack on UKA, TGV Multinet, attempts to optimise link
    performance by determining the maximum size IP packet that can be
    sent to a destination without fragmentation.  This is know as "MTU
    (Maximum Transfer Unit) path discovery".

    Being connected to a 16Mbps Token Ring, the Novell LAN Workplace IP
    stack can accept very large frames and offers to do so when
    connecting to UKA.  Critically, it offers to accept larger frames
    than Ethernet can handle.  Other IP stacks in use on the Dartford
    Token Ring only offer to accept frame sizes within Ethernet limits so
    do not trigger the problem.

    UKA takes Novell LAN Workplace up on it's offer and, when it has
    large amounts of data to send in one go (page up or page down while
    in an ALL-IN-1 folder is an example) sends packets within FDDI
    specifications but outside of Ethernet.  As part of MTU path
    discovery, the "don't fragment" bit is set.  The DECbridge 500 has to
    fragment the packet to pass it to Ethernet but has been forbidden to
    do so.  To fully conform to the specification, the DECbridge 500
    should inform UKA of this and state the frame size it can accept.  It
    does *not* do this.  Multinet re-transmits the frame, with "don't
    fragment" set several times before giving up on it's previously known
    route to Dartford.  Multinet then starts from scratch to find a route
    to Dartford and, in doing so, retransmits the frame without setting
    "don't fragment".  This time, the DECbridge 500 can fragment the
    frame and it gets to the client correctly.  This whole process takes
    just under 16 seconds.  Because Multinet has reset all it's opinions
    of the link, next time a large frame is generated, the whole process
    starts over again.


    The Solution

    Work already planned for the coming weekend will switch IP
    connectivity between Stevenage and Dartford from the current link to
    a Switched Multi-bit Data Services (SMDS) connection.  SMDS will not,
    of itself cure the problem.  However, the associated work will remove
    both the DECbridge 500 and the Stevenage Ethernet segment from the
    path between UKA and the Dartford PCs.  With these elements removed,
    the problem identified above cannot occur.

    Fallback Positions

    In the unlikely event that the above work has to be called off or
    rolled back, the connectivity at Stevenage can be altered, by
    installation of a new router, to remove the DECbridge 500 and
    Ethernet segment from the path between UKA and Dartford.

    As a third option, Multinet can be configured not to perform MTU Path
    Discovery.  This would also remove a critical part of the scenario
    but may have some small performance effects elsewhere.  These would
    have to be considered before taking such a step.

    This question has been covered elsewhere in the notesfile.
    I found it using the keyword 'fragmentation'
    
    (and I'm the first one to tut when some-one else fails to check
     first!!)
    
    Frank.

Elsewhere it is stated that the problem doesn't exist with the DECswitch 900
and the DECbridge is end of life and not likely to be upgraded.

What it doesn't say that I can see is that the DECbridge is fully conformant
and it is the software used by the customer that is at fault.

RFC1191 is optional, so it doesn't have to be implemented.

So that means that only RFC 792 applies.  The relevant part of RFC 792 says:

[re: sending an ICMP message back to the host]

      Another case is when a datagram must be fragmented to be forwarded
      by a gateway yet the Don't Fragment flag is on.  In this case the
      gateway must discard the datagram and may return a destination
      unreachable message.

Note the words "must discard" and "may return".  The DECbridge MUST discard
but MAY return an ICMP message, but it doesn't have to, so it doesn't.

Note that RFC1191 was written after the DECbridge was designed and shipped.
I don't believe that the hardware design would actually allow sending back
any ICMP message, much less the one specified by RFC1191.