Quite often RFCs in the “earlier days” discussed not only process but also design. Looking back now, considering the complexity of the network engineering world, these RFCs might seem even a little trite. But these “architectural RFCs” often still carry thoughts and records of experience that are important, even if they aren’t so much followed any longer.
One such RFC is 5218, What Makes for a Successful Protocol? This RFC lays out the basic characteristics of protocols that fail, protocols that succeed, and protocols that “succeed wildly,” in the way of giving advice for designers of new protocols. The draft lays out two protocol design dimensions, purpose and scale, which control protocol design. A protocol that fails either doesn’t meet the requirements given, or isn’t widely deployed for some reason. A protocol that succeeds meets these dimensions, and a protocol that succeeds wildly exceeds these dimensions — as shown below in a figure based on the the original in the draft.
- An unsuccessful protocol is one that doesn’t fulfill even the scale and scope it was originally designed to contain
- A successful protocol is one that fills the lighter grey box, fulfilling the originally intended scale and scope
- A wildly successful protocol is one that fills the darker grey box, going far beyond the originally intended scale and scope
The draft goes on to describe three more areas of interest to protocol designers. The first is the effects of wild success, including failure-through-success; as engineers begin using a protocol for purposes far outside it’s intended scope and scale, problems of various types can crop up. Generally these show up as unintended consequences, but they may simply be scale issues no-one thought would ever be important. The second is the set of attributes protocols designers often strive for when building a new protocol in order to ensure success.
The second section reaches into more general engineering principles, breaking basic success factors into general groups such as positive net value, incremental deployability, open code availability, open specification availability, and open maintenance process.
This second section is of the most interest to network designers, as its focus is on general engineering, rather than specific protocol design factors. For instance, the first principle listed is hardware costs: “Protocols that don’t require hardware changes are easier to deploy than those that do.” Duh, right? On the other hand we’ve become so tied to building ASICs around each new generation of protocols that we often leave this principle in the dust. How many gates do you think are stamped into those ASICs you’re thinking about buying to support some protocol you’ll never use? When was the last time you thought about some new design, or even modifying an old design, in terms of hardware independence?
Another example given in the draft is operational interference: “Protocols that don’t require changes to other operational processes and tools are easier to deploy than ones that do.” Again, this might seem like a “no-brainer,” but, again — when was the last time you really thought about this when deciding which new protocol or design to deploy? In fact, how much do we hear about this when we’re discussing overlay technologies, and the management complexity they bring into the network, versus how often we just “toss the problem over the cubicle wall,” to the network management folks?
The Wild Success Factors in Section 2.2 are just as useful in network design as they are in protocol design — if not more so. Three “wild success factors” are also listed, including extensibility, no hard scaling bound, and sufficient mitigation of threats. Of course there are always going to be limits to extending and scaling a network design, and there are always going to be some threats that simply cannot be resolved or defended against.
Overall, though, RFC5218 provides a solid checklist with which to think about successful protocol design — and some good pointers for successful network design along the way.
I’m speaking on business drivers in a case study at Interop in just a few weeks! If you’re in town, I should be around the floor to talk about network design, the IETF, or just network stuff in general — look me up while you’re there.