Why You Need to Know About Promise Theory

I encountered the term "promise theory" while learning about Cisco's Application Centric Infrastructure (ACI) and the associated Application Policy Infrastructure Controller (APIC). OK, time out! What is promise theory? I needed to do some research on this concept.

I quickly found a Wikipedia explanation, which led me to the information on Mark Burgess, a computer scientist who seems to be the author of the concept. Still, these pages didn't do much for educating me on the subject so I then watched Mark's promise theory Google TechTalk and read his blog.

Still feeling a little bit in the dark, I resumed researching Cisco's ACI while I let the new knowledge percolate in my brain. It finally started to make sense, probably due to some other things I read about ACI and APIC and the use of promise theory in their operations. A fundamental concept of promise theory is that it uses declarative control instead of imperative control.

Imperative Control
An imperative control system describes and executes each step of a process to achieve a desired result. For example, to apply quality-of-service (QoS) queuing definition to the core of a network, we would implement the following steps:

1. Define QoS queues and traffic rate limits.
2. Determine the set of non-edge switches and routers.
3. For each type of router or switch, determine the specific commands to implement the desired queuing with rate limits and add those commands to the device configuration. These configurations are very detailed descriptions of what the devices should do.
4. Optionally create a policy to verify that the desired QoS configuration remains unchanged so that we can find future exceptions to the desired configuration.

The important point of imperative control is that the system being controlled contains no intelligence. All the intelligence is in the control system. It is a centralized model, even when the individual devices being controlled are distributed.

Another interesting point is that if the commands are executed more than once by an imperative control system, a different final state may be created. For example, if control statements add configuration commands to an existing configuration, performing the same commands again may result in two copies of the commands in the configuration. Only through careful selection of the control statements can those control statements be executed more than once, with the end result being the same. In other words, the execution of the control statements may not be an idempotent operation, which is a repeatable operation well-known in the programming world. (Note: Network engineers will need to understand terms like "idempotent" to communicate with software-defined networking software developers.)

Declarative Control
A declarative control system communicates what should happen, not how it should be done. It is up to the endpoints to implement what the control system communicates. Following our QoS example, we have a very different control system.

1. Determine the QoS queues and rate limits. This is the same as what we saw with the imperative control system.
2. Communicate the queue structure and threshold limits to the devices that incorporate the QoS promises.
3. Each device changes its configuration to match the desired state.

The control system doesn't know what steps each device takes to achieve the desired configuration state. The devices simply implement the promises required to achieve the desired state. This control system is idempotent. It allows the control system to repeat the instructions more than once with the confidence that the final state will be the same. In the QoS example, a router or switch would promise to forward all traffic marked EF (Express Forwarding, DSCP 46) in the high-priority queue, up to the specified rate limits. The specific configuration commands needed to implement this configuration within the device are not known to the central control system.

How Does This Relate to Promise Theory?
Promise theory states that the devices promise to implement a desired state requested by the control system. So in the QoS example above, the devices in the declarative control system promise to implement the desired QoS queues and rate limits. The promises can be implemented either within the devices or within an interface layer that communicates with the device.

Another advantage of promise theory is that the configuration control is distributed. The implementations of the promises that a device can make are specific to that device. The central control system no longer has to be capable of configuring every different device. It simply issues the declarative commands and it is up to each device that supports the desired promises to implement them. If a device can't deliver on the promise, perhaps because limited internal resources are fully committed, then it would return an error to the controller.

The distributed nature of the promise theory implementation on each device is a significant advantage. It means that the configuration control system doesn't have to include the detailed configuration control elements for each device it may need to control. Instead, devices are distributed with the promise theory control function, either internally or as a small library added as an interface module in the control system.

Historically, we've had network management systems (NMS) shipped many months after vendors release devices. This is because the NMS vendor needed to add the imperative control system components for the new devices. But with promise theory, the device vendor can ship the promise theory control module with the device, implementing a known set of promises. This decouples device releases from NMS releases. What a splendid idea. Promises seem to be a good abstraction upon which to build.

Vendors are building real systems around promise theory. One of the first is CFEngine, which Mark created to manage configurations of Linux systems. It is exciting to see promise theory also being incorporated into networking systems such as Cisco's ACI and APIC.