What Makes A Good Protocol Design?

What makes a good protocol design?

Not all protocols are equal. I’ve worked with good ones and bad ones. One of the worst was a protocol accidently defined to control parameters on a DS3/DS1 cross-connect switch. The hardware engineers didn’t know they were designing a protocol and made quite a mess.

I was able to easily clean it up with a new protocol. The engineers seemed to be very happy to have someone worrying about it, and equally happy to rewrite the code they had written to use my new protocol.

For a network protocol to be well designed, it must have five attributes: Focus, Unity, Simplicity, Clarity, and Generality. Notice that all the attributes imply a scale. One knows if something has focus or not. The more of each, the better.

The first thing I look for is Focus.

Focus is the characteristic of designers being narrowly mindful of their mission. Narrowing down the scope of what the protocol should be doing is key. A good network protocol has very clear objectives, is designed to serve those objectives, and avoids doing things that distract from those objectives.

Sometimes this means there should be two protocols.

The two most used protocols in the universe are TCP and its ever present companion, IP. TCP, as you almost certinaly know, is the protcol that forms the connections of the Internet.

TCP provides reliable, in-order, unduplicated transfer of bytes, being careful not to overrun a slow reader. That last bit is called flow-control. The 20-byte TCP header and the protocol design are very focused on this objective. The list constitutes the minimum requirements to have a reliable byte-pipe between hosts across the Internet.

The IP protocol, on the other hand, provides the mechanism to carry those TCP segments across the Internet. It has to provide a way of addressing the remote host in a way that is independent of underlying network technology. IP can work on anything from Ethernet to a pair of tomato cans and some string.

(I’ve always wanted to implement a network segment using a tin can and string modem, and put it on the Internet. Maybe some day.)

To do this, the inventors of IP designed an addressing scheme that could pass datagrams to the next hop in a path to the ultimate destination. The addressing scheme recognized that a portion of the host address was the identity of the network it was on, as well as which node on that network. All it had to do was pass the datagram to that network.

A series of machines between TCP endpoints pass these datagrams along. Originally, these machines were timesharing hosts running Unix, TOPS-10, DEC VMS, and so forth. But soon enough someone had the idea of a specialized computer, an appliance, to pass the datagrams instead of bogging down the hosts with all this network traffic.

We called it a router.

What does all this have to do with Focus?

Well, at first these were not two protocols, but one. No one had yet organized a way of thinking about networking, especially internetworking, by dividing it into layers. The original team tried to design a single protocol to do both the transport and the internetworking.

This was too much for a single protocol. Eventually it occured to them that they were actually two protocols working together. The TCP part just used the IP part to try to deliver the TCP segments. If IP didn’t get through, the segment would be resent.

This change of thinking allowed the IP part to focus on the data link layers between nodes, and the TCP to ignore those issues.

The speparation allowed for each part to focus on what it needed to do.

Notice that IP doesn’t exchange routing information. That’s not it’s focus. Other protocols do that job.

I focus on specific objectives with the protocols I design. ATA-over-Ethernet (AoE) was designed to add devices that look like disks to Linux, Windows, and VMware servers. It’s job is to connect a disk to a server. That way we can have as much storage on a server as we want, and we can easily bring up a disk on a different server if we need to.

To do that, we created a protocol that does only four things. It discovers and claims AoE targets, passes SATA commands to the targets, fences off and hides targets from other servers, and it can reserve targets.

All very focused. That’s why the spec is only about six typeset pages.