[ih] Internet-history Digest, Vol 65, Issue 23

[John Shoch]

I do not want to lightly challenge Dave Crocker's memory nor the
programming skill of whoever implemented XNS at UB 45 years ago, but I do
feel the need to come to the defense of the XNS internet protocols.

You observe that, "Eventually the culprit was found to be a bad U-B
interface card. But none of the networking protocols enforced data
integrity and this problem had,
apparently, gone on for months."
Of course I have no real data about the problem, but I have a suspicion:  I
rather doubt that this was a protocol design issue, but it was much more
likely an implementation issue:

--The XNS protocols were widely implemented and used at the time, without
systematic error problems.
--Published by Xerox they were the basis for many early internetworking
products from U-B, Novel, and others.  Cisco's multi-protocol routers
routed both PUP and XNS packets.
--From Wilipedia:
"The protocol suite specifications for XNS were placed in the public domain
in 1977. This helped XNS become the canonical local area networking
protocol, copied to various degrees by practically all networking systems
in use into the 1990s. XNS was used unchanged by 3Com's 3+Share and
Ungermann-Bass's Net/One. It was also used, with modifications, as the
basis for Novell NetWare, and Banyan VINES"
     https://en.wikipedia.org/wiki/Xerox_Network_Systems
--There is some documentation at:

https://bitsavers.org/pdf/xerox/xns/XNSG_068504_Xerox_System_Network_Architecture_General_Information_Manual_Apr85.pdf
--There was, of course, a checksum in every XNS internet packet:
"The Internet packet fields fall into three categories: addressing fields,
which specify the address of the destination and source network addresses;
control fields, which consist of checksum, length, transport control, and
packet type fields; and data fields,. which carry the data and consist of
information that is interpreted only at the next higher Courier layer. "
--Furthermore, at a higher level of the protocol stack the Filing protocol
included a separate checksum over an entire file:
"Attributes are additional information about the file: they are partitioned
into interpreted and uninterpreted attributes. ..."
"At the files sub-layer, some of the interpreted attributes are: - a binary
file identifier - a file name as a human sensible character string. - a
flag indicating temporary or permanent - a version number - a checksum -
the file size (in octets) - access control information -the time and
identity of the client performing the operation. "

During that period we did occasionally see problems other people were
having:
--In some cases, they had just turned off the checksum capability....caveat
emptor.
--In other cases (perhaps at UB) they were implementing protocols in a
separate smart NIC;  performing a packet checksum there did not protect you
from errors in the NIC or in the path to main memory.  (A lesson learned
from IMPs doing error detection, and then introducing an error on the way
to the host.)  It's why we often preferred "dumb NICs" with error
processing being done in the main memory.
--You note that, "...the culprit was found to be a bad U-B interface." No
packet checksum can protect you from an error beyond the scope of the error
checking.
--Note that the same problem would occur if you did the TCP stack and
checksum in a smart NIC that was introducing errors...

Am I missing something?

John Shoch

------------------------------
>
> Message: 2
> Date: Sun, 20 Apr 2025 08:24:05 +0000 (UTC)
> From: Dave Crocker <dhc at dcrocker.net>
> To: internet-history at elists.isoc.org
> Subject: Re: [ih] Checksums in Host-Host protocol
> Message-ID: <a716c6bd-7d28-428a-8ef8-82658fdededa at dcrocker.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> > On Friday, April 18, 2025 at 03:12:39 PM EDT, Steve Crocker via
> > Internet-history <internet-history at elists.isoc.org> wrote:
> > ...
> > We removed the checkum from our design, a mistake I've rued ever since.
>
>
> I was at Ungermann-Bass(*) in the latter 1980s, and managed its
> development of a TCP/IP stack for its 'smart' Ethernet cards. These has
> a Intel 186 chip on the card.
>
> U-B?s original business was using networking tech to do terminal
> concentration back to mainframes.? That is, they reduced the amount of
> wiring needed back to the mainframe.? Eventually, however, they had to
> support PCs and that included Netbios and SMB.
>
> The original U-B protocol stack was a modified XNS, which was true for a
> number of vendors, each making their own adaptations. (I think I was
> told that XNS had been published well enough to use but the Internet
> protocols were not yet stable, when these networking companies were
> getting started.)
>
> While I was at U-B, there was a major fire drill for a customer that
> discovered they had very serious file data corruption. Eventually the
> culprit was found to be a bad U-B interface card. But none of the
> networking protocols enforced data integrity and this problem had,
> apparently, gone on for months.
>
> It was quietly noted that had they been running with TCP, there would
> have been no data corruption.? Just an increase in retransmissions...
>
>
> d/
>
> (*) Ungermann-Bass was one of the original LAN companies, though it did
> not market as a networking company.? It had a very few, very large
> customers, and it never quite managed to expand from this.? One example
> was that its 'dumb' Ethernet card was superior to the wildly popular
> 3Com Ethernet card.? Another was that as a private tool to aid
> development debugging, I adapted a packet tracing tool to provide
> symbolic TCP and IP traces.? After seeing some ops admin customers get
> excited about this tool, as I used it to show how the smart Ethernet
> card was performing, I tried to get Marketing interested in selling it
> and they declined.? About 2 years later, Harry Saal was making good
> money off of a similar product. sigh.
>
> --
> Dave Crocker
>
> Brandenburg InternetWorking
> bbiw.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
>
>
>