Protocols: Data Units

The previous post of this series describes four types of interactions a protocol can have. One of these interactions is with a peer protocol. To exchange its state information with the peer, the protocol uses Protocol Data Units (PDUs). A PDU is essentially a block of information, which may be referred to by various names (e.g., frame, packet, segment) by various protocols.

PDU Components

A typical PDU consists of:

• Header: Contains protocol control information (PCI) necessary for the protocol machine (PM) to coordinate communication. The header typically contains fixed-length fields for easier processing. Headers include essential details like the length of the PDU, protocol identifiers, and instructions for processing the user data.

• User Data: The actual data being transmitted, which the PM doesn’t need to understand—it’s simply passed along to the relevant application or protocol above.

• Trailer: Sometimes used to carry additional control information. Trailers are less common in higher-level protocols but are used in some cases to carry information that can’t be determined until after the header and user data are processed, such as cyclic redundancy check (CRC), or integrity check.

How Many PDUs?

The design of a protocol’s PDUs involves balancing simplicity, efficiency, flexibility, and the specific needs of the network environment. The number and type of PDUs are key decisions that can significantly impact the protocol’s performance and adaptability.

In any protocol, there must be at least one type of PDU responsible for carrying the user’s data. While only one PDU type is strictly necessary, protocols can have multiple PDU types for some design considerations, such as minimizing bandwidth overhead or processing time. Other advantages of multiple PDU types include:

• Enabling asynchronous and parallel processing, which can improve the efficiency of the protocol.
• Facilitating adding or removing functionality while maintaining backward compatibility with older versions of the protocol.
• Reducing overhead by allowing optional mechanisms to be included in the protocol, without forcing all PDUs to include unused elements (fields).

Separating control information from data leads to different types of PDUs. This prevents overloading a single PDU with too many functions, which can make the protocol more complex and less efficient. TCP is an example of a protocol that has one PDU type. Due to the use of various flags in the TCP header (SYN, ACK, FIN, etc.), some implementations treat each flag as a different PDU type to simplify handling the PDUs. The SNMPv3, on the other hand, has seven PDU types, each is used for a distinct purpose.

PDU Size

The size of PDUs is a critical design factor in protocols. The choice of PDU size has a direct impact on processing efficiency, bandwidth utilization, and overall network performance.

Factors favoring larger PDUs:

• Processing Overhead: The overhead associated with processing a PDU is largely dependent on the Protocol Control Information (PCI) contained within it. The length of the PCI, which includes elements such as addresses, sequence numbers, and control flags, dictates the processing effort required. While the overhead is tied to the PCI length, it is generally independent of the overall length of the PDU (i.e., the combination of PCI and user data). This means that once the PCI is processed, the size of the user data doesn’t significantly add to the processing time.
• Processing Efficiency: To maximize efficiency, PDUs should be as long as possible, meaning that the user data should be maximized relative to the PCI. A larger PDU with more user data and the same PCI length reduces the relative overhead and increases the overall processing efficiency.
• Bandwidth Efficiency: Similarly, larger PDUs are more bandwidth-efficient. With more user data per PDU, the network transmits a higher volume of useful information relative to the overhead.

Factors favoring smaller PDUs:

• Application Data Size: The amount of data that is significant to the application may be small, meaning that generating large PDUs is unnecessary or even wasteful.
• Buffering Constraints: Systems may have limited buffering capacity, making it impractical to handle large PDUs.
• Fairness (Interleaving PDUs): To ensure fairness in a network, smaller PDUs may be preferred to allow multiple flows to be interleaved more effectively, preventing any single flow from dominating the bandwidth.
• Error Characteristics: In environments with a high likelihood of transmission errors (e.g., wireless networks), smaller PDUs are preferable. Smaller PDUs reduce the time window in which errors can occur, lowering the risk of having to retransmit large amounts of data.

In addition to the above, each protocol may have an optimal PDU size range depends on which layer it operates:

• For upper-layer protocols, PDU size is heavily influenced by the application’s needs. The logical structure and significance of the data at the application level often dictate the boundaries for PDU size.
• In the middle layers, PDU size is moderated by system constraints, such as the operating system and multiplexing requirements.
• At the lower layers, PDU size is more directly influenced by the characteristics of the underlying media. For instance, in a wireless network with higher error rates, smaller PDUs are used to minimize the impact of errors.

References

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