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.

Congestion control prevents too much data from being injected into the network, which would cause router buffers to overflow and packets to be dropped. Unlike flow control (receiver protection), congestion control protects the network itself.

The tragedy of the commons:

If every sender transmits as fast as possible, network queues overflow, packets are dropped, senders retransmit, making congestion worse—congestion collapse. Early ARPANET suffered this in 1986, triggering Van Jacobson's landmark congestion control work for TCP.

Key concepts:

• Congestion window (cwnd): Sender-side limit on data in flight, based on network conditions (not receiver capacity)
• Effective window: min(rwnd, cwnd)—sender uses the smaller of receiver window and congestion window
• Congestion signals: Packet loss, delay increase, or explicit signals (ECN) indicate congestion

TCP congestion control phases:

1. Slow Start:

• Start cwnd = 1 MSS (Maximum Segment Size)
• For each ACK, cwnd += 1 MSS (doubles each RTT)
• Exponential growth until loss or threshold (ssthresh)

2. Congestion Avoidance:

• After reaching ssthresh, grow linearly: cwnd += 1/cwnd per ACK
• Roughly 1 MSS increase per RTT—AIMD (Additive Increase)
• Continue until loss detected

3. Fast Retransmit & Fast Recovery:

• 3 duplicate ACKs indicate loss (not just timeout)
• Retransmit lost segment immediately (don't wait for timeout)
• ssthresh = cwnd/2, cwnd = ssthresh + 3 MSS
• Multiplicative Decrease

4. Timeout:

• If RTO expires, assume severe congestion
• ssthresh = cwnd/2, cwnd = 1 MSS (back to slow start)

Multiplexing allows multiple communication streams to share a single lower-layer connection or channel. Demultiplexing is the reverse—delivering incoming data to the correct upper-layer recipient.

The multiplexing problem:

A single computer runs multiple applications—web browser, email client, SSH session, video stream. All share one network interface and one IP address. How does the OS know which incoming packet belongs to which application?

How TCP demultiplexes connections:

TCP identifies a connection by the 4-tuple: (source IP, source port, destination IP, destination port).

A web server listening on port 443 can handle thousands of simultaneous connections because each has a unique 4-tuple:

Even if the source IP and destination are identical, different source ports create distinct connections. The kernel's socket table maps incoming segments to the correct application based on the complete 4-tuple.

We've explored the fundamental building blocks from which all network protocols are constructed. These elements recur at every layer of the network stack, combined in different configurations to meet different requirements.

What's next:

Now that we understand the individual elements, we'll see how they're organized into layers in the protocol stack. The next page examines how protocols at different layers cooperate through well-defined interfaces, enabling the modular, extensible architecture that makes the Internet possible.