Protocol Elements

Every network protocol—from the simplest acknowledgment scheme to the most sophisticated secure transport layer—is composed of a small set of fundamental building blocks. These elements recur across layers, technologies, and decades of protocol evolution.

Understanding these elements provides a powerful mental framework: when you encounter any new protocol, you can immediately recognize its components and understand how they work together. Instead of memorizing each protocol as an isolated entity, you see them as assemblies of familiar parts arranged in different configurations.

Addressing is the fundamental mechanism for identifying the source and destination of communication. Without addresses, messages would have no way to reach their intended recipients in a network of connected devices.

The addressing problem:

In a network with N nodes, how does Node A deliver data specifically to Node C, not to B, D, or E? The answer is to assign each node a unique identifier—an address—and include the destination address in every message.

Types of addresses in networking:

Address properties:

• Uniqueness: Addresses must be unique within their scope. MAC addresses are globally unique (assigned by manufacturers). IP addresses must be unique on a network (assigned by administrators or DHCP).

• Hierarchical vs. Flat: IP addresses are hierarchical (network portion + host portion), enabling efficient routing by aggregating routes. MAC addresses are flat—no inherent structure helps route them.

• Static vs. Dynamic: Some addresses are permanently assigned (burned-in MAC addresses), while others are dynamically assigned (DHCP-assigned IP addresses).

Addressing modes:

• Unicast: One source to one destination (most common)
• Broadcast: One source to all destinations on a network (255.255.255.255 in IPv4)
• Multicast: One source to a group of interested destinations (224.0.0.0/4 in IPv4)
• Anycast: One source to the nearest destination from a group (same address on multiple hosts)

Framing is the process of dividing a continuous stream of bits into discrete frames or packets—self-contained units of data with clear boundaries.

The framing problem:

Physical transmission media transmit continuous streams of bits. How does a receiver know where one message ends and another begins? How does it distinguish data bits from control information?

Framing techniques:

Frame components:

A typical frame contains several parts:

• Preamble/Start delimiter: Marks the beginning and allows clock synchronization
• Header: Contains control information—addresses, length, sequence numbers, flags
• Payload: The actual user data being transmitted
• Trailer: Contains error-detection codes (e.g., CRC) and possibly end delimiter

Why framing matters:

Without proper framing, a receiver cannot interpret the bit stream. It wouldn't know where addresses are, where data starts, or where frames end. Framing is so fundamental that protocols at every layer implement some form of it—Ethernet frames, IP packets, TCP segments, HTTP/2 frames.

Physical transmission media are imperfect. Electrical interference, cosmic rays, signal degradation, and component failures can flip bits during transmission. Error detection mechanisms allow receivers to identify when corruption has occurred.

The error detection problem:

A sender transmits 1000 bits. The receiver receives 1000 bits. How does it know if any bits changed during transmission?

Common error detection techniques:

CRC deep dive:

CRC is the gold standard for error detection in networking due to its excellent detection capabilities relative to overhead.

How CRC works:

1. Treat the data as a giant binary number (polynomial)
2. Divide by a fixed generator polynomial using XOR-based division
3. Append the remainder (the CRC value) to the data
4. Receiver divides received data (including CRC) by the same generator
5. If remainder is zero, no detected errors; if non-zero, errors occurred

CRC-32 detects:

• All single-bit errors
• All double-bit errors
• All odd numbers of bit errors
• All burst errors up to 32 bits
• Most longer burst errors (probability of missing ≈ 2^-32)

Error correction (or Forward Error Correction, FEC) enables receivers to not only detect errors but automatically repair them without retransmission. This is crucial when retransmission is impractical—satellite communications, real-time media streaming, or one-way broadcast.

The Hamming Distance Principle:

Error correction codes work by adding redundancy that increases the "distance" between valid codewords. If valid messages are far apart in Hamming distance, a few bit flips will land in the space between them, and the receiver can determine which valid codeword was intended.

Hamming distance = number of positions where two codewords differ

To detect d errors: need minimum Hamming distance of d + 1
To correct d errors: need minimum Hamming distance of 2d + 1

Hamming (7,4) Code Example:

The Hamming (7,4) code encodes 4 data bits into 7 bits (adding 3 parity bits). It can correct any single-bit error.

Bit positions: 1, 2, 3, 4, 5, 6, 7

• Positions 1, 2, 4 are parity bits (powers of 2)
• Positions 3, 5, 6, 7 are data bits

Each parity bit covers specific positions:

• P1 (position 1): covers positions with bit 0 set in binary (1, 3, 5, 7)
• P2 (position 2): covers positions with bit 1 set in binary (2, 3, 6, 7)
• P4 (position 4): covers positions with bit 2 set in binary (4, 5, 6, 7)

To find the error, the receiver computes syndrome bits—if a parity check fails, its position bit is 1. The syndrome value gives the position of the flipped bit!

In many networks, messages can arrive out of order, be duplicated, or be lost entirely. Sequencing mechanisms assign identifiers to messages that allow receivers to detect and handle these conditions.

The sequencing problem:

A sender transmits packets A, B, C in order. Due to different paths through the network or retransmissions, they might arrive as B, A, C, A, or just A, C. How does the receiver:

1. Detect that the order is wrong?
2. Reorder them correctly?
3. Detect duplicates?
4. Detect missing packets?

Sequence numbers:

The solution is to assign each packet a sequence number—a monotonically increasing identifier. The receiver tracks the expected next sequence number and can:

• Detect reordering: Receiving sequence 5 when expecting 4 means 4 is delayed or lost
• Reorder: Buffer out-of-order packets and deliver in sequence order when gaps fill
• Detect duplicates: Same sequence number received twice
• Detect loss: After timeout, missing sequence numbers indicate lost packets

Sequence number space:

Sequence numbers have finite bits and eventually wrap around. A 32-bit sequence number wraps after ~4 billion packets. The sequence number space must be larger than the maximum number of packets in flight at once; otherwise, ambiguity occurs.

TCP sequence numbers:

TCP uses 32-bit sequence numbers that count bytes, not packets. If a connection sends 1 TB of data, sequence numbers can wrap. TCP uses timestamps (PAWS—Protection Against Wrapped Sequences) to disambiguate.

Acknowledgment (ACK) is a message sent by a receiver to confirm that data has been received correctly. Combined with retransmission on timeout or negative acknowledgment (NAK), ACKs enable reliable delivery over unreliable channels.

The acknowledgment problem:

Sender transmits packet. Did it arrive? Without feedback, the sender doesn't know. Did the receiver process it? Did it get corrupted and dropped? The sender needs confirmation.

ACK strategies:

Timeout and retransmission:

How long should a sender wait for an ACK before concluding the packet was lost? This is the Retransmission Timeout (RTO) problem.

• Too short: Retransmit unnecessarily, wasting bandwidth and potentially causing congestion
• Too long: Waste time waiting when the packet was clearly lost

Adaptive RTO:

Modern protocols (like TCP) dynamically estimate RTO based on measured Round-Trip Time (RTT):

1. Measure RTT for each acknowledged packet
2. Maintain smoothed RTT estimate: SRTT = α × SRTT + (1-α) × measured_RTT
3. Maintain RTT variance estimate: RTTVAR = β × RTTVAR + (1-β) × |SRTT - measured_RTT|
4. Calculate RTO: RTO = SRTT + 4 × RTTVAR

This adapts to network conditions—faster retransmission on low-latency LANs, longer timeouts for transcontinental connections.

Flow control ensures that a fast sender doesn't overwhelm a slow receiver. It's a point-to-point mechanism between directly communicating peers.

The flow control problem:

A high-performance server can send data at 10 Gbps. A mobile phone on a congested WiFi connection can only receive at 50 Mbps. If the server blasts data at full speed, the receiver's buffers overflow and data is lost.

Flow control mechanisms:

TCP's sliding window in depth:

TCP implements flow control through the receive window (rwnd):

1. Receiver maintains a buffer to hold incoming data before the application reads it
2. Each ACK includes the advertised window—how many bytes the receiver can accept
3. Sender limits data in flight to min(rwnd, congestion_window)
4. As application reads data, buffer space frees, receiver advertises larger window
5. If receiver buffer fills (application not reading), advertised window drops to 0—zero window

Zero window situation:

When the receiver advertises window size 0, the sender must stop. But how does the sender know when to resume? TCP uses window probes—the sender periodically sends tiny segments to elicit an ACK with the current window size. When the window opens, transmission resumes.