RFC 1925, an April 1, 1996 Internet Memo Filed as Humor, Listed 'You Can Always Add Another Level of Indirection' Among Twelve Networking Truths

Chris Pirillo holds a network cable that loops through a tower of nested boxes while a pig with a rocket on its back flies overhead — Illustration: LockerGnome

The memo’s byline puts Callon at the “Internet Order of Old Farts,” care of Bay Networks, and its status section is plain about what it is: it “does not specify an Internet standard of any kind.” The abstract adds a wink, saying it isn’t a standard “except in the sense that all standards must implicitly follow the fundamental truths.”

The truths start simple. Rule 1 is “It Has To Work.” Rule 2 says that no matter how hard you push, “you can’t increase the speed of light,” with a corollary that you can’t make a baby in much less than nine months, and trying to speed it up “might make it slower.”

Rule 3 is the most quotable. “With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.” It continues that it’s hard to know where they’ll land and dangerous to sit under them.

Rule 6 is the one that reaches past networking. “It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.” Its corollary, 6a, reads: “It is always possible to add another level of indirection.” Then Rule 11 circles back to it. “Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works,” and its corollary is just “See rule 6a.”

The rest of the list fills out the cynicism. Rule 7a is “Good, Fast, Cheap: Pick any two (you can’t have all three).” Rule 9a says every networking problem “always takes longer to solve than it seems like it should.” Rule 12 borrows the old line about perfection, which arrives “not when there is nothing left to add, but when there is nothing left to take away.” Even the Security Considerations section gets a line: “security protocols are subject to the fundamental networking truths.”

Rule 5 warns that “it is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.” That spelling is the original’s. When Randy Bush and David Meyer wrote RFC 3439 in December 2002, a straight-faced memo on Internet architecture and what they called the Simplicity Principle, they quoted Rule 5 as a corollary to their argument against piling up layers, and fixed the spelling to “agglutinate” on the way.

RFC 1925 also has company. April 1 RFCs go back at least to RFC 1149 in 1990, which described sending Internet packets by “avian carriers.”

Steal this

Ask “are we solving it or moving it?” before adding a layer. When a fix is a new proxy, wrapper, queue or service in front of the broken thing, write one sentence saying what the problem was and whether it’s gone or just somewhere else now. This is like sweeping dust under a rug: the floor looks clean until someone lifts the corner.
Split problems that don’t share a cause. When one design is meant to fix three unrelated complaints, break it into three smaller changes, so each can be tested and backed out on its own, the way RFC 3439 argues for keeping layers separate. Kind of like not wiring the doorbell, the porch light and the garage door to one switch.
Search for the old name of a “new” idea. Before a team adopts a fresh pattern, spend ten minutes looking for what it was called fifteen years ago and how that went. This is like checking a used car’s history report before you fall for the paint job.

The rule about indirection lands differently now than it did in 1996, when it was aimed at network architecture. Today’s systems are built from containers inside virtual machines inside clouds, behind gateways and service meshes. Which of those layers solved a problem, and which ones just moved it somewhere a little harder to see?

More Retro