1
play

1 rdt2.0: FSM specification rdt2.0: operation with no errors - PDF document

Sep 03, 2022 •161 likes •229 views

Principles of Reliable data transfer important in app., transport, link layers top-10 list of important networking topics! Reliable Data Transfer characteristics of unreliable channel will determine complexity of reliable data transfer

  1. Principles of Reliable data transfer ❒ important in app., transport, link layers ❒ top-10 list of important networking topics! Reliable Data Transfer ❒ characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer Transport Layer 3-1 3-2 Reliable data transfer: getting started Reliable data transfer: getting started We’ll: rdt_send(): called from above, (e.g., deliver_data(): called by app.). Passed data to by rdt to deliver data to ❒ incrementally develop sender, receiver sides deliver to receiver upper layer upper of reliable data transfer protocol (rdt) ❒ consider only unidirectional data transfer send receive ❍ but control info will flow on both directions! side side ❒ use finite state machines (FSM) to specify event causing state transition sender, receiver actions taken on state transition state: when in this state state “state” next state event 1 udt_send(): called by rdt, uniquely determined 2 rdt_rcv(): called when packet actions to transfer packet over arrives on rcv-side of channel by next event unreliable channel to receiver Transport Layer 3-3 Transport Layer 3-4 Rdt1.0: reliable transfer over a reliable channel Rdt2.0: channel with bit errors ❒ underlying channel perfectly reliable ❒ underlying channel may flip bits in packet ❍ no bit errors ❍ checksum to detect bit errors ❍ no loss of packets ❒ the question: how to recover from errors: ❒ separate FSMs for sender, receiver: ❍ acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK ❍ sender sends data into underlying channel ❍ negative acknowledgements (NAKs): receiver explicitly ❍ receiver read data from underlying channel tells sender that pkt had errors rdt_send(data) Wait for Wait for rdt_rcv(packet) ❍ sender retransmits pkt on receipt of NAK call from call from extract (packet,data) packet = make_pkt(data) ❒ new mechanisms in rdt2.0 (beyond rdt1.0 ): below above deliver_data(data) udt_send(packet) ❍ error detection sender receiver ❍ receiver feedback: control msgs (ACK,NAK) rcvr->sender Transport Layer 3-5 Transport Layer 3-6 1

  2. rdt2.0: FSM specification rdt2.0: operation with no errors rdt_send(data) rdt_send(data) snkpkt = make_pkt(data, checksum) receiver snkpkt = make_pkt(data, checksum) udt_send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && isNAK(rcvpkt) isNAK(rcvpkt) Wait for Wait for Wait for Wait for rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && call from ACK or call from ACK or udt_send(sndpkt) corrupt(rcvpkt) udt_send(sndpkt) corrupt(rcvpkt) above NAK above NAK udt_send(NAK) udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for Wait for Λ Λ call from call from below below sender rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) notcorrupt(rcvpkt) extract(rcvpkt,data) extract(rcvpkt,data) deliver_data(data) deliver_data(data) udt_send(ACK) udt_send(ACK) Transport Layer Transport Layer 3-7 3-8 rdt2.0: error scenario rdt2.0 has a fatal flaw! rdt_send(data) snkpkt = make_pkt(data, checksum) ❒ Stop and Wait udt_send(sndpkt) rdt_rcv(rcvpkt) && ❍ Sender sends one packet, then waits for receiver response isNAK(rcvpkt) Wait for Wait for rdt_rcv(rcvpkt) && ❒ What happens if ACK/NAK corrupted? call from ACK or corrupt(rcvpkt) udt_send(sndpkt) above NAK ❍ sender doesn’t know what happened at receiver! udt_send(NAK) ❍ can’t just retransmit: possible duplicate rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for Λ call from ❒ Handling duplicates: below ❍ sender adds sequence number to each pkt rdt_rcv(rcvpkt) && ❍ sender retransmits current pkt if ACK/NAK garbled notcorrupt(rcvpkt) ❍ receiver discards (doesn’t deliver up) duplicate pkt extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer 3-9 Transport Layer 3-10 rdt2.1: sender, handles garbled ACK/NAKs rdt2.1: receiver, handles garbled ACK/NAKs rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(0, data, checksum) extract(rcvpkt,data) udt_send(sndpkt) rdt_rcv(rcvpkt) && deliver_data(data) ( corrupt(rcvpkt) || sndpkt = make_pkt(ACK, chksum) Wait for Wait for isNAK(rcvpkt) ) udt_send(sndpkt) ACK or rdt_rcv(rcvpkt) && (corrupt(rcvpkt) call 0 from udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) NAK 0 above sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum) rdt_rcv(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) udt_send(sndpkt) && && notcorrupt(rcvpkt) Wait Wait notcorrupt(rcvpkt) for && isACK(rcvpkt) rdt_rcv(rcvpkt) && for rdt_rcv(rcvpkt) && && isACK(rcvpkt) 0 from 1 from Λ not corrupt(rcvpkt) && not corrupt(rcvpkt) && Λ below has_seq1(rcvpkt) below has_seq0(rcvpkt) Wait for Wait for sndpkt = make_pkt(ACK, chksum) ACK or sndpkt = make_pkt(ACK, chksum) call 1 from rdt_rcv(rcvpkt) && udt_send(sndpkt) udt_send(sndpkt) NAK 1 above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) ( corrupt(rcvpkt) || && has_seq1(rcvpkt) rdt_send(data) isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) extract(rcvpkt,data) udt_send(sndpkt) deliver_data(data) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Transport Layer 3-11 Transport Layer 3-12 2

  3. rdt2.1: discussion rdt2.2: a NAK-free protocol ❒ same functionality as rdt2.1, using ACKs only Sender: Receiver: ❒ seq # added to pkt ❒ must check if ❒ instead of NAK, receiver sends ACK for last pkt received packet is received OK ❒ two seq. #’s (0,1) will duplicate ❍ receiver must explicitly include seq # of pkt being ACKed suffice. Why? ❒ duplicate ACK at sender results in same action as ❍ state indicates ❒ must check if whether 0 or 1 is NAK: retransmit current pkt received ACK/NAK expected pkt seq # corrupted ❒ note: receiver can not ❒ twice as many states know if its last ❍ state must “remember” ACK/NAK received whether “current” pkt OK at sender has 0 or 1 seq. # Transport Layer Transport Layer 3-13 3-14 rdt2.2: sender, receiver fragments rdt3.0: channels with errors and loss Approach: sender waits rdt_send(data) New assumption: “reasonable” amount of time sndpkt = make_pkt(0, data, checksum) underlying channel can udt_send(sndpkt) for ACK rdt_rcv(rcvpkt) && also lose packets ( corrupt(rcvpkt) || Wait for retransmits if no ACK received Wait for ❒ isACK(rcvpkt,1) ) ACK call 0 from (data or ACKs) in this time 0 udt_send(sndpkt) above if pkt (or ACK) just delayed (not sender FSM ❒ ❍ checksum, seq. #, lost): fragment rdt_rcv(rcvpkt) ACKs, retransmissions && notcorrupt(rcvpkt) ❍ retransmission will be will be of help, but not && isACK(rcvpkt,0) duplicate, but use of seq. #’s rdt_rcv(rcvpkt) && enough already handles this (corrupt(rcvpkt) || Λ has_seq1(rcvpkt)) Wait receiver FSM ❍ receiver must specify seq # for fragment udt_send(sndpkt) of pkt being ACKed 0 from below requires countdown timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) ❒ && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) Transport Layer 3-15 Transport Layer 3-16 rdt3.0 sender rdt3.0 in action rdt_send(data) rdt_rcv(rcvpkt) && sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) || udt_send(sndpkt) isACK(rcvpkt,1) ) start_timer Λ rdt_rcv(rcvpkt) Λ Wait Wait for timeout for call 0from udt_send(sndpkt) ACK0 above start_timer rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) notcorrupt(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) && isACK(rcvpkt,0) stop_timer stop_timer Wait Wait for timeout for call 1 from udt_send(sndpkt) ACK1 above rdt_rcv(rcvpkt) start_timer Λ rdt_send(data) rdt_rcv(rcvpkt) sndpkt = make_pkt(1, data, checksum) && udt_send(sndpkt) ( corrupt(rcvpkt) || start_timer isACK(rcvpkt,0) ) Λ Transport Layer 3-17 Transport Layer 3-18 3

  4. rdt3.0 in action Performance of rdt3.0 ❒ rdt3.0 works, but performance stinks ❒ Why? Transport Layer Transport Layer 3-19 3-20 rdt3.0: stop-and-wait operation Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to-be- sender receiver acknowledged pkts first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R ❍ range of sequence numbers must be increased ❍ buffering at sender and/or receiver first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R ❒ Two generic forms of pipelined protocols: go-Back-N, selective repeat Transport Layer 3-21 Transport Layer 3-22 Go-Back-N Pipelining: increased utilization sender receiver Sender: first packet bit transmitted, t = 0 ❒ k-bit seq # in pkt header last bit transmitted, t = L / R ❒ “window” of up to N, consecutive unack’ed pkts allowed first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R ❒ ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” ❍ may deceive duplicate ACKs (see receiver) ❒ timer for each in-flight pkt ❒ timeout(n): retransmit pkt n and all higher seq # pkts in window Transport Layer 3-23 Transport Layer 3-24 4

Recommend

More recommend