Conference 7.286::fddi

    Our bridges?switches I believe currently only handle IP fragmentation.
    On the statement in Pauls document. What it actually says is as
    follows..
    
    "Translate the packet  to Ethernet format. It it is too long, check 
    whether it's a protocol for which fragmentation is supported. If so,
    fragment it; otherwise discard the packet and count it as oversized."
    
    In addition, I also understand that some end nodes will establish 
    communications with each other and essentually keep sending larger
    and larger packets at each other until they can't communicate
    anymore, thus they determine the largest packet size they can use
    to talk to each other before communications are lost due to their
    packets being discarded.
    
    Bob

    
    Bob,
    
    		thanks for your reply. Yes, I should say 'switch' to be
    fashionable!
    I located a copy of the Decbridge500 technical guide which
    details the code operation and backs up Paul's document in that
    oversize frames are junked.
    I guess that the idea was detailed in the Vaxcluster article more as 
    a proposal which may have appeared in a draft IEEE 802.1 document
    but was subsequently dropped? Obviously, if it did make it into
    the standard, we would have implemented it ;-)
    It's a shame since it seems a pretty neat idea.
    
    John.
    
    < incidentally, I'm waiting for someone to invent the terms
      Britch and Swidge to give customers a warm feeling about Bridge 
      - Switch interoperability !> 
    

VMScluster protocol NISCS uses the algorithm described to detect intervening
Ethernet LANs so that it limits the packet size appropriately.  The algorithm
is simple and available to any protocol that chooses to implement it.  Set
the priority field in FC to non-zero and then check incoming packets for each
peer.  If the priority is zero in the inbound FC then the packet came via
some other path than pure FDDI.

Note that this is just one protocol feature that NISCS has that is not supported
in any other popular protocol.

In part, the problem is that there are so many implementations that adding
useful optimizations to all the implementations is difficult, and the problems
can be avoided by requiring those bleeding edge users to configure things to
avoid the problem.

But another reason is that the underlying belief systems prevent considering
other options.  For example, NISCS aggressively supports multiple adapters
and communication paths for increased availability and performance.  The IP
belief system holds that this is impossible and unneeded since ATM or something
will provide unlimited scaling using a single interface.

Perhaps more telling is the amount of explaining I'm having to do to explain
that in a network with over 100 FDDI rings/Ethernet segments (~60/~40) that
there is no need for routing.  Most unix and/or Internet people think that
this would require one mother of a router so that each segment can be its own
subnet.  Of course, with a router connecting each ring/segment, there is
`no problem' in doing things like fragmenting and implementing path mtu logic.

>>Ethernet LANs so that it limits the packet size appropriately.  The algorithm
>>is simple and available to any protocol that chooses to implement it.  Set
>>the priority field in FC to non-zero and then check incoming packets for each
>>peer.  If the priority is zero in the inbound FC then the packet came via
>>some other path than pure FDDI.

    Aahhhh!  That may work when using all Digital gear, but who says that
    the other FDDI vendors use 50h for the FC byte when coming across a
    10/100 bridge?
    
>>Note that this is just one protocol feature that NISCS has that is not supported
>>in any other popular protocol.
    
    Other protocols rely on MTU discovery or packet size negotiation on a
    connection by connection basis.  For example, Novell's IPX
    implementation does negotiate packet size, but it also sends test
    packets to verify that the packet size works.  If not, they have an
    algorithm where they nail in on the largest packet size that works by
    sending/resending test packets of varying lengths.
    
>>But another reason is that the underlying belief systems prevent considering
>>other options.  For example, NISCS aggressively supports multiple adapters
>>and communication paths for increased availability and performance.  The IP
>>belief system holds that this is impossible and unneeded since ATM or something
>>will provide unlimited scaling using a single interface.
    
    I don't believe you'll find that "IP belief system" in today's market. 
    In fact, outside vendors like Microsoft and Novell have multiple NIC
    support in their TCP/IP stacks with optional routing support.  There
    are plenty of examples of vendors touting the installation of more than
    one interface in a system to increase performance and/or reliability. 
    Some of this information is FUD (eg. four 10Mbps Ethernet adapters does
    not equal 40Mbps) but there are many users who install multiple NICs in
    end nodes (usually servers).
    
       - Larry

    ...for reference, this use of the priority is discussed in 802.1i
    and notes 319 and 1561 in this notes conference...

Re: .4:   If you buy a non-802 compliant bridge, then you deserve
          whatever you get.

DECnet/OSI also uses the FC snooping (and hopefully IPv6 will as well; I
submitted comments to that effect).