Go-Back-N ARQ  packets transmitted continuously (when available) without waiting for ACK, up to N outstanding, unACK’ed packets  a logically different sender timer association with each unACK’ed packet: extension of AB protocol Receiver:  ACK packet if correctly received and in-order, pass to higher layer  NACK or ignore (possibly discard) corrupt or out-of-order packet Sender : if NACK received, or timeout, for packet n, begin resending from n all over again if NACK received, or timeout, for packet n, begin resending from n all over again  cumulative ACK: ACK of n implicitly acknowledges up through n

Go-Back-N continued  no receiver transport buffering with discard  saves resources at receiver  avoids large bursts of packet delivery to higher layers  simplicity in buffering and protocol processing at sender and receiver  tradeoff between buffering/processing complexity and bandwidth

Go Back N: Example

Selective Repeat ARQ As in go back-N:  packet transmitted when available, up to limit timer associated with each unACK’ed packet  receiver NACK’s or ignores corrupted packets Unlike Go-Back-N:  out-of-order (but otherwise correct) packet is ACK’ed  receiver: buffers out-of-order packets  sender: on timeout or NACK of packet n, just retransmit n

Selective Repeat ARQ (cont) Notes:  more receiver buffering than Go back-N  more complicated buffer management by both sides  saves bandwidth: no need to retransmit correctly received packets

Selective Repeat ARQ: example

How Big Can a Window Be? Suppose sequence number space size is N Q: How big can window be and have SR still work? Partial answer: N-1 won’t work: Fundamental problem: sender and receiver  do not have synchronized info  cannot know exact same information

Throughput Comparison p - loss probability t_trans - pkt transmission time rtt - round trip time tput_SW = (1-p)/(rtt+t_trans) tput_GB = (1-p)/(p rtt + t_trans) tput_SR = (1-p)/t_trans

Throughput Comparison 1GB/sec link 1KB pkt -> t_trans = 8  s rtt =1ms

Throughput Comparison 1GB/sec link 1KB pkt -> t_trans = 8  s rtt =30ms

Detecting Errors: checksums Need to detect errors: bits in packet may be flipped while in transit or stored at intermediate notes. Approach: add extra bits to packets that will allow us to detect (possibly correct) bit errors

Simple example: Parity Given n-1 bit packet, add n-th bit, choosing value so that total number of 1  bits in packets (including nth bit) is odd (odd parity).  example packet: At receiver:  count # 1’s in packet, if even, then error!  what if even number of bit flips?  what if odd number of bit flips? error detection seq ack data (parity bit)

Simple example: Parity Note:  many codes with more powerful error detection capabilities  CRC-16: 16 bit code, detects 2 random bit errors, 16 errors in sequence.  packet header itself often separately checksummed  checksumming also done at data link layer  hardware support for transport-level checksum: SGI

Forward Error Correction: FEC ARQ protocols operate by detecting errors and retransmitting  retransmission needs round-trip delay to recover  may be too long for deep space, or high-speed, real- time applications  FEC: key idea is to transmit enough redundant data to allow receiver to recover from errors itself! (no sender transmission required)

(c) example: no errors (d) example: single bit error seq # ACK# data EDF d 1,1 … d 1,J d 1,J+1 d 2,1 … d 2,J d 2,J+1 d I,1 … d I,J d I,J+1 d I+1,1 … d I+1,J d 1,j+1 (a) 2-dimensional parity (b) packet format row parity column parity