Summary
- Craig Partridge's 1989 BBN report argued that one-gigabit speed did not by itself require a new network architecture. It replaced the headline rate with separate tests for packet rate, processor work, data touching, buffering and control delay.
- The result depended on declared forecasts: larger average packets, 60–70 MIPS processors, 64-bit paths and sufficient memory. Propagation did not accelerate, so bandwidth-delay inventory and the time needed to learn capacity remained genuine constraints.
- In 1998, the BBN MultiGigabit Router team reported a 50-Gb/s backplane and up to 32 million packets per second. That was a bounded implementation receipt, not a solo invention or proof that every future speed and traffic mix would scale automatically.
A unit of speed had acquired constitutional force
Partridge's starting point was a belief, not a failed machine. Networking researchers expected the jump from 10-megabit local networks to more than one gigabit per second to strain datagram architectures severely. The threshold at which they would break was rarely specified. One gigabit had become a convenient magnitude at which architectural replacement felt inevitable.
BBN Report No. 7080, dated 5 June 1989 and preserved in the IETF's fourteenth meeting proceedings, attacked that inference. Partridge did not say that gigabit networks presented no hard problems. He asked whether the problems were unusual enough to require a different architecture. He also tried to remain neutral between datagrams and virtual circuits. If both could meet the target, choosing between them was a matter of preference and function, not technological necessity.
That distinction is easy to lose. A design may deserve to change because it cannot satisfy a defined workload. It does not deserve to change merely because a large number makes continuity sound old-fashioned.
The line rate became a packet deadline
The report disclosed two assumptions. Average packets on a gigabit network would be no smaller than contemporary Internet packets, and components already in test production could indicate what early-1990s routers and hosts might do. Partridge used a 60–70 MIPS RISC processor and 64-bit data paths as conservative candidates. These were forecasts, not guarantees.
For routers, the useful denominator was packets per second. Contemporary expectations of 6,000–10,000 packets per second between two or three Ethernets became an extrapolated 600,000–1,000,000 packets per second at a gigabit. A 60-MIPS processor would then have roughly 60–100 instructions for a packet, or 1–1.6 microseconds before the next one arrived.
That accounting exposed both opportunity and risk. A virtual-circuit fast path could amortise setup. Basic IP forwarding was estimated at roughly 100–150 instructions on then-common 32-bit processors, plus driver work. Wider operations, simpler drivers, pipelining or hardware assistance could move the boundary. Small packets could move it in the other direction. “One gigabit” was not one workload: a stream of acknowledgements and a stream of large transfers asked the router to do very different numbers of decisions.
Hosts paid for bytes that routers could avoid touching
Hosts and routers did not share the same job. A router usually needed the header. A receiving application often needed the data. Partridge separated protocol processing, operating-system work and application work, using earlier TCP measurements to construct an illustrative host budget of about 1,000 fixed instructions plus work proportional to packet length divided by the machine word size.
The graph made packet size the free variable. Under the paper's 60-MIPS model, an average packet of roughly 3 KB could let a host fill a gigabit. At 512 bytes the host could use nearly a quarter of the link; at 100 bytes, about 50 Mb/s. These were not promises for a product. They demonstrated why line rate, packet rate and data-touch rate must not be collapsed into one capacity claim.
Partridge had already co-authored RFC 1071 with Bob Braden and David Borman. Its implementation advice included combining a memory copy with checksum calculation so the bytes were fetched once for both. The arithmetic mattered, but the memory trip could be the scarce resource. RFC 4297 later summarised this family of evidence, including a historical Sun-3/60 measurement in which data-touching operations accounted for 64% of measured overhead and copying for 48%. Those percentages belong to the cited Clark study, not to modern hardware or to Partridge personally.
Their durable lesson is narrower: count the path through memory, not just the protocol instructions.
Propagation refused the upgrade
The speed of the link did not shorten the fibre. A faster network placed more bits in flight during the same round trip. Partridge's longest-path illustration produced about 5.9 MB of bandwidth-delay inventory; using a carrier delay that implied at least a 120 ms round trip produced 15 MB. In 1989, those were serious but plausible memory commitments. They were not universal buffer recommendations.
The report also separated propagation from switching. If one hundred forwarding elements each added the small delay permitted by the gigabit packet budget, their combined buffering consequence was only about 12.5–20 KB. Long-distance propagation, not a procession of fast local decisions, dominated the inventory.
Flow control had a second clock. A sender might need to learn how much capacity the path would accept. The report considered a datagram sender beginning with an eight-byte probe and expanding exponentially each round trip; it could reach the gigabit scale in under two seconds. That was encouraging for a long transfer and unacceptable for some short or interactive work. The architecture had not failed, but an application might still need a faster, trustworthy capacity signal.
Nine years later, the argument acquired hardware
The later receipt did not arrive as a cleverer slogan. In 1998, Partridge and a large BBN team described the MultiGigabit Router. The paper reported up to 32 million packet forwards per second and a 50-Gb/s full-duplex backplane, while noting that overhead traffic consumed about a quarter of the backplane capacity.
Its architecture bounded expensive movement. An inbound line card kept the packet body and sent the header to a forwarding engine. The engine looked up the route, updated the header and returned instructions; only then did the full packet cross to the outbound card. Complete forwarding tables were replicated into the engines so a central lookup could not become a thousand-times-more-expensive detour. A switched fabric replaced a shared bus. Forwarding engines were separated from line cards, link-specific headers were normalised before the fast path, and QoS classification was separated from output scheduling.
This was running-code evidence with caveats. At publication, all hardware except interface cards had been fabricated and tested, and most software was running. The quoted seven-to-eight-microsecond latency for a 128-byte datagram was an estimate built from measured software, hardware-debug observations and simulation because external interfaces and complete internal timing were not yet available. Calling the router finished would erase the most useful part of the receipt: which claims were measured, which were inferred and which remained to be completed.
The team concluded that examining every IP header at high speed was feasible and that router technology had not become obsolete. It did not prove that every routing table, failure mode, packet distribution or future line rate would behave the same way.
The person behind the denominator
The Internet Hall of Fame credits Partridge with designing domain-name mail routing, leading the first multigigabit-router team, helping invent anycast and contributing to TCP timing. Colorado State University now lists him as a professor whose research interest is the movement of bits, packets, chunks and files between machines. The breadth matters here because the 1989 paper was not a defence of one box. It was a method for refusing category errors.
Its enduring rule is to find the denominator that can contradict the claim. A rate becomes packets per second. A packet becomes instructions and memory crossings. A long path becomes bytes in flight. A connection becomes round trips before useful work. A prototype becomes a ledger of completed, estimated and absent evidence.
That is also where the argument meets Running-Code Primacy. An institution, vendor or standards body may prefer a new architecture. Preference does not become necessity merely by attaching a frightening scale. The party asking others to surrender compatibility, capital or operational control must show the failing executable path and preserve the measurements that make the failure testable.
Sources
- IETF 14 proceedings — BBN Report No. 7080
- Partridge et al. — A 50-Gb/s IP Router
- RFC 1071 — Computing the Internet Checksum
- RFC 4297 — RDMA over IP Problem Statement
- Internet Hall of Fame — Craig Partridge
- Internet Hall of Fame — public Craig Partridge portrait
- Colorado State University — Computer Science people
- Heng Lu — Running-Code Primacy
- Heng Lu — Why Reality, Not Advocacy, Is the Product
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
