rdt2. has a fatal flaw! rdt2.1:, handles garbled ACK/NAKs what happens if ACK/NAK corrupted? doesn t know what happened at! can t just retransmit: possible duplicate handling duplicates: retransmits current pkt if ACK/NAK corrupted adds sequence number to each pkt two seq. # s (,1) will suffice. Why? discards (doesn t deliver up) duplicate pkt && isack(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(, data, checksum) call from ACK or NAK 1 ACK or NAK call 1 from isnak(rcvpkt) ) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) Transport Layer 3-29 Transport Layer 3-3 rdt2.1:, handles garbled ACK/NAKs notcorrupt(rcvpkt) && has_seq(rcvpkt) extract(rcvpkt,data) deliver_data(data) corrupt(rcvpkt) corrupt(rcvpkt) sndpkt = make_pkt(nak,checksum) sndpkt = make_pkt(nak,checksum) notcorrupt(rcvpkt) && has_seq1(rcvpkt) from below 1 from below notcorrupt(rcvpkt) && has_seq1(rcvpkt) notcorrupt(rcvpkt) && has_seq(rcvpkt) rdt2.2: a NAK-free protocol same functionality as rdt2.1, using ACKs only instead of NAK, sends ACK for last pkt received OK must explicitly include seq # of pkt being ACKed duplicate ACK at results in same action as NAK: retransmit current pkt extract(rcvpkt,data) deliver_data(data) Transport Layer 3-31 Transport Layer 3-32
rdt2.2:, fragments rdt3.: channels with errors and loss (corrupt(rcvpkt) has_seq1(rcvpkt)) sndpkt = make_pkt(ack, 1, checksum) sndpkt = make_pkt(, data, checksum) call from from below ACK FSM fragment FSM fragment notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, 1, checksum) isack(rcvpkt,1) ) && isack(rcvpkt,) Transport Layer 3-33 new assumption: underlying channel can also lose packets (data, ACKs) checksum, seq. #, ACKs, retransmissions will be of help but not enough approach: waits reasonable amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but seq. # s already handles this must specify seq # of pkt being ACKed requires countdown timer Transport Layer 3-34 rdt3. rdt3. in action call from && isack(rcvpkt,1) stop_timer isack(rcvpkt,) ) sndpkt = make_pkt(, data, checksum) Wait for ACK 1 Wait for call 1 from sndpkt = make_pkt(1, data, checksum) isack(rcvpkt,1) ) && isack(rcvpkt,) stop_timer rcv send rcv send rcv send (a) no loss rcv send resend rcv X loss (b) packet loss send rcv send Transport Layer 3-35 Transport Layer 3-36
rdt3. in action rcv send resend rcv X loss (c) ACK loss send rcv rcv (detect duplicate) send rcv send resend rcv rcv send rcv rcv (detect duplicate) send (detect duplicate) send (d) premature / delayed ACK Transport Layer 3-37 Performance of rdt3. rdt3. is correct, but performance stinks e.g.: 1 Gbps link, 15 ms prop. delay, 8 bits packet: D trans = L R U : utilization fraction of time busy sending U = 8 bits = 1 9 = 8 microsecs bits/sec L / R RTT + L / R =.8 3.8 =.27 if RTT=3 msec, 1KB pkt: 27 kbits/sec throughput over 1 Gbps link stop-and-wait protocol limits use of physical resources! Transport Layer 3-38 rdt3.: stop-and-wait protocol first packet bit transmitted, t = last packet bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK Pipelined ARQ protocols pipelining: allows multiple, in-flight, yetto-be-acknowledged pkts range of sequence numbers must be increased buffering at and/or ACK arrives, send next packet, t = RTT + L / R U = L / R RTT + L / R =.8 3.8 =.27 two generic forms of pipelined ARQ protocols: go-back-n, selective repeat Transport Layer 3-39 Transport Layer 3-4
Pipelining: increased utilization Pipelined ARQ protocols: overview first packet bit transmitted, t = last bit transmitted, t = L / R RTT ACK arrives, send next packet, t = RTT + L / R U = 3L / R RTT + L / R =.24 3.8 first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK 3-packet pipelining increases utilization by a factor of 3! =.81 Go-back-N (GBN): can have up to N unacked packets in pipeline only sends cumulative ack indicates that all packets up to acked # correctly received at the has timer for oldest unacked packet when timer expires, retransmit all unacked packets Selective Repeat (SR): can have up to N unacked packets in pipeline rcvr sends individual ack for each packet maintains timer for each unacked packet when timer expires, retransmit only that unacked packet Transport Layer 3-41 Transport Layer 3-42 Go-Back-N: k-bit seq # in pkt header window of up to N, consecutive unacked pkts allowed ACK(n): ACKs all pkts up to, including seq # n - cumulative ACK may receive duplicate ACKs (see ) timer for oldest in-flight pkt (n): retransmit packet n and all higher seq # pkts in window Transport Layer 3-43 Go-Back-N: ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don t buffer): no buffering! re-ack pkt with highest in-order seq # Transport Layer 3-44
GBN in action window (N=4) send send pkt3 (wait) rcv, send pkt4 rcv, send pkt5 ignore duplicate ACK pkt 2 send pkt3 send pkt4 send pkt5 Xloss receive, send receive, receive pkt3, discard, (re) receive pkt4, discard, (re) receive pkt5, discard, (re) rcv pkt2, deliver, send ACK2 rcv pkt3, deliver, send ACK3 rcv pkt4, deliver, send ACK4 rcv pkt5, deliver, send ACK5 Selective repeat individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer only resends pkts for which ACK not received timer for each unacked pkt window N consecutive seq # s limits seq #s of sent, unacked pkts Transport Layer 3-45 Transport Layer 3-46 Selective repeat:, windows Selective repeat data from : if next available seq # in window, send pkt (n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n-1]: mark pkt n as received if n is equal to sendbase, advance window sendbase to next unacked seq # pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window rcvbase to next not-yetreceived pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore Transport Layer 3-47 Transport Layer 3-48
Selective repeat in action window (N=4) send send pkt3 (wait) rcv, send pkt4 rcv, send pkt5 record ACK3 arrived pkt 2 record ACK4 arrived record ACK5 arrived Xloss receive, send receive, receive pkt3, buffer, send ACK3 receive pkt4, buffer, send ACK4 receive pkt5, buffer, send ACK5 rcv pkt2; deliver pkt2, pkt3, pkt4, pkt5; send ACK2 Relationship between seq # size and window size N & retransmit n-bit sequence number: Go-back-N ARQ: N=2 n -1 Selective-repeat ARQ: N=2 n-1 problem with too-large windows: 1 2.. 7 ACK7 At this point, the expects the next frame & retransmit 1 2.. 4 ACK4 At this point, the expects new frames 5,6,7,,1 Q: what happens when ACK2 arrives? <Go-back-N: N=8> <Selective-repeat: N=5> Transport Layer 3-49 Transport Layer 3-5