Before the internet became the thing everyone uses, several other technologies intended to be the world's network, and several of them had cleverer people and far more money behind them.
X.25, Frame Relay, ATM — those names are in every textbook and almost nowhere else.
What makes this interesting is not that it is history, but that the ones that lost did not lose by being worse. Several did things the internet still cannot — guarantee quality, meter usage precisely, carry error control built in.
What they lost on was a choice made at the first question, and this article computes what that choice costs, in bytes.
If you have never thought about this, start here
Every network faces one basic question — before sending data, must the path be reserved first?
Reserve first builds the path, then sends. That path is yours until you release it.
Do not reserve sends immediately, and each piece finds its own way, possibly by different routes.
Old telephony chose the first. The internet chose the second, and nearly everything that followed is a consequence.
Reserving the path, and what it costs
Reserving a circuit buys something valuable — certainty. Once reserved, the rate and the delay are fixed. Nobody competes for it, there is no queue, nothing is lost.
The price is that the reserved channel is yours even when you are not using it. In an ordinary telephone conversation people take turns and leave long silences, so half the channel sits empty for the whole call.
For computer data it is far worse, because traffic arrives in bursts. Loading a web page uses the full rate for two seconds, then goes quiet for five minutes.
Sending piece by piece and finding the way
The alternative is to reserve nothing: put the destination address in every piece and let the devices along the way decide, one piece at a time, which way to send it — which is what the IP article describes.
The upside is a shared path: while one party is quiet, another gets all of it. The downside is that nothing is guaranteed — delay varies, pieces can be lost, and they can arrive out of order.
Accepting those downsides is what let it win, because not having to remember anything in the middle means the devices in the middle are cheap and simple, and the network can grow without anyone agreeing in advance.
Virtual circuits — the middle road that once looked like the answer
X.25, Frame Relay and ATM took the middle road — build the path in advance like a reservation, but do not hold bandwidth for it. That is a virtual circuit.
A piece of data then need not carry a full destination address, only a short circuit number, which is smaller and much faster to look up. In an era of slow hardware that was a genuine advantage.
The price is where you cannot see it — every device along the path has to remember every circuit passing through it. The more users, the bigger the tables, and adding a new path means configuring every device along the way.
Compare that with IP, where a router need not know about any connection at all, only which way a given prefix goes. That difference decided which one could grow to the size of the world.
ATM and the 53-byte cell
ATM went one step further. Rather than sending pieces of varying size, it cuts everything into fixed-size pieces called cells, because equal-size pieces make it possible to build very fast switches in pure hardware and to compute delay precisely — which matters a great deal for voice.
The size chosen was 53 bytes: a 5-byte header and 48 bytes of payload.
cell 53 bytes
header 5 bytes
payload 48 bytesHeader overhead alone is 5 divided by 53, or 9.43% paid always, whatever you send, whether the line is idle or full.
And that is not even the expensive part.
The real cost of cutting into equal pieces
Carrying IP over ATM follows RFC 2684 — append an 8-byte trailer, then pad up to a multiple of 48 before cutting into cells. The document shows the padding field as PAD (0 - 47 octets).
Here is what that does, computed.
IP bytes cells on wire overhead
40 1 53 32.5%
41 2 106 158.5%
64 2 106 65.6%
576 13 689 19.6%
1500 32 1696 13.1%The first row is a bare 40-byte TCP ACK, one of the most common packets on the internet. It pays 32.5% overhead.
The second row is the one that startles people.
A cliff one byte wide
Because cells are a fixed size, adding one byte of data can require another whole cell.
40 bytes -> 53 on wire 1 cell
41 bytes -> 106 on wire 2 cells +53The +53 is the extra bytes on the wire caused by adding a single byte of data.
Cliffs like that sit every 48 bytes across the whole range, and they do not go away at larger sizes either.
1528 bytes -> 1696 on wire 32 cells
1529 bytes -> 1749 on wire 33 cells +5313% at full frame size, plus 32% on small packets, plus a cliff every 48 bytes was the price paid for the life of the technology, in exchange for fast switches and computable delay.
When ATM was designed that trade was worth it, because building a high-speed switch for variable-size pieces was still very hard. Once hardware caught up, the advantage disappeared. The overhead did not.
Why 53
The number 53 did not come from engineering. It came from a compromise.
The voice side wanted small cells, because a bigger cell means waiting longer to fill it before sending, which adds delay and forces echo cancellers. The data side wanted large cells, because header overhead falls as the cell grows.
The proposals were 32 and 64. What emerged was 48, exactly in the middle, plus a 5-byte header, making 53.
A number nobody wanted became the number everyone paid for thirty years.
A note — the story of that compromise is widely repeated in the industry. The ITU-T document defining the cell does not explain why the number was chosen, and while this article was being written the ITU server returned an error, so I could not verify it at the source. What is verifiable is the 53 and 48 figures, cited from RFC 2684, and the overhead computed from them.
What survived
Those technologies are gone, but one idea is not — putting a short label in front of a piece of data and letting devices along the way decide from the label instead of searching a full routing table.
That is what MPLS does, and it is in nearly every carrier network today. The difference from its ancestors is that it sits on top of IP rather than trying to replace it.
The lesson is that the winner is not the technology that is best at everything, but the one that requires the least agreement in advance. A network you can extend without asking anyone's permission grows faster than one that needs configuring at every point along the way — even when the second gives better quality.
When it lies
"Packet switching is always more efficient." Not always. For steady traffic that needs constant delay, reservation clearly wins, which is why leased circuits still sell today.
"ATM died because the technology was bad." It died because it cost more agreement, and because hardware caught up and erased its main advantage. Not because it was badly designed.
"A few percent overhead does not matter." Thirteen percent on a circuit billed by bandwidth is real money every month, and 32% on traffic made of many small packets is not a figure to wave away.
"A WAN is just a longer LAN." They differ in cost per bit and in who owns the medium in between, which changes every design decision. The Wi-Fi article shows the parallel case: once the medium is shared with others, every assumption changes.
Real cases from real work
Case 1 — computing overhead before buying a circuit
Situation A provider quotes a circuit in bits per second, and you need to know how much actual data that yields.
How to read it Ask at which layer the number is counted. If it is a layer that cuts data into cells, allow for the overhead in the table above — and note that the figure depends on the packet sizes in your real traffic, not one fixed number. Traffic with many small packets loses far more.
What this does not prove The table is computed for AAL5 per RFC 2684 alone. A real circuit may have further encapsulation layers stacked on it, adding more. You have to ask the provider where their number is measured.
Case 2 — choosing between a leased circuit and the internet
Situation Two branches must be connected, and the two options differ enormously in price.
How to read it Ask whether the real work tolerates variable delay. For file copies or web traffic the internet is far better value. For voice, or a system that needs a constant response time, a reserved circuit still has a case, because what you are buying is not speed but certainty.
What this does not prove The certainty a provider guarantees is a contract, not physics. Read what is actually guaranteed and how it is measured; the sales figures and what you can measure may differ.
Case 3 — reading "virtual circuit" in a datasheet
Situation A provider's document uses the phrase and you need to know what it means here.
How to read it Ask three questions.
1 is bandwidth actually reserved, or only a number in the contract
2 if the main path breaks, is failover automatic, and how fast
3 where must configuration change to add a new endpointThe third separates a virtual circuit from IP most clearly. If the answer is "in several places", that is the pattern this article describes.
What this does not prove The same phrase means different things across products. These three questions describe the behaviour you need to know far better than arguing about definitions.
References
Standards that are free to download
- RFC 2684, encapsulating IP over ATM's AAL5 — the source of the 48-byte payload and the
PAD (0 - 47 octets)field used in the computations here - RFC 2427, multiprotocol interconnect over Frame Relay
- RFC 1356, multiprotocol interconnect over X.25
Computed here
- The overhead table and the cliff every 48 bytes, computed from a 53-byte cell, a 48-byte payload, and the 8-byte AAL5 trailer specified in RFC 2684
What could not be verified at the source
- The origin of choosing 48 from proposals of 32 and 64 is widely repeated but the ITU-T document defining the cell gives no reason, and the ITU server returned an error while this was written. It is noted here rather than presented as verified.