Chapter 2 Designing Reliable Protocols

1
Chapter 2Designing Reliable Protocols

• Professor Rick Han
• University of Colorado at Boulder
• rhan_at_cs.colorado.edu

2
Announcements

• Moved to ECCR 265
• Larger classroom gt 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

3
Recap of Previous Lecture

• 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

Host A
1011000
Layer 2
Layer 1
4
Reliable Protocols

• Why arent error detection and correction enough?
• Receiver drops a packet when errors detected
• Receiver cant 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

5
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 doesnt arrive, then
  retransmit

Sender
Receiver
6
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
7
Reliable Protocols (4)

• If the acknowledgement gets lost on the way back
  to sender, how does sender know its lost?
• If an acknowledgement for a packet is not
  received by a timeout value, then sender assumes
  the packet is lost retransmits it

8
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

9
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 doesnt match packets
  checksum, then discard packet.
• Alternative policy? Receiver caches noisy packet
  for future error correction!
• Retransmission can occur both at link layer and
  transport layer

10
ACKs and NAKs

• Types of Acknowledgments
• ACKs positive acknowledgements Ive
  received these packets
• Cumulative
• Selective
• NAKs negative acknowledgements I have not
  received these packets
• ACKs are more prevalent than NAKs

0100110
6
Sender
Receiver
11
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 gtgt roundtrip time
• Lets approximate roundtrip time RTT
  2(propagation delay), gtgt means much greater
  than
• Example if satellite link has prop. delay of 120
  ms each way, then RTT 240 ms. If timeout1 min
  gtgt 240 ms, then send too slowly.
• If timeout is too short, then retransmit
  unnecessarily
• Too short means timeout lt roundtrip time
• Example if timeout 1 ms lt RTT 240 ms, then
  retransmit unnecessarily
• Can have 2 or more copies of same packet in
  transit

12
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)

13
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 gt RTT

14
Stop-and-Wait Protocol (2)

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

Sender
Receiver
Frame
Timeout Period
Frame
Ack
time
15
Stop-and-Wait Protocol (3)

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

Sender
Receiver
Frame
Timeout Period
Frame
Ack
time
16
Stop-and-Wait Protocol (4)

• Want timeout gt RTT to avoid spurious
  retransmissions of a frame/packet

Sender
Receiver
Frame
Unnecessary retransmission
TO
Ack
RTT
Frame
Ack
time
17
Stop-and-Wait Protocol (5)

• Label each packet and ACK with the proper
  sequence to avoid confusion at receiver and
  sender

Receiver
Sender
Frame 1
Timeout Period
RTT
ACK 1
Frame 2
ACK 2
time
time
18
Problem with Stop-and-Wait

• Only one outstanding packet at a time gt waste of
  link bandwidth
• Example 1.5 Mbps link with RTT 45 ms gt a
  DelayBandwidth product 67.5 Kb 8 KB. pipe
  size
• If frame size 1 KB, then use only 1/8 of
  bandwidth

Sender
Receiver
Frame 1
RTT
ACK 1
Frame 2
ACK 2
time
time
19
Keep the Pipe Full

• During one RTT, send N packets
• Example 1.5 Mbps link with RTT 45 ms gt a
  DelayBandwidth product 67.5 Kb 8 KB. pipe
  size
• If frame size 1 KB, and N3, then can have 3
  outstanding packets, 3/8 of BW, and triple
  bandwidth utilization!

Sender
Receiver
RTT
time
time
20
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)

SWS


LAR
LFS

• Sliding window
• When ACK arrives, slide LAR and LFS to right
• LFS LAR lt SWS ( delayBW product?)
• Retransmit entire window

21
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)

RWS


LFR
LAF

• Sliding window
• When frame arrives, keep it if its within window
• If frame (LFR1) arrives, then slide window to
  right (increment LFR and LAF)
• Send back Cumulative ACK LFR, LAF LFR lt RWS

22
Go-Back-N Sliding Window Protocol (3)

• 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 (LFR8,
  LAF12), and send cumulative ACK 8.

RWS4


LFR5
LAF9
LFR8
LAF12
23
Go-Back-N Sliding Window Protocol (4)

• Meanwhile, back at the sender
• Example suppose SWS6, LAR5, LFS11
• 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 (LAR8, LFS14), and transmits
  entire window (frame 9 thru 14)

LAR5
LFS11
LAR8
LFS14
24
Problem with Go-Back-N

• Cumulative ACKs cause unnecessary
  retransmissions gt inefficient
• In our example, packets 7 and 8 are
  retransmitted even though theyve already arrived
  at receiver
• Solution acknowledge each packet individually,
  or selectively, rather than cumulatively

25
Selective Repeat Protocol (SRP)

• Selective ACKs 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


26
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?

27
Other Protocol Design Issues

• Flow control
• Sequence wrap-around
• Connection establishment
• Connection tear-down
• State machine definition at sender and receiver
  endpoints of protocol