Protocols: Seeing Clearly

In “The Elements of Style”, Strunk and White didn’t mince their words. They called the lack of clarity in writing as “a destroyer of life, of hope.” The same is true with the lack of clarity in protocols and their specifications.

Clarity is the fourth attribute I look for in a good protocol.

There are two aspects to that clarity. The first is the clarity of the specification, the narrative that defines the protocol. The specification is sometimes the work of very smart people, who have never learned the art of communication with words.

Communicating with words is a different art form than programming a machine. I often have trouble talking with people after long stints of coding. Forming my words and composing groups of words into sentences to create ideas, and then to group these sentences into units to communicate what I’m trying to say can become difficult. It is as if I were in a different mode of thought.

Sometimes I think technical people have neglected the development of verbal communication skills. They can be very skilled at programming and other aspects of design, but not very good at translating those ideas into the words that convey that design.

Sometimes reading a protocol specification and reforming the author’s ideas in my mind requires more work than one would think necessary. Once done, however, the author’s ideas are then clear in my mind.

Having said that, I usually find when reading a specification that’s fumbling and searching for the right words in obvious frustration, like a stroke patient with Fluent Aphasia, I almost always find an equally confused protocol.

All technology is an imprint of ideas. Some ideas are clear, clean, well thought out. They have easily-understood concepts. They are usually the product of step-wise refinement, of iterative development before the protocol settles out.

But other ideas can be vague, misty, like something you think you see out of the corner of your eye, only to have the image vanish as soon as you try to look at it. Just like the words that describe it, protocol concepts can leave more questions than answers.

This results in multiple interpretations of both the meaning and operation, resulting in ambiguousness in the protocol.

Ambiguity is death in networking.

Good ideas demonstrate their clarity by being obvious. The uninitiated might even think the brilliant idea is actually trivial. They think “of course, one would do it that way.” Yet one wonders why it took 6,000 years of human history before someone thought of the “obvious.”

If the ideas in the protocol are clear, then the written word can be clear. If the protocol is a mess, so will be its description.

An example of a good protocol, both the protocol ideas and its description, is TCP. Its original description in RFC 793 (Request for Comment), written by Jon Postel, describes the protocol in only 77 pages. Every minute of every day, civilization depends on thousands of TCP implementations seamlessly working together. The fact that it works is a tribute to Vint Cerf and Bob Kahn, who invented TCP/IP, and Postel for describing it so well.

The description is only 77 pages, yet the protocol it describes has all the features needed in a transmission control protocol. It assures bytes sent from one end arrive at the other in correct order, un-duplicated, with flow control.

The concepts in TCP are sophisticated, yet clear. There are only five 32-bit words in the header.

Just one example is the idea that each byte transmitted has an associated sequence number. This provides an easy way to regroup bytes during the transmission, yet makes sure all bytes arrive in the right order. Resending a missing chunk can, for example, include new bytes not yet sent and still work. It is a clean, clear idea described in a clean, clear way.

That is just one of the good concepts in TCP. The quantity and quality of other ideas are equally impressive.

There is quality in this design because it was invented by only two people: Vent Cerf and Robert Kahn. Two’s about the limit for any really good technology. But the clarity of language in the RFC was the work of Jon Postel.

Jon was the RFC editor from 1969 until his death in 1998 from heart surgery. His clarity of language is certainly missed, I can tell you.

My favorite Postel quote is “Group discussion is very valuable; group drafting is less productive.”

The modern internet is very much the product of the clear thinking and writing of Cerf, Kahn, Postel, and others.

Their clarity of thought is inspiring.