Data Link Control

Data Link Control (DLC) is a set of services provided by the Data Link Layer (Layer 2) of the OSI Model. Its job is to turn a raw, error-prone physical link into a connection that two devices can use to exchange frames reliably and without stepping on each other.

Why Is Data Link Control Needed?

A physical link by itself guarantees almost nothing. Left unmanaged, several problems show up as soon as two or more devices try to communicate over it:

• Devices may try to transmit at the same time, corrupting each other's signals.
• A fast sender can overwhelm a slower receiver that can't process data as quickly as it arrives.
• Frames can be damaged or lost in transit due to noise, interference, or hardware issues.

Data Link Control addresses all three by:

• Coordinating which device gets to transmit and when.
• Regulating the speed of transmission to match what the receiver can handle.
• Detecting and correcting transmission errors in frames.

These three responsibilities map directly onto DLC's three main functions: Line Discipline, Flow Control, and Error Control.

1. Line Discipline

Line Discipline coordinates communication between devices sharing a link. It exists to answer two questions before any data moves:

• Which device can send data?
• When can it send data?

Without this coordination, two devices could transmit at the same moment, causing a collision and losing both transmissions. Two methods are commonly used: ENQ/ACK and Poll/Select.

ENQ/ACK Method

ENQ/ACK is used on a dedicated, point-to-point link between exactly two devices — there's no need to decide which device gets the link, only whether the receiver is ready right now.

How it works:

1. Sender sends ENQ. The sender transmits an ENQ (Enquiry) frame — in effect, asking "are you ready to receive data?"
2. Receiver responds. The receiver replies with either:
   • ACK — ready to receive, or
   • NACK — not ready.
3. Data transmission proceeds based on the reply:
   • If ACK: the sender transmits the data, and signals the end with an EOT (End of Transmission) frame.
   • If NACK: the sender holds off and tries again later.
   • If no response arrives at all: the sender assumes the ENQ itself was lost, and retries a limited number of times before giving up.

This maps closely onto a phone call: "Hello, can you hear me?" (ENQ) → "Yes, go ahead" (ACK) → the conversation (data) begins.

Poll/Select Method

Poll/Select is used in networks with multiple devices sharing a link, organized around one Primary Station that controls all communication and one or more Secondary Stations that only transmit or receive when the primary allows it — much like a classroom where the teacher (primary) decides who gets to speak, and students (secondaries) wait to be called on.

There are two distinct operations, depending on which direction data needs to flow.

**Select — the primary wants to send data:**

1. The primary sends a SEL (Select) frame containing the address of the intended secondary device.
2. That secondary responds with an ACK if it's ready to receive.
3. The primary sends the data.
4. The secondary acknowledges successful receipt.

(Analogy: "Student A, please listen." → "I'm ready." → the teacher provides the information.)

**Poll — the primary wants to receive data:**

1. The primary asks each secondary device, one at a time, whether it has data to send.
2. Each device responds with ACK (data available) or NACK (nothing to send).
3. Any device that responded ACK is then given a turn to transmit.

(Analogy: "Does anyone have a question?" — only students who respond get to speak next.)

2. Flow Control

Flow Control regulates the rate at which data moves from sender to receiver, so the sender never transmits faster than the receiver can actually process.

Why Flow Control Is Needed

Consider a sender capable of 100 Mbps talking to a receiver that can only process 10 Mbps. If the sender transmits at full speed regardless, the receiver's input buffer fills up faster than it can be drained, and once it's full, incoming data is simply dropped — not because the link failed, but because the receiver was never given a chance to keep up. Flow control exists to prevent exactly this mismatch.

Two techniques are used: Stop-and-Wait and Sliding Window.

Stop-and-Wait Flow Control

The sender transmits one frame, then waits for an acknowledgment before sending the next. This repeats, one frame at a time, until all data has been sent — much like sending parcels one at a time and waiting for a delivery confirmation before sending the next.

Sliding Window Flow Control

Sliding Window allows the sender to transmit several frames continuously before waiting for any acknowledgment, instead of pausing after every single one. A logical "window" defines how many frames can be outstanding (sent but not yet acknowledged) at once.

For example, with a window size of 4, the sender can transmit Frames 0, 1, 2, and 3 before it needs to wait for any acknowledgment. As acknowledgments arrive, the window slides forward — each ACK frees up room for one more new frame to be sent — which is where the technique gets its name.

This is similar to a courier company dispatching several parcels at once instead of sending one and waiting for its delivery confirmation before sending the next; as confirmations come back, more parcels go out.

Sender window tracks:

• Frames already sent.
• Frames sent but still awaiting acknowledgment.
• Frames not yet sent but ready to go.

Receiver window tracks:

• Which frames are expected next.
• Available buffer space.
• Whether frames are arriving in the correct sequence.

3. Error Control

Even on a well-managed link, frames can still arrive corrupted, out of order, or not at all. Error Control is the function responsible for catching these problems and ensuring the correct data ultimately gets delivered. Its objectives are to detect transmission errors, recover data that was lost, and retransmit damaged frames.

The core mechanism behind error control in data link protocols is ARQ (Automatic Repeat reQuest) — a scheme that relies on acknowledgments, negative acknowledgments, and timers to decide when a retransmission is needed.

Stop-and-Wait ARQ

This pairs the one-frame-at-a-time discipline of Stop-and-Wait with retransmission logic:

1. The sender transmits a frame.
2. The receiver checks it for errors.
3. The receiver replies with ACK if the frame was correct, or NAK if it was damaged.
4. The sender retransmits whenever a NAK (or no response at all) is received.

A timer backs this up: if no ACK arrives before the timer expires, the sender assumes the frame or its acknowledgment was lost and retransmits automatically, without waiting indefinitely.

Scenario — damaged frame:

1. Sender transmits Frame 0.
2. The frame is corrupted in transit.
3. Receiver detects the damage and sends a NAK.
4. Sender retransmits Frame 0.

Scenario — lost frame:

1. Sender transmits Frame 0.
2. The frame never reaches the receiver at all.
3. No ACK is ever sent, so none arrives.
4. The sender's timer expires.
5. Sender retransmits Frame 0.

Sliding Window ARQ

Sliding Window ARQ combines Flow Control's continuous transmission with Error Control's retransmission logic, so the link isn't forced back into a strict one-frame-at-a-time pattern just to handle errors. The sender keeps a copy of every frame it has transmitted but not yet had acknowledged, so that any of them can be resent if something goes wrong. Two common variants handle what gets retransmitted differently: Go-Back-N and Selective Reject.

Go-Back-N ARQ

If a frame is lost or damaged, the receiver rejects it — and, critically, also discards every frame that arrives after it, even if those later frames were received correctly. The sender must then retransmit the lost frame and everything that followed it.

Example: Frames 0, 1, 2, 3 are sent, and Frame 2 is damaged.

• Receiver accepts: 0, 1
• Receiver rejects (discards): 2, 3
• Sender retransmits: 2, 3 — even though 3 was originally received intact

Selective Reject ARQ

Selective Reject only retransmits the specific frame that was damaged or lost. Frames received correctly — even ones that arrive after a bad frame — are held in a receiver buffer rather than being thrown away, and are reassembled into the correct order once the missing frame finally arrives.

Example: Frames 0, 1, 2, 3 are sent, and Frame 2 is lost.

• Receiver buffers: 0, 1, 3
• Sender retransmits only: 2
• No need to resend Frames 0, 1, or 3

Choosing Between Go-Back-N and Selective Reject

The trade-off comes down to receiver complexity versus bandwidth efficiency. Go-Back-N keeps the receiver simple at the cost of resending data that didn't actually need it; Selective Reject uses bandwidth as efficiently as possible but requires the receiver to do more work — buffering, reordering, and tracking which frames have already arrived correctly. Protocols that expect frequent errors or operate over high-bandwidth, high-latency links (where resending unnecessary data is especially costly) tend to favor Selective Reject; simpler or more error-free links can get away with Go-Back-N's simplicity.