The vehicle was a silver research van. The destination was a computer in Southern California. The remarkable part was that the data went through Europe to get there.
On November 22, 1977, a demonstration connected a mobile packet-radio system in the San Francisco Bay Area with a host at the University of Southern California’s Information Sciences Institute, using three different kinds of networks. SRI’s historical account identifies the route as passing through London. [1]
The 1977 three-network test demonstrated that a common internetworking protocol could support communication across packet radio, the wired ARPANET, and a packet satellite network. These networks did not have to become identical before their attached computers could communicate.
The van was the memorable prop. The important achievement was getting the boundaries between networks out of the application’s way.
What Happened in the 1977 Three-Network Test?
The demonstration brought together three experimental environments:
| Network | What it contributed | Why the combination was challenging |
|---|---|---|
| PRNET: Packet Radio Network | Mobile access over radio | A moving station could encounter changing radio conditions and connectivity. |
| ARPANET | An established packet-switched network with terrestrial links and overseas connections | Its existing mechanisms were not a universal service for every other kind of network. |
| SATNET: Packet Satellite Network | Packet communication using satellite links across the Atlantic | Satellite communication introduced different transmission characteristics and delays. |
The networks differed in more than the material carrying their signals. Their packet formats, packet-size limits, interfaces, and delivery behavior also mattered. Cerf and Kahn’s 1974 paper had already identified these kinds of differences as central internetworking problems. [2]
Think of a shipment traveling by truck, ship, and railway. The containers and handling rules at each stage can differ. What matters is having a workable agreement about how the shipment crosses each boundary and reaches the intended recipient.
Our ARPANET history explains the earlier network. The new challenge was making that network one part of a larger system.
Why Take a California Message Through Europe?
Because the point was to test the connections between technologies, rather than find the shortest route between two buildings.
In his Smithsonian oral history, Vint Cerf recalled a 1977 demonstration involving a vehicle on the Bay Shore Freeway, radio repeaters around the Bay Area, gateways, ARPANET, satellite networking, University College London, and a return to the United States. [3]
He also explained the military motivation: a mobile unit in the field should be able to reach distant computing resources through a combination of available networks. A laboratory arrangement with a conveniently short cable would not exercise that problem.
The deliberate detour made the demonstration useful. The communicating systems had to work across a chain of different networks, rather than rely entirely on the behavior of one familiar carrier.
This is a simplified account of the experiment’s purpose, not a hop-by-hop reconstruction. The number three refers to the three network types involved, not a claim that the packets crossed exactly three links or three routers.
Before the Three-Network Test, There Was a Beer Garden
The November 1977 milestone did not appear from nowhere.
In August 1976, researchers used the van in a two-network experiment associated with Rossotti’s, now the Alpine Inn, in Portola Valley. The Computer History Museum describes the team sending its weekly progress report over packet radio and then ARPANET. [4]
Do not conflate the two events: the 1976 trial used packet radio and ARPANET; the celebrated November 22, 1977 demonstration also included SATNET.
The progress report is a pleasingly practical detail: the technology was carrying a real piece of the researchers’ work.
Gateways Changed the Wrapper, Not the Meaning
How could incompatible networks carry one conversation?
A key idea was encapsulation: an internetwork packet could travel inside a packet format suitable for the particular network carrying it.
The 1974 TCP specification, RFC 675, describes a gateway removing a packet’s local-network wrapping, examining the internetwork information, and wrapping it appropriately for the next network. It also provides for splitting data when the next network cannot carry a packet of the same size. [5]
Imagine placing a letter into a courier pouch, then transferring it into a different carrier’s container. Changing the carrier’s container does not require rewriting the letter for its recipient.
That is a teaching analogy, not a literal description of every field in the experimental protocol. The useful distinction is between the format needed for one network crossing and the information needed for the wider journey.
Packet switching explains how traffic can share communication resources. Internetworking adds the problem of crossing from one packet system into another.
The gateway was therefore more than a box with two convenient connectors. Its software implemented an agreement about what information survived the boundary and how forwarding continued.
A Shared Protocol Did Not Require a Shared Internal Design
Redesigning every participating network around a single internal technology would have made each new addition dependent on changes elsewhere.
Instead, the open-architecture approach preserved the individual networks and defined how they could interoperate. The Internet Society’s history, written by researchers involved in the work, identifies independent networks, best-effort delivery, gateways, and the absence of one global operational controller as important design principles. [6]
Consider the consequence. If a new radio network could satisfy the common internetworking requirements at its boundary, the computers communicating across the system would not each need a new radio-specific application protocol.
That is the architectural payoff illustrated by the van. The system could accommodate differences underneath a common communication service.
It did not mean differences vanished. A slow or unreliable part of the path could still affect performance. Interoperability makes communication possible; it does not make every path equally fast or equally dependable.
TCP/IP Was Still Becoming TCP/IP
There is a small historical trap in calling this a demonstration of today’s TCP/IP.
The experimental TCP lineage initially combined functions that would later be separated. In August 1977, Jon Postel’s Internet Experiment Note 2 explicitly argued for separating internetwork packaging and routing from end-to-end conversation control. [7]
The familiar TCP/IP division emerged through subsequent development, with the split taking shape in 1978. It was an architectural refinement, rather than simply a new name for unchanged software. [8]
In the later IPv4 model, IP handles datagrams across interconnected networks without itself providing end-to-end reliability or sequencing. TCP provides applications with an ordered, reliable byte stream using mechanisms including sequence numbers, acknowledgments, and retransmissions. [9][10]
For a modern teaching example, suppose information arrives out of order and some is missing. A receiving TCP implementation can track what arrived, while acknowledgments and retransmission mechanisms help recover the missing data. The application need not treat the order of individual packet arrivals as the order of its byte stream.
That example describes the later TCP service, not an exact reconstruction of the 1977 implementation. Nor does reliability guarantee success through a permanent outage.
Our TCP/IP overview provides the broader protocol context. The van’s experiment belongs to the development of that architecture, rather than a claim that every detail was already finished.
The Van Was a Team Effort on Wheels
An appealing photograph can make an engineering achievement look like the work of whoever happens to be standing beside the equipment.
The Computer History Museum’s account identifies contributions across hardware, protocol implementations, gateways, and network operations. Don Nielson led SRI’s packet-radio effort; Jim Mathis and Dave Retz worked on the client implementation; Virginia Strazisar of BBN wrote gateway software. Collins Radio supplied packet-radio equipment, while other teams developed and operated the satellite and host systems. [4]
A useful way to read the story is as an integration achievement: several independently difficult pieces had to work together.
It was also part of an international exchange of ideas. Our article on the CYCLADES network explores another contribution to the architectural questions behind reliable internetwork communication.
Demonstrating an Internet Was Not the Same as Deploying It
Three milestones help keep the chronology straight:
- 1974: Cerf and Kahn published their internetworking design paper; RFC 675 subsequently documented an early TCP specification. [2][5]
- November 22, 1977: The three-network demonstration provided a memorable working example of heterogeneous internetworking. [1]
- January 1, 1983: This was the target date specified in RFC 801 for ARPANET’s complete transition from NCP to IP/TCP. [11]
The transition plan is a reminder that a successful demonstration is only one stage. Hosts needed implementations, and services such as remote login, file transfer, and mail needed to operate over the new protocols.
Calling one of these dates the Internet’s single birthday hides the different kinds of work involved: designing an architecture, demonstrating interoperability, and putting it into operational use.
The Lesson Still Traveling With Every Packet
When a modern connection crosses different access and backbone technologies, the interesting achievement is that an application can use a common networking service without becoming an expert in each carrier along the path.
That is the enduring lesson of the 1977 three-network test. A common agreement at the right boundary can connect systems whose internals remain different.
The van helped make that abstract idea tangible. A mobile node, gateways, terrestrial networking, and satellite communication could participate in one working experiment.
The vehicle stayed in California. The architectural lesson traveled much farther.
References and Further Reading
- SRI: Internetworking—institutional account of the demonstration and its equipment.
- Vinton G. Cerf and Robert E. Kahn, A Protocol for Packet Network Intercommunication, IEEE Transactions on Communications, May 1974.
- Smithsonian: Oral History Interview with Vinton Cerf, interviewed April 24, 1990; section “The Internet Stirs to Life.”
- Computer History Museum: Born in a Van—1976 precursor, the 1977 demonstration, and contributors.
- RFC 675: Specification of Internet Transmission Control Program, December 1974.
- Internet Society: A Brief History of the Internet, by participants in its development.
- Jon Postel, IEN 2: Comments on Internet Protocol and TCP, August 15, 1977.
- IEEE Communications Society: TCP Design Published—context for the subsequent TCP/IP split.
- RFC 791: Internet Protocol, September 1981.
- RFC 9293: Transmission Control Protocol—the modern TCP service, used here for comparison.
- RFC 801: NCP/TCP Transition Plan, November 1981.
