Protocols: Mechanism and Policy

In the previous posts of this series, we learned that a communication protocol is often implemented as a finite state machine we can call a protocol machine (PM). A PM has four types of interactions: one with the peer PM in a remote system, two with PMs in the upper and lower layers, and one with the operation system. All these interactions are considered procedure calls that update the state of the PM. The protocol data unit (PDU) exchanged with the remote PM is considered a procedure call with the header, trailer, and the payload are the parameters. The PM interactions with the PM in the same system are via service data units (SDUs).

In his book (Day 2008), John Day argues that a protocol implementation can be split into mechanisms and policies.

The concepts of mechanism and policy are well known in operating systems. Policies determine what needs to be done; mechanisms determine how to do it. For example, granting a resource to a process using first come first serve algorithm is a policy. This policy can be implemented using a queue mechanism. Separating policy from mechanism is a design principle that ensures flexibility.

In protocols, mechanisms are the static, unchangeable functions or procedures that are defined by a protocol. Once a protocol is specified, its mechanisms are fixed and remain constant. For example, a protocol may specify a mechanism for detecting errors using a particular type of error-detecting algorithm (e.g., CRC).

Policies, on the other hand, dictate how and when a mechanism should be used. Policies can vary and are more dynamic. They can be adjusted based on the specific conditions or requirements of the communication. For instance, in data error detection, the policy would determine when the error-detection algorithm is applied, such as how frequently checks are made or under what conditions.

Mechanisms form the core functions that are needed to meet the basic requirements of the protocol. Example mechanisms include error control, flow control, or acknowledgment processes. These mechanisms are necessary to ensure the protocol operates effectively within its intended environment.

Policies are applied to these mechanisms to tailor the protocol’s behavior to specific situations or needs. For instance, a sliding-window flow-control mechanism could have different policies that control how and when new credits are granted to a sender. These policies could range from extending credit every time a PDU is received to extending credit only under certain conditions, such as after a timeout.

Typically, for each sending policy, there is a corresponding receiving policy , see the figure below. For instance, if the sending policy is to compute a CRC and attach it to a PDU, the receiving policy is to compute the CRC upon receiving the PDU and compare it with the attached value. This coordination ensures that mechanisms function correctly across both ends of a communication link.

A single PDU may contain fields for several different mechanisms. This means that a PDU could carry information relevant to error control, flow control, and other processes, all of which are interpreted according to the policies in place.

The ability to change policies allows a protocol to adapt to different conditions without needing to change its core mechanisms. The frequency of sending acknowledgments, for example, can be adjusted based on the network conditions, which might not require strict synchronization with the data stream.

Protocols may include mechanisms for negotiating policies during the establishment of a connection. This negotiation can set parameters for how data will be exchanged and how various mechanisms will be applied during the communication session. However, changing policies mid-stream can introduce complexity, especially if it requires synchronization similar to establishing a new flow.

By clearly separating mechanism and policy, protocols can be optimized for different environments without needing to redesign their core functions. This flexibility can reduce the need for multiple protocols and make it easier to understand and manage the different policies in use.

For instance, instead of creating a new protocol to handle the small number of packet drops in voice data streams, we can alter the acknowledgment policy of an existing protocol to send an acknowledgment even if not all data has been received. The existing protocol can be adapted to meet the needs of voice communication without requiring new mechanisms. This change in policy requires the reinterpretation of acknowledgments form confirming receipt of data, to mean that retransmission is not required. This new interpretation shifts the focus of acknowledgements from strict data verification to maintaining the flow of communication.

Common Mechanisms

Here’s a list of some of the common protocol mechanisms :

• Delimiting: Marks the start and end of a PDU, either externally, using flags, or internally, with a length field.
• Connection Establishment: Establishes shared state before data transfer, using handshakes (two-way, three-way, or timer-based).
• Multiplexing: Maps multiple higher-layer flows onto fewer lower-layer flows, combining PDUs from different sources.
• Ordering: Ensures PDUs arrive in the correct order using sequence numbers.
• Lost and Duplicate Detection: Detects and handles lost or duplicated PDUs using sequence numbers.
• Flow Control: Manages data transmission rate to prevent overloading the receiver.
• Activity Detection: Maintains connection during long inactivity periods through keepalive signals.
• Security Mechanisms: Maintain confidentially and integrity of data.

Types of Mechanisms

A protocol mechanism is a function of certain fields of the protocol control information (PCI) and state variables of the PM. Manipulation of these fields results in changes to the state of PM, which is convey to peer PM in one ore more PDUs. Certain fields within the PCI are used to specify mechanisms. These fields are split into two categories:

• Tightly bound fields, which must be directly associated with the user data (i.e., they must be part of the Transfer PDU). Examples include a sequence number field that is used for ordering packets, and Cyclic Redundancy Check (CRC) field used for detecting corrupted data.
• Loosely bound fields, which do not need to be associated with the user data, the Transfer PDU, and may be used for purposes like synchronization, flow control, or acknowledgments.

The type of fields used results in two types of mechanisms:

• Tightly Coupled Mechanisms: These are mechanisms that operate solely based on tightly bound fields, such as mechanisms related to ensuring data is received in the correct order or that it has not been corrupted.
• Loosely Coupled Mechanisms: These mechanisms depend on at least one loosely bound field. They might include operations for managing the flow of data or ensuring proper synchronization between systems, which do not require being directly tied to the user data.

Some protocols, like TCP, use a single PDU type that includes all PCI in every PDU, making it simpler but potentially less efficient. Other protocols, like SCTP, use multiple PDU types that carry user data and control information separately.

References

1. J. Day, Patterns in network architecture: A return to fundamentals. 2008.