🚀 go-pugleaf

In article <mbt.718307170@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> 
> >> IP aside how does SGI deal with ether to FDDI translation bridging
> >> of protocols that don't use byte level acks? Just courious...
> 
> >I don't know what is meant by "byte level acks".  Protocols such as TP4
> >or XNS with records?  What problems special do they have?
> 
> A bridge can't fragment a 4K XNS/IPX datagram the way it can a IP
> datagram. The only reason you can frag an IP packet is because the
> seq numbers are at the byte level. With XNS et. al. since the seq
> numbers correlate to packet number a bridge can't really fragment
> packet number 2 into packet number 2 and packet 2.5. The end node
> is going to send out packet seq number 3 after 2. So how can the
> bridge fragment?



I don't know about XNS or IPX, and I can't find any equivalent to the
IP offset or MF bits in the "Internet Protocol" described in my old
Xerox XNS documents.

The TCP sequence numbers have absolutely nothing to do with fragmenting
TCP/IP, UDP/IP, or any other current IP protocol.  IP fragmenting is
done entirely within the IP datagram, and is based on the 8-byte
"offset" and the "more fragments" flag.

The only IP fragmenting that an FDDI-ether bridge will usually need to
do is of UDP packets.  UDP packets are datagrams, and have no sequence
numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
initial MSS negotiation in TCP will pick 1500.  This is consistent with
the TCP/IP lore (and RFC) that considers fragmenting harmful.


Vernon Schryver,  vjs@sgi.com