chapter 2 designing reliable protocols professor rick han university of colorado at boulder...

Chapter 2Designing Reliable Protocols

Professor Rick HanUniversity of Colorado at Boulder

[email protected]

Prof. Rick Han, University of Colorado at Boulder

Announcements• Moved to ECCR 265• Larger classroom => graduate students

on wait list may take the class• If not enough textbooks, send me email• First two lectures are online• TA has posted office hours and office on

Web site• Homework #1 is on the Web site, due in

2 weeks• Programming assignment #1 available

next class• Next, Chapter 2, reliable data-link

protocols


Recap of Previous Lecture

Layer 1

Layer 2

Host A1011000

1011000

• Physical Layer• Encoding bits as

analog waveforms, …

• Ways to increase bit rate

• Unreliability and propagation delay

• Data Link Layer• Framing via byte/bit

stuffing and length field in header

• Error detection and correction


Reliable Protocols• Why aren’t error detection and correction

enough?• Receiver drops a packet when errors detected• Receiver can’t correct errors in some packets• Receiver never receives a packet

• Solution: Retransmit lost or corrupt packets• Also called ARQ (Acknowledgement-Repeat-

Request) Protocols• Useful for communicating non-delay-sensitive

data, e.g. Web pages, files, email, even playback video

• Can incur too much delay for interactive audio/video


Reliable Protocols (2)• How does sender detect when a packet

needs to be retransmitted?• Analogy: Send a package by mail. How do I

know it got there? Certified mail sends back a receipt.

• In reliable protocols, Acknowledgements are sent by receiver back to sender confirming receipt of a packet

• When an acknowledgment doesn’t arrive, then retransmit

Sender Receiver

1011000#5

…Got #5


Reliable Protocols (3)• The sender knows that packet #5 was

received correctly when it gets acknowledgement #5

• How does receiver know that sender got its acknowledgment?• Sender increments sequence number to #6

when acknowledgement #5 arrives. When receiver sees packet #6, it knows acknowledgement #5 made it

Sender Receiver

0100110#6

…Got #6


Reliable Protocols (4)• If the acknowledgement gets lost on the

way back to sender, how does sender know it’s lost?

• If an acknowledgement for a packet is not received by a timeout value, then sender assumes the packet is lost & retransmits it

Sender Receiver

1011000#5

…Got #5


Reliable Protocols Thus Far• To detect when a packet needs to be

retransmitted, reliable/ARQ protocols must use both:• Acknowledgements, and• Timeouts,

• Sequence numbers:• Sender labels packets with them• For certain protocols, a receiver can infer

correct reception of the acknowledgement for a packet with a lower sequence number


Reliable Protocols: Other Points

• Feedback loop allows receiver to send info about its state back to sender• Which acknowledgements have been received• Amount of room in my receive buffer (flow

control)

• Retransmission can work in conjunction with error detection/correction• Each packet has CRC/checksum. At receiver, if

calculated checksum doesn’t match packet’s checksum, then discard packet.

• Alternative policy? Receiver caches noisy packet for future error correction!

• Retransmission can occur both at link layer and transport layer


ACK’s and NAK’s• Types of Acknowledgments

• ACK’s – positive acknowledgements = “I’ve received these packets”• Cumulative• Selective

• NAK’s – negative acknowledgements = “I have not received these packets”

• ACK’s are more prevalent than NAK’s

Sender Receiver

0100110#6

…Got #6

…Got <#7


Timeouts• How would you choose the value of a

timeout?• If timeout is too long, then waste bandwidth

and send slowly.• “Too long” means timeout >> roundtrip time • Let’s approximate roundtrip time RTT =

2*(propagation delay), “>>” means “much greater than”

• Example: if satellite link has prop. delay of 120 ms each way, then RTT = 240 ms. If timeout=1 min >> 240 ms, then send too slowly.

• If timeout is too short, then retransmit unnecessarily• “Too short” means timeout < roundtrip time• Example: if timeout = 1 ms < RTT = 240 ms, then

retransmit unnecessarily• Can have 2 or more copies of same packet in transit


Designing Efficient Reliable Protocols

• Already seen one way to improve efficiency: choose timeout wisely

• Another way to improve efficiency: “keep the pipe full” with new data packets and necessary retransmissions• Stop-and-Wait• Go-Back-N• Selective Repeat (SRP)


Stop-and-Wait Protocol• After transmitting a packet/frame, the

sender stops and waits for an ACK before transmitting the next frame

• If a timeout occurs before receiving an ACK, the sender retransmits the frame

• Link layer RTT = send time + process time at receiver + ACK send time

• Here, timeout > RTT

Sender ReceiverFrame

Ack

Next frame

Ack

TimeoutPeriod

RTT

time time


Stop-and-Wait Protocol (2)• If a timeout occurs before receiving an

ACK, the sender retransmits the frame.

time

Sender Receiver

Frame

Frame

Ack

TimeoutPeriod


Stop-and-Wait Protocol (3)• If a timeout occurs before receiving an

ACK, the sender retransmits the frame.

time

Sender Receiver

Frame

Frame

Ack

TimeoutPeriod


Stop-and-Wait Protocol (4)• Want timeout >= RTT to avoid spurious

retransmissions of a frame/packet

time

Sender Receiver

Frame

Frame

Ack

RTT Ack Unnecessary retransmission

TO


Stop-and-Wait Protocol (5)• Label each packet and ACK with the

proper sequence # to avoid confusion at receiver and sender

Sender ReceiverFrame #1

ACK #1

Frame #2

ACK #2

TimeoutPeriod

RTT

time time


Problem with Stop-and-Wait• Only one outstanding packet at a time =>

waste of link bandwidth• Example: 1.5 Mbps link with RTT 45 ms => a

Delay*Bandwidth product = 67.5 Kb ≈ 8 KB. “pipe size”

• If frame size = 1 KB, then use only 1/8 of bandwidth

Sender ReceiverFrame #1

ACK #1

Frame #2

ACK #2

RTT

time time


“Keep the Pipe Full”• During one RTT, send N packets

• Example: 1.5 Mbps link with RTT 45 ms => a Delay*Bandwidth product = 67.5 Kb ≈ 8 KB. “pipe size”

• If frame size = 1 KB, and N=3, then can have 3 outstanding packets, 3/8 of BW, and triple bandwidth utilization!

Sender Receiver

RTT

time time

Frame #1Frame #2

Frame #3

ACK #3ACK #2

ACK #1


Go-Back-N Sliding Window Protocol

• Maintain a sliding window at both sender and receiver of unacknowledged packets• Send Window Size (SWS)• At sender: LAR (last ACK received), LFS (last

frame sent)

• Sliding window:• When ACK arrives, slide LAR and LFS to right• LFS – LAR <= SWS (= delay*BW product?)• Retransmit entire window

… …

LAR LFS

SWS


Go-Back-N Sliding Window Protocol (2)

• At receiver:• Maintain a Receive Window Size (RWS)• At receiver: LAF (largest acceptable frame),

LFR (last frame received)

• Sliding window:• When frame arrives, keep it if it’s within window• If frame #(LFR+1) arrives, then slide window to

right (increment LFR and LAF)• Send back Cumulative ACK = LFR, LAF – LFR <=

RWS

… …

LFR LAF

RWS



• Example: RWS = 4, LFR = 5, LAF = 9.• Suppose at receiver frames #7 and #8 arrive,

but frames #6 or #9 either arrive out of order or are lost.

• When frame #7 arrives out of order, then send cumulative ACK with sequence #5 (same for frame #8) (alternative: delay ACKs until #6 arrives)

• When frame #6 arrives, slide window (LFR’=8, LAF’=12), and send cumulative ACK #8.

… …

LFR=5 LAF=9

RWS=4

LFR’=8 LAF’=12



• Meanwhile, back at the sender…• Example: suppose SWS=6, LAR=5, LFS=11• Each time sender gets a cumulative ACK of

#5, it retransmits frame #6 through frame #11

• When sender gets cumulative ACK #8, it slides window right (LAR’=8, LFS’=14), and transmits entire window (frame #9 thru #14)

… …

LAR=5 LFS=11

SWS=6

LAR’=8 LFS’=14


Problem with Go-Back-N

• Cumulative ACK’s cause unnecessary retransmissions => inefficient• In our example, packets #7 and #8 are

retransmitted even though they’ve already arrived at receiver

• Solution: acknowledge each packet individually, or selectively, rather than cumulatively


Selective Repeat Protocol (SRP)

• Selective ACK’s sent by receiver identify specifically which frame(s) have been received correctly • In our example, the ACK would contain info

that only packets #7 and #8 have already arrived at receiver

• Sender only retransmits packets #6 and #9, and avoids resending #7 and #8

• “sliding” window in SRP actually becomes much more complicated than GBN - track “holes” btwn. acknowledged packets

… …

Window


Link Layer vs. End-to-End Retransmission

• Can retransmit end-to-end (at transport layer) as well as at data-link layer

• Given link layer retransmission, why do you need end-to-end retransmission?• Packets can still be lost in intermediate nodes,

e.g. routers

• Given end-to-end retransmission, why retransmit at link-layer at all?• Performance?


Other Protocol Design Issues

• Flow control• Sequence # wrap-around• Connection establishment• Connection tear-down• State machine definition at sender and

receiver endpoints of protocol

chapter 2 designing reliable protocols professor rick han university of colorado at boulder...

Documents

boulder reliable protocols

reliable datalink protocols

certain protocols

reliablearq protocols

packets receiver

correction slide

packet solution

boulder announcements