Reliable data transfer protocols are developed incrementally to handle increasingly challenging network conditions. Rdt1.0 provides reliable transfer over a reliable channel using separate finite state machines for the sender and receiver. Rdt2.0 adds checksums and acknowledgments to handle bit errors, requiring the sender to retransmit packets on negative acknowledgment from the receiver. Rdt3.0 further addresses lost packets by having the sender retransmit if no acknowledgment is received within a timeout period, using sequence numbers and timers. Pipelined protocols like Go-Back-N and Selective Repeat then improve throughput by allowing multiple outstanding packets, with Selective Repeat having the receiver acknowledge each packet individually for retransmission of only missing packets.
Reliable data transfer protocols are developed incrementally to handle increasingly challenging network conditions. Rdt1.0 provides reliable transfer over a reliable channel using separate finite state machines for the sender and receiver. Rdt2.0 adds checksums and acknowledgments to handle bit errors, requiring the sender to retransmit packets on negative acknowledgment from the receiver. Rdt3.0 further addresses lost packets by having the sender retransmit if no acknowledgment is received within a timeout period, using sequence numbers and timers. Pipelined protocols like Go-Back-N and Selective Repeat then improve throughput by allowing multiple outstanding packets, with Selective Repeat having the receiver acknowledge each packet individually for retransmission of only missing packets.
Reliable data transfer protocols are developed incrementally to handle increasingly challenging network conditions. Rdt1.0 provides reliable transfer over a reliable channel using separate finite state machines for the sender and receiver. Rdt2.0 adds checksums and acknowledgments to handle bit errors, requiring the sender to retransmit packets on negative acknowledgment from the receiver. Rdt3.0 further addresses lost packets by having the sender retransmit if no acknowledgment is received within a timeout period, using sequence numbers and timers. Pipelined protocols like Go-Back-N and Selective Repeat then improve throughput by allowing multiple outstanding packets, with Selective Repeat having the receiver acknowledge each packet individually for retransmission of only missing packets.
Reliable data transfer protocols are developed incrementally to handle increasingly challenging network conditions. Rdt1.0 provides reliable transfer over a reliable channel using separate finite state machines for the sender and receiver. Rdt2.0 adds checksums and acknowledgments to handle bit errors, requiring the sender to retransmit packets on negative acknowledgment from the receiver. Rdt3.0 further addresses lost packets by having the sender retransmit if no acknowledgment is received within a timeout period, using sequence numbers and timers. Pipelined protocols like Go-Back-N and Selective Repeat then improve throughput by allowing multiple outstanding packets, with Selective Repeat having the receiver acknowledge each packet individually for retransmission of only missing packets.
Download as PPT, PDF, TXT or read online from Scribd
Download as ppt, pdf, or txt
You are on page 1/ 31
Reliable Data Transfer
Transport Layer
3-1
Principles of Reliable data transfer
important in app., transport, link layers top-10 list of important networking topics!
characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Transport Layer
3-2
Reliable data transfer: getting started
rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer
send side
udt_send(): called by rdt,
to transfer packet over unreliable channel to receiver
deliver_data(): called by rdt to deliver data to upper
receive side
rdt_rcv(): called when packet
arrives on rcv-side of channel Transport Layer
3-3
Reliable data transfer: getting started
Well: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machines (FSM) to specify
sender, receiver
state: when in this
state next state uniquely determined by next event
state 1
event causing state transition
actions taken on state transition event actions
state 2
Transport Layer
3-4
Rdt1.0: reliable transfer over a reliable channel
underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver read data from underlying channel
error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender
Transport Layer
3-6
rdt2.0: FSM specification
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK
Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer
3-7
rdt2.0: operation with no errors
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)
Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer
3-8
rdt2.0: error scenario
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)
Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Transport Layer
3-9
rdt2.0 has a fatal flaw!
Stop and Wait
Sender sends one packet, then waits for receiver
response
What happens if ACK/NAK corrupted?
sender doesnt know what happened at receiver!
cant just retransmit: possible duplicate
Handling duplicates:
sender adds sequence number to each pkt
sender retransmits current pkt if ACK/NAK garbled receiver discards (doesnt deliver up) duplicate pkt Transport Layer 3-10
rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isNAK(rcvpkt) ) ACK or call 0 from udt_send(sndpkt) NAK 0 above
New assumption: underlying channel can also lose packets (data or ACKs)
checksum, seq. #, ACKs,
retransmissions will be of help, but not enough
Approach: sender 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 use of seq. #s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer Transport Layer 3-16
last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
Transport Layer 3-23
Go-Back-N Sender: 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 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-24
GBN: receiver ACK-only: always send ACK for correctlyreceived pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum
out-of-order pkt: discard (dont buffer) -> isn't this bad? Re-ACK pkt with highest in-order seq #
Transport Layer 3-25
GBN in action
Transport Layer 3-26
Selective Repeat receiver
individually acknowledges all correctly
received pkts
buffers pkts, as needed, for eventual in-order delivery
to upper layer
sender only resends pkts for which ACK not
received
sender timer for each unACKed pkt
sender window N consecutive seq #s again limits seq #s of sent, unACKed pkts
Transport Layer 3-27
Selective repeat: sender, receiver windows
Transport Layer 3-28
Selective repeat sender data from above :
receiver pkt n in [rcvbase, rcvbase+N-1]
if next available seq # in
send ACK(n)
timeout(n):
in-order: deliver (also
window, send pkt
resend pkt n, restart timer
ACK(n) in [sendbase,sendbase+N]: mark pkt n as received if n smallest unACKed pkt,
advance window base to
next unACKed seq #
out-of-order: buffer
deliver buffered, in-order
pkts), advance window to next not-yet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
ACK(n)
otherwise: ignore
Transport Layer 3-29
Selective repeat in action
Transport Layer 3-30
Selective repeat: dilemma Example: seq #s: 0, 1, 2, 3 window size=3 receiver sees no
difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size? Transport Layer 3-31
