Summary

  • RFC 872 challenged a 1982 fear that TCP was inherently too heavy for a fast, low-error local area network. The relevant question was what service the application needed between hosts.
  • Padlipsky accepted leaner choices where they fit, including UDP or direct use of local facilities; a separate local protocol suite also created code to build and maintain alongside the suite used across networks.

A short, fast cable made TCP look like a dinner guest who had arrived with a suitcase for an overnight visit. In RFC 872, published in September 1982, Michael A. Padlipsky asked what was actually inside the suitcase. Engineers had begun to repeat that TCP, designed for communication across connected networks, was somehow unsuitable on a local area network. His essay called the growing fear a Woozle: people following one another's tracks until they thought the tracks belonged to a beast. The network had a real cable. The beast was an argument waiting to be examined.

Padlipsky first specified the room in which this beast supposedly lived. His LAN was a short-distance communications subnetwork with high bit rate and relatively low errors, connecting potentially different computers for resource sharing. It could use different media and topologies. The defining work was host-to-host communication, not a particular shape of cable. A collection of terminals reaching several hosts, without those hosts running intercomputer protocols with each other, was a different arrangement in his terms.

That distinction mattered because a fast local link answered questions about moving bits while the attached computers still had to agree on services.

TCP supplied one such service: a reliable logical connection, with flow control and ordered delivery, for an application that expected it. The application's needs did not shrink when its peer was down the corridor. A file transfer still had to arrive in order; a conversation that depended on a logical connection still needed its endpoints to maintain one. The short path might reduce some kinds of trouble, but the task at the endpoints remained the task. “Local” described the physical neighborhood, not a waiver issued to the application.

Padlipsky then separated TCP from IP, a distinction often lost when people argued about the pair as though it were one solid block. IP dealt with the nearby network and with the path beyond it: deciding whether a destination was local or required a gateway, fitting packets to networks with different limits, and delivering each packet to the appropriate upper protocol. Keeping IP separate let other host-to-host protocols use that machinery. A host that could reach only local peers had one set of options; a host that also had to reach the wider catenet had another.

The latter needed a common way to cross the boundary, even when the first hop was a LAN.

The menu included UDP. In the RFC's account, a use such as packetized speech might value speed over TCP's reliability features. An application could also use facilities of a local network more directly if that suited its design. Padlipsky's practical objection concerned maintenance when a site invented a second, parallel host-to-host suite for local work while keeping TCP/IP for communication beyond the LAN. Two stacks mean two bodies of code and two sets of assumptions in the same machines. A fast link might justify a specialized path; the supposed automatic need for one was the Woozle.

There was a fair performance question. If a LAN had few transmission errors, the TCP checksum could seem like unnecessary ceremony. Padlipsky reported measurements from several research-community host implementations that put checksum processing at a modest share of per-transmission work. That reported share belonged to those implementations in 1982. The larger point was methodological: compare the whole cost of the service and its replacement, including the host's work. Removing one visible operation does not tell you what the application, disk, scheduler or alternative protocol will cost.

A machine cannot send data faster than it can fetch, prepare and hand over that data.

The paper listed operating-system implementations, deployed application protocols and observed TCP performance as evidence that the suite existed outside a drawing. It also insisted on careful measurement of TCP/IP on LANs. Local alternatives could earn their place where a particular task and measured constraint called for them. Engineers had to compare like service with like service, and account for the host as well as the wire. A headline link speed was a poor substitute for that experiment.

Read as a 1982 intervention, RFC 872 shows a useful way to disarm a fashionable technical fear. Start with the application: does it need ordered, reliable, flow-controlled communication? Follow the path: must the same host speak beyond the local link? Then measure the actual machine, link and software together. The monster shrinks quickly when the questions get specific.