Why TCP Was Split Into TCP and IP

#TL;DR

When Vint Cerf and Bob Kahn published their 1974 protocol paper, it described a single protocol called TCP that handled addressing, routing, reliability, and ordering all at once. By 1978, Jon Postel — the RFC editor who would later become one of the internet’s most quietly consequential figures — had spent four years arguing that this was a mistake. Reliability and routing, he pointed out, weren’t the same problem, and welding them together meant every application on the network paid the cost of guarantees most of them didn’t want. Postel won. The split produced the layered stack the internet still runs on — IP at the bottom, TCP and UDP as separate transports on top — and made possible DNS, VoIP, video streaming, online games, and eventually QUIC.

#What the Original 1974 TCP Did

The paper Cerf and Kahn published in IEEE Transactions on Communications in May 1974 — “A Protocol for Packet Network Intercommunication” — described one protocol that did everything needed to get a message from host A to host B reliably across arbitrary intermediate networks.

That protocol handled:

Addressing. Each host got a globally unique identifier.
Routing. Gateways between networks decided how to forward packets.
Reliability. Packets that got lost were retransmitted; out-of-order packets were reordered; duplicates were discarded.
Flow control. The sender slowed down if the receiver got overwhelmed.
Fragmentation. Big messages got chopped up to fit the smallest network between sender and receiver.

It was elegant as a research sketch. It was also a monolithic spec trying to serve every possible use case, and by 1977 implementers were finding that a lot of those use cases didn’t need everything TCP offered. Worse, they were paying for it anyway.

#Postel’s Objection

Jon Postel had been editing RFCs since RFC 40. By 1977 he was the de facto editor of the entire series, which meant he read every protocol proposal the ARPANET community produced and had an unusually clear view of which designs tended to work and which didn’t.

Postel’s argument, which shows up across a series of RFCs and design notes in 1977 and 1978, was structural:

Routing is a property of the network. Reliability is a property of the conversation.

They run on different timescales, serve different stakeholders, and fail for different reasons. Combining them in one protocol means:

Applications that don’t need reliability still pay for it. A DNS lookup sends one request and expects one response. Wrapping that in a full three-way handshake, retransmission logic, and connection teardown is absurd overhead for a single query.
Applications that need different reliability semantics can’t get them. Real-time audio would rather drop a late packet than wait for a retransmission that makes the playback stall.
The network layer is harder to evolve. Every time you want to change the addressing or routing scheme, you touch the reliability code too.

Postel proposed a clean layering: one protocol for addressing and routing, a separate protocol on top for reliability, and the option to bypass the reliability layer entirely for applications that didn’t want it.

#The Split

By IEN 2, then IEN 26, and finally in the 1978 and 1980 RFC drafts, the single TCP became three things:

  ┌───────────────────────────────┐
  │            TCP                │   ← reliable, ordered, connection-oriented
  ├───────────────────────────────┤
  │            UDP                │   ← unreliable, unordered, fire-and-forget
  ├───────────────────────────────┤
  │            IP                 │   ← addressing and routing, best-effort
  └───────────────────────────────┘

IP became the network layer. It does addressing (every host has an IP address) and best-effort delivery. A packet either arrives or it doesn’t. IP makes no promises.
TCP became a transport layer that sits on top of IP. It adds reliability, ordering, connection state, flow control, and congestion control. If you want to think of a connection as a stream of bytes, TCP is what makes that illusion work over unreliable IP.
UDP became an alternative transport layer, also on top of IP, but with almost none of TCP’s guarantees. UDP is a thin wrapper around IP that adds port numbers (so multiple applications on the same host can share an IP) and a checksum. That’s it.

The crucial part of the split wasn’t just having two protocols on top of IP. It was that applications got to choose.

#What UDP Unlocked

Without UDP, a whole category of applications either wouldn’t exist or would have to reinvent a TCP-bypass mechanism from scratch.

DNS — every domain name lookup is a single UDP request and response, finishing in one round-trip. Running DNS over TCP would triple the round-trips and quadruple the bytes on the wire. The DNS root would have collapsed under TCP overhead by the late 1980s.
VoIP and real-time video — voice and video are latency-sensitive, loss-tolerant. A late packet is useless; you’d rather skip it than wait. TCP’s retransmission behavior is exactly wrong for this use case.
Online games — multiplayer game state updates run over UDP because the game would rather drop a stale position update than stall the player waiting for it.
DHCP, NTP, SNMP, TFTP — simple request-response or announcement protocols that fit in a single packet. TCP would be overkill.
Multicast and broadcast — TCP is a point-to-point conversation. Sending the same packet to many receivers at once requires UDP’s connectionless model.

UDP is structurally simpler than TCP because it makes no promises. That’s also why it can do things TCP never can.

#The Hourglass That Resulted

The split produced what Internet Protocol designers started calling the hourglass model — a diagram that captures why the internet could scale and evolve in ways earlier networks couldn’t.

    HTTP  SSH  SMTP  DNS  QUIC  WebRTC  ...  ← many application protocols
         ╲   │   │   │   │    ╱
           ╲ │   │   │   │  ╱
    ┌──────────────────────────┐
    │      TCP   UDP   ...     │              ← a few transport protocols
    ├──────────────────────────┤
    │           IP             │              ← ONE network protocol
    ├──────────────────────────┤
    │      TCP   UDP   ...     │
    │                          │
    └──────────────────────────┘
         ╱   │   │   │   │   ╲
       ╱     │   │   │   │     ╲
  Ethernet  Wi-Fi  4G  5G  fiber  satellite  ← many link layers

One protocol at the narrow waist — IP — and arbitrary diversity above and below. The link layer can change (Ethernet, Wi-Fi, 4G, LTE, 5G) without breaking applications. New application protocols can be invented (HTTP, WebRTC, QUIC) without touching the network. The one thing you can’t change, without changing everything, is IP itself.

This is why IPv6 has taken thirty years to deploy. Changing the narrow waist is structurally expensive. Every other layer is cheap.

#The Counterfactual

What would have happened without the split?

We can look at ISO’s competing OSI standards effort for a partial answer. OSI kept a much fatter stack — seven layers, with session management, presentation encoding, and application features all specified at the network level. OSI was the official, government-blessed successor to the ARPANET protocols for most of the 1980s.

OSI lost decisively. One reason among several was that its layers were too tightly coupled. You couldn’t ship a small change. You couldn’t run a non-standard application protocol over a standard transport. By the time the specifications were ratified, TCP/IP — iterating freely through RFCs on the layered stack — had overtaken them.

The split also enabled the end-to-end principle to hold. If TCP were inseparable from IP, features like encryption, congestion control, and reliability would be network-layer concerns — baked into routers, impossible to evolve without replacing hardware. Because TCP lives at the endpoints and IP is thin, end-to-end innovation stayed cheap.

#What Postel Actually Won

The TCP/IP post summarizes the split in a paragraph. What’s easy to miss is how much downstream architecture depends on it:

TLS exists because there’s a clean handoff from TCP to an application-layer encryption scheme. A monolithic TCP-with-security would have been much harder to evolve.
QUIC exists because UDP is still dumb and unopinionated. Building a new reliable transport on top of UDP is possible precisely because UDP promises nothing. You couldn’t build a new transport on top of TCP; TCP is already opinionated all the way down.
Cloud-scale load balancing works because connection state lives at the endpoints. An L4 load balancer can move a TCP flow between backends without understanding TCP internally.
IPv6 is deployable at all because changing the network layer doesn’t require changing the transport layer. TCP and UDP run over IPv4 and IPv6 with minor tweaks.

Postel’s instinct was that reliability and routing are different problems served by different concerns and should be encoded separately. The industry spent the next fifty years validating that instinct, not by arguing about it, but by discovering every new system they wanted to build was easier because of it.

In 1978, splitting one protocol into three looked like a small cleanup. It turned out to be the decision that made the internet keep evolving.