🚀 go-pugleaf

In article <mbt.718307170@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
|>vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|>>In article <mbt.717984230@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?

Wrong.  IP works not because of the byte level acks (which obviously
don't exist in UDP), but because the IP network layer supports the
fragmentation of IP packets.  The destination system will gather the
fragments, rebuild the IP packet and then process it.  The upper layers
(TCP/UDP/...) don't even (have to) know that fragmentation happened.

CLNS supports fragmentation of its packets so a bridge could fragment
them and TP4 wouldn't care (even though it uses segment based acks).

Protocols such as LAT, XNS, or DECnet Phase IV which don't support
fragmentation must either restrict themselves to using 1500 byte packets
or use "some" method of determining whether packets to the remote target
system traverse an Ethernet.
--
Matt Thomas                     Internet:   thomas@lkg.dec.com
DECnet-ULTRIX Development       UUCP:       ...!decwrl!thomas
Digital Equipment Corporation   Disclaimer: This message reflects my own
Littleton, MA                               warped views, etc.