1) The document describes RDT 3.0, a protocol for reliable data transfer over channels that can lose packets. It assumes packets and ACKs can be lost and proposes using checksums, sequence numbers, ACKs, and retransmissions to provide reliability despite losses.
2) The protocol proposes waiting a "reasonable amount of time" for an ACK before retransmitting, where reasonable is at least the round-trip time to avoid premature timeouts. It must also handle packet losses, ACK losses, and delayed ACKs.
3) Examples show how the protocol operates correctly in cases of no loss, packet loss, ACK loss, and premature timeout/delayed ACK. However, its performance is poor due to stop
1) The document describes RDT 3.0, a protocol for reliable data transfer over channels that can lose packets. It assumes packets and ACKs can be lost and proposes using checksums, sequence numbers, ACKs, and retransmissions to provide reliability despite losses.
2) The protocol proposes waiting a "reasonable amount of time" for an ACK before retransmitting, where reasonable is at least the round-trip time to avoid premature timeouts. It must also handle packet losses, ACK losses, and delayed ACKs.
3) Examples show how the protocol operates correctly in cases of no loss, packet loss, ACK loss, and premature timeout/delayed ACK. However, its performance is poor due to stop
1) The document describes RDT 3.0, a protocol for reliable data transfer over channels that can lose packets. It assumes packets and ACKs can be lost and proposes using checksums, sequence numbers, ACKs, and retransmissions to provide reliability despite losses.
2) The protocol proposes waiting a "reasonable amount of time" for an ACK before retransmitting, where reasonable is at least the round-trip time to avoid premature timeouts. It must also handle packet losses, ACK losses, and delayed ACKs.
3) Examples show how the protocol operates correctly in cases of no loss, packet loss, ACK loss, and premature timeout/delayed ACK. However, its performance is poor due to stop
1) The document describes RDT 3.0, a protocol for reliable data transfer over channels that can lose packets. It assumes packets and ACKs can be lost and proposes using checksums, sequence numbers, ACKs, and retransmissions to provide reliability despite losses.
2) The protocol proposes waiting a "reasonable amount of time" for an ACK before retransmitting, where reasonable is at least the round-trip time to avoid premature timeouts. It must also handle packet losses, ACK losses, and delayed ACKs.
3) Examples show how the protocol operates correctly in cases of no loss, packet loss, ACK loss, and premature timeout/delayed ACK. However, its performance is poor due to stop
underlying channel can “reasonable” amount of also lose packets time for ACK (data, ACKs) Ø retransmits if no ACK • checksum, seq. #, received in this time ACKs, retransmissions • Either due to data or Ack lost will be of help … but Ø if pkt (or ACK) just delayed (not lost): not enough • retransmission will be • How do we detect duplicate, but seq. #’s loss? already handles this • receiver must specify seq # of pkt being ACKed Ø requires countdown timer RDT 2-1 rdt3.0: channels with errors and loss
Reasonable amount of time?
Ø Wait at least the RTT
Ø Should try to recover from the loss ASAP Ø Wait for time value such that packet loss is likely but not guaranteed • don’t need worst-case delay
RDT 2-5 Performance of rdt3.0 Ø rdt3.0 is correct, but performance stinks Ø e.g.: 1 Gbps link, 15 ms prop. delay, 8000 bit packet and 30msec RTT: L 8000 bits Dtrans = R = = 8 microsecs 109 bits/sec • U sender: utilization – fraction of time sender busy sending
U L/R .008 sender = = = 0.00027 RTT + L / R 30.008
• RTT=30 msec, 1KB pkt every 30.008 msec: 33kB/sec
thruput over 1 Gbps link Ø Network protocol limits use of physical resources! RDT 2-6 rdt3.0: stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R
first packet bit arrives
RTT last packet bit arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
U L/R .008 sender = = = 0.00027 RTT + L / R 30.008
RDT 2-7 Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R
first packet bit arrives
RTT 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 3-packet pipelining increases utilization by a factor of 3!
U 3L / R .0024 sender = = = 0.00081 RTT + L / R 30.008
