The last of the 12 truths of networking has a long history in the IETF, particularly in relation to the development of protocols. “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.” This rule has been overridden so often in networks and protocols that it almost seems inoperable—take, for instance, the number of tunneling protocols currently in use, each of which was designed to be “the last tunneling protocol ever designed.”
Or, perhaps, the many different telemetry and management systems stuffed into networks. I once sat in a three-day meeting where the first two days were taken up working through a spreadsheet of every custom-built and commercial telemetry or network management tool being used in the network. The third day was just everyone pointing fingers at everyone else about why we had so many tools, who maintained them all, and whose tool should become the “one tool to take the place of all the other tools.” In other words, the third day of the meeting was largely useless, other than when classified as entertainment.
There are some places, however, where the removal of all unnecessary things is actually taken seriously—and no, I’m not talking about feature sets in vendor products, which seem to accumulate like the junk in my junk drawer, until it overflows beyond all reasonable bounds. No, I’m talking about some clever ways the fine folks in the IETF have discovered to reduce some protocols to the minimum.
For instance, RFC1924 takes note of the many different numbers and letters required to write an IPv6 address. Why so many? Wouldn’t it be following rule 12 more closely if we could represent an IPv6 address in a much shorter form? After all, using a shorter string of symbols is technically “removing” things, and removing things is the goal, so … The authors of RFC1924 posit that by treating an IPv6 addresse “as a 128 bit integer, encode that in base 85 notation, then encode that using 85 ASCII characters,” the address can be written in a dramatically shortened form. This can save a lot of space on network diagrams, which are, after all, a crucial use of IP addresses.
Another form of removing things from protocols is suggested by RFC8565, which suggests removing answers from HTTP to create Hyper-Text Jeopardy Protocol, or HTJP. This idea not only removes the answers from the protocol, thus making the protocol simpler, it also increases security by making it much harder to guess what the sender and receiver are saying to one another. In this case, instead of answering with information, the client supplies the information, and the server responds with an appropriate question.
Perhaps the ultimate example of removing everything possible, however, is represented by RFC6592, which defines the Null Packet. The Null Packet is often referenced, as it turns out, but is not defined anywhere. A Null packet has no content, being 0 octets in length, and hence has no header, nor any protocol identifier, nor even a packet length. Null packets are never really transmitted, because there is nothing to encode, and they are ignored when they are not received.
The Null packet, containing nothing, represents the ultimate expression of rule 12—there is nothing else to remove, because there is nothing in the protocol packet to begin with.
Russ White has more than twenty years' experience in designing, deploying, breaking, and troubleshooting large scale networks. Russ is currently a member of the Architecture Team at LinkedIn, where he works on next generation data center designs, complexity, and security. His most recent books are The Art of Network Architecture and Navigating Network Complexity.