Data Link Layer

Quiz
What is the role of the data link layer?

A. Routing Packets
B. Next hop delivery
C. Encoding
D. Supporting processes
1. Framing Techniques
2. Error Control
Byte Oriented Protocol
Bit Oriented Protocol
 Data Link Layer:
Reliable Data Transfer
 Outline Sending
Process
Receiving
Process

● Develop a Reliable Data Data

Data Transfer protocol

(RDT) a) Service

Sending Receiving
– Unreliable channel with bit Process Process

errors Data Data

Sending Receiving

– Unreliable channel with bit side

RDT
side
RDT
errors and losses
Data Data

b) Implementation
 Automatic Repeat Request (ARQ)

Using acknowledgements and timeouts to

implement reliable delivery is sometimes called
Automatic Repeat Request
 RDTv1.0: Channel with bit errors
● Telephone Analogy Required Functionality:

● Receiver Feedback • Error Detection

mechanism
– Positive: aha, ok, hmm  ACK

– Negative: repeat that, didn‟t – Checksum, CRC etc

follow, what did you say? 
NACK ● ?

– Do we need both?

● Sender retransmits on NACK

 RDTv1.0: Channel with bit errors
● Protocols based on Required Functionality:
Feedback and
retransmissions ● Error Detection
mechanism

Packet Packet
– Checksum, CRC etc
ACK NACK
● Receiver Feedback
Next Packet Same Packet

– ACK + NACK

RDTv1.0
 RDTv1.0 has a fatal flaw!
● What if the ACK/NACK
got corrupted? Required Functionality:

● Error Detection
– What should sender do then?
mechanism
● Send next packet? If prev.
pkt is lost, RDT not – Checksum, CRC etc
providing reliability
● Receiver Feedback
● Send previous packet? If
prev. pkt is not lost, creates – ACK + NACK
duplicates
 RDTv2.0
• Receiver gives feedback Required Functionality:
(ACK, NACK)
● Error Detection
• Sender retransmits mechanism
"sequenced" packet on
NACK, garbled
– Checksum, CRC etc
ACK/NACK
● Receiver Feedback
• Receiver discards
– ACK + NACK
duplicates if any based
on sequence number – Data Sequence Numbers
 RDTv2.0

● What is the sequence number space?

– Just two seq #s “0 , 1” will suffice

Packet0 Packet0 Packet0 Packet0

ACK NACK NACK

ACK

Packet1 Packet0 Packet0 Packet0

Duplicate Rx accepts
Rx discards
 RDTv2.1
● Optimization: NACK free operation

– Convey same information as NACK but through ACK.

How?

● Instead of NACK, receiver sends ACK of last

correctly received packet

– Receiver must explicitly include seq # of packet being

ACKed

● Duplicate ACK at sender results in same action as

NACK: retransmit current packet
 RDTv2.1
Required Functionality:

● Error Detection mechanism

– Checksum, CRC etc

● Receiver Feedback

– ACK + NACK

– Data Sequence Numbers

– ACK carries sequence number of data packets

 RDT: Channel with Errors and Losses

● Will RDTv2.1 work? Packet0

● Sender gets no feedback: Need a

Timeout mechanism
Packet0

● How long to wait?

Ack0
 RDTv3.0
● Sender waits Required Functionality:
“Reasonable” amount of
time for ACK ● Error Detection mechanism

– Checksum, CRC etc

– Retransmits if no ACK
received in this time ● Receiver Feedback

● If pkt (or ACK) just – ACK + NACK

delayed (not lost)
– Data Sequence Numbers
– Retransmission will be
duplicate, seq. #'s help – ACK carries data seq. No.
resolve this
– Timeout Timer
RDTv3.0: Stop and Wait Protocol
In Action
Packet0
Packet0

ACK0

Packet1 Timeout Packet0

ACK1
ACK0

(a) No Loss
(b) Lost Packet

Also called Alternating Bit Protocol

 RDTv3.0: Stop and Wait Protocol
In Action Packet0

Packet0 ACK0

Packet0
ACK0 Timeout

Timeout
Packet0
Duplicate Packet Packet1
Discard Packet
ACK0 Send ACK

(c) Lost ACK

(d) Premature Timeout

or delayed ACK
 RDTv3.0: Stop and Wait Protocol
In Action Packet0

Packet0 ACK0

Packet0
ACK0 Timeout

Duplicate Packet
Timeout
Packet0 ACK0 Discard Packet
Send ACK
Duplicate Packet Packet1
Discard Packet
ACK0 Send ACK Duplicate ACK,
Retransmit Packet1
Packet1
ACK1

(c) Lost ACK

(d) Premature Timeout

 RDTv3.0: Stop and Wait Protocol
In Action Packet0

Packet0 ACK0

Packet0
ACK0 Timeout

Duplicate Packet
Timeout
Packet0 ACK0 Discard Packet
Send ACK
Duplicate Packet Packet1
Discard Packet
ACK0 Send ACK Duplicate ACK,
Retransmit Packet1
Packet1
ACK1

(c) Lost ACK

Sorcerer's
Apprentice Bug
(d) Premature Timeout
 RDTv3.0: Stop and Wait Protocol
In Action Packet0

Packet0 ACK0

Packet0
ACK0 Timeout

Duplicate Packet
Timeout
Packet0 ACK0 Discard Packet
Send ACK
Duplicate Packet Packet1
Discard Packet
ACK0 Send ACK Duplicate ACK,
Ignore, Do nothing
ACK1

(c) Lost ACK

(d) Premature Timeout

 Design of RDT protoc ols

● Many challenges to handle

– ACKs/Packet loss, ACKs/Packet delayed,

Duplication of packets, Reordering, Incorrect
timeout timer settings, Receiver capabilities

– Protocol has to work correctly and efficiently in

spite of all this
 NACK vs ACK

• Can conclude packet loss on detecting "holes"

– Long delay between some packets can slow down

recovery

– What if the last packet in the flow is lost?

• Receiver doesn't generate NACK,
• sender assume "all is well"

• Advantage of NACK: If errors are infrequent, reduces

overhead of feedback
 P erforma nc e of S top a nd Wait P rotoc ol

● What is the achieved throughput?

– 10 Mbps link, 10 ms prop. delay, 1KB packet,

ACK too small (ignore its Transmission time)

7
● Throughput: 8000 bits / [(8000/10 ) + 2*0.010]
= 384.6Kbps

● Utilization = 384.6kbps/10000kbps = 3.8%

 1
Sender Receiver 𝑈 =
1 + 2𝑎
TX Time
Packet0 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑡𝑖𝑜𝑛 𝑑𝑎𝑙𝑎𝑦
𝑎 =
𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑠𝑠𝑖𝑜𝑛 𝑑𝑎𝑙𝑎𝑦

RTT

ACK0 • a <<< 1 Tx >>> PD more utilization

Packet1
Sender Receiver
• a >>>1 Tx <<< PD less utilization

Sender Receiver
 Performance of Stop and Wait Protocol

• At a time only one outstanding frame on the link at a time.

• for eg. : A 1.5 Mbps link with a 45-ms RTT. i.e the link has (delay
x bandwidth) product of 67.5Kb or 8 KB. Since the sender can
send only one frame per RTT and assume frame size is 1 KB, this
implies a maximum sending rate of

• Throughput = Bits Per Frame / Time per frame

= 1024 x 8 /0.045
= 182 kbps
1/8th of the link capacity 182000 / 1500000 = 12.14 %
 Summary
● The current protocol design is inefficient.

● Reliable data transfer protocols provide reliable channel'

service abstraction to higher layers.

● We incrementally determined the required functionality

needed in RDT protocols.

● Future: Build on this framework to design better

protocols.
 Data Link Layer:
Sliding Window Protocols
 Sender General Idea
Receiver
TX Time
P0 Sender Receiver
P1
P2 Ack0 TX Time
P3 Ack1
P4 Ack2 P0
RTT
Ack3
Ack4
RTT
Ack0

P5 Ack5
Utilization = P1
P6 Ack6 Utilization = TX
5*TX time / P7 Ack7 time / (TX time
(TX time + P8 Ack8 + RTT)
RTT) P9 Ack9

Eg: 3.8%
b) Stop and Wait
Eg: 19% a) Sliding Window
 Performance of Stop and Wait Protocol

● What is the achieved throughput?

– 10 Mbps link, 10 ms prop. delay, 1KB packet, U = 1 /(1 + 2a)

ACK too small (ignore its Transmission time)

7
● Throughput: 8000 bits / [(8000/10 ) + 2*0.010]
= 384.6Kbps

● Utilization = 384.6kbps/10000kbps = 3.8%

Utilization = TX time / (TX time+ RTT)

= (0.0008) / ( 0.0008 + 0.02 )
= 3.8%
 Bandwidth-Delay Product
● Sender can send a maximum of W packets (window
size) without waiting for anACK
● What can the window size be?
– To keep utilization maximum, sender can send
"roughly"upto Data-Rate*RTT before hearing an ACK
– Window size =Bandwidth * RTT bits - (to maintain equilibrium )
● Divide by packet size to get the number of packets
 Sliding Window
● At any given time, no more than W packets can be
outstanding (their status not known at sender)
● As status of packets gets known at sender, the window
of sequence number slides to encompass newer
sequence numbers
– Permits sender to send subsequent packets
 Sender Side
● Assign a sequence number to each frame
● Maintain 3 variables:
– Send Window Size (SWS): upper bound on number of outstandingframes
– LAR: Seq. No of Last Acknowledgment Received;Advance LAR when
ACK arrives
– LFS: Sequence number of Last Frame Sent

● Maintain Invariant: LFS-LAR <= SWS

LAR LFS Can send but not yet sent

Sent, Not yetAcked

AlreadyAcked Can‟tsend
SWS
 Receiver Side
● Maintains the following three variables
– Received Window Size (RWS): upper bound on the number of
out of order frames
– LAF denotes sequence number of last acceptable frame
– LFR denotes sequence number of last frame received
● Set LAF = LFR + RWS

LFR Out of order buffered packets LAF

LAF Not acceptable, discarded

In order, Passed up
Expected, Hole RWS Acceptable, within window
 Consequences
● Need a range of sequence numbers (two won’t suffice)

● Sender has to buffer more than one frame (buffer all

• transmitted but not yet acked)
● Receiver may also have to buffer (out of order frames)
● Range of protocols based on sliding window
– Go Back N, Selective Repeat, TCP
– Actions taken on events (like frame/ack rcvd, duplicate ack,
timeout etc) differ
 Action at the sender
● On receiving a packet from higher layer:
– Send the packet or buffer it or discard it?
● On receivingACK:
– Send packet?
– If so, which one?
● Timeout: Retransmit packet, update timer
 Action at Receiver
● On receiving a packet:
– Should I accept it or discard?
– Whether accepted or not, should I generate ACK?
– If ACK generated, what should I acknowledge in
it?
 Receiver Side Details
● Frame “SeqNum” arrives
– If SeqNum <= LFR or SeqNum > LAF, discard frame
– If LFR< SeqNum <= LAF, accept

● Always good to send an ACK (improves performance by

early detection of losses)
– Exception: depends on protocol (e.g. Go-Back-N doesn't send Ack when
frames are discarded)

● Types of ACK: Cumulative Ack; SelectiveACK

– Tradeoff: Simplicity vs Performance
 Cumulative ACK at receiver
● SeqNumToAck
– Largest sequence number received such that all
frames with sequence number less than
SeqNumToAck have also been received
– LFR is set to this value
 Example
● Frames 0,1,2,3,5,7 arrive in that order
● State: Receiver acked frame 3, assume RWS is 4
– When 5 arrives: Buffer 5, ack 3, LFR=3, LAF=7
– When 7 arrives, Buffer 7, ack 3, LFR=3, LAF=7
– When 4 arrives (say due to sender retransmission), it fills the
hole,
● Accept 4 and pass up packets till 5, ack 5, LFR=5, LAF=9
– When 6 arrives, accept/pass up, ack 7, LFR=7, LAF=11
 Selective ACK at receiver
● For out of order packets: ACK sequence number of
whatever packet accepted
● In previous example:
– When 5 arrives, ack 3, sack 5
– When 7 arrives, ack 3, sack 7 5
– When 4 arrives, ack 5, sack 7
– When 6 arrives, ack 7
 Sender Side Details
● On receiving packet from higher layers:
● On receiving ACK from receiver:
 Sender Side Details
● On receiving packet from higher layers:
– Determine next sequence number to use (SeqNum)
– If SeqNum – LAR <= SWS, send the packet, else buffer or
inform application
 Sender Side Details

● On receiving ACK: action function of ACK type

– Can get very complex (e.g. TCP variants)
– Duplicate Acks and Selective acks can be used to determine
packet loss, which in turn trigger retransmission
● Timeout is a backup mechanism
– Simple Version: Use cumulative ack to advance window
● If SeqNum in ACK > LAR, LAR = SeqNum in ACK
● If SeqNum of Buffered packets <= LAR+SWS, send them
 Sequence Number Space
● How many sequence numbers do you need?
● Suppose RWS = 1, SWS = 3
– Maxseqno = 4 i.e. 0,1,2, 3?
• RWS > SWS
● Suppose RWS=SWS=3 • RWS<=SWS
• RWS = 1
– Maxseqno=4 sufficient?
● What is the general rule?
 Sliding Window Protocols

• Examples:
•
• 1. Simple - Sliding Window Protocol
• 2. Go Back N - Sliding Window Protocol
• 3. Selective Repeat - Sliding Window Protocol
 Utilization of Sliding Window Protocol

• U = 1 W > (1 + 2a)

• W/(1 +2a) W<(2a+1)

• Where W – Window Size