This document discusses reliable data transfer protocols including Go-Back-N (GBN). GBN allows a sender to transmit multiple packets without waiting for acknowledgements, up to a maximum window size of N. The sender bases retransmissions on a timeout for the oldest unacknowledged packet. The receiver discards out-of-order packets and sends cumulative acknowledgements for the highest in-order packet received. Pipelining helps increase utilization over stop-and-wait protocols but requires numbering packets, buffering, and handling retransmissions and duplicate packets.
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
protocol, to transfer packet over
unreliable channel to receiver
deliver_data(): called by rdt
to deliver data to upper layer
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel
3. Rdt2.0: FSM Specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
call from
above
Wait for
ACK or
NAK
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Λ
receiver
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for call
from below
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
4. Rdt2.0
• rdt2.0 is a stop and wait
protocol
– Sender sends one packet, then
waits for receiver response
Handling Duplicates:
• rdt2.0 has a fatal flaw
• What happens if ACK/NAK get
corrupted?
•
•
•
–
•
Add checksum bits to ACK/NAK
How the protocol should recover
from errors in ACK/NAK?
– Retransmission on receipt of a
corrupt ACK/NAK
– Retransmission causes duplicates
– Receiver does not know whether
ACK or NAK it sent was received
correctly
– Receiver does not know a priori
whether an arriving packet
contains new data or is a
retransmission
Sender retransmits current
packet if ACK/NAK garbled
Sender adds sequence number
to each packet
Receiver discards (doesn’t
deliver up) duplicate packet
5. Rdt2.1: Sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
Wait for call
0 from
above
Wait for
ACK or
NAK 0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
Λ
Wait for
ACK or NAK
1
Wait for
call 1
from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
7. Rdt2.2: a NAK-free protocol
• Same functionality as rdt2.1, using ACKs only
• Instead of NAK, receiver sends ACK for last packet
received OK
– Receiver must explicitly include seq # of the
packet being ACKed
• Duplicate ACK at sender results in same action as
NAK: retransmit current packet
8. Rdt2.2: Sender, Receiver Fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
rdt_rcv(rcvpkt) &&
udt_send(sndpkt)
( corrupt(rcvpkt) ||
Wait for
Wait for
isACK(rcvpkt,1) )
ACK
call 0 from
above
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
Wait for
0 from
below
0
Sender FSM
Fragment
Receiver FSM
Fragment
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
Λ
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK,1, chksum)
udt_send(sndpkt)
9. Rdt3.0: Channels with Errors and Loss
New Assumption: Underlying channel can also lose packets
(data or ACKs)
What to do when packet loss occurs?
Retransmissions
How to detect loss?
Sender waits “reasonable” amount of time for ACK
Must wait at least as long as RTT plus processing
delay.
Retransmits if no ACK received in this time
If packet (or ACK) just delayed (not lost):
Retransmission will be duplicate, but use of sequence
numbers can handles this.
11. Pipelined Reliable Data Transfer
Protocols
Rdt3.0 works, but performance is poor
Poor Performance is due to the fact that
it is a stop and wait protocol
Poor utilization of the resource
Solution
Sender is allowed to send multiple packets
without waiting for ACKs.
Pipelining
Since many sender to receiver packets can be
visualized as filling a pipeline
Increase utilization
12. Pipelined Reliable Data Transfer Protocols
Pipelining has the following consequences for
reliable data transfer
Range of sequence numbers must be increased
Sender and receiver sides may have to buffer
more than one packet.
Two basic approaches towards pipeline error
recovery:
Go-Back-N, Selective Repeat
13. Go-Back-N (GBN)
Sender:
Sender is allowed to transmit multiple packets without waiting
for an acknowledgement
Constrained to a certain maximum number N.
Base or send_base
Sequence number of oldest unacknowledged packet
Nextseqnum
Sequence number of next packet to be sent
The range of sequence numbers for transmitted but not
acknowledged packets can be viewed as a window of size N.
This window slides forward as the protocol operates
14. Go-Back-N
GBN sender must respond to three types of events
Invocation from above (rdt_send() is called):
If window is full, returns data to upper layer
Maintain synchronization mechanism
Receipt of an ACK:
ACK for packet with seq # n is taken as“Cumulative ACK”
More shortly in receiver
Time out event:
Sender has timer for oldest unacknowledged packet
• If timer expires, retransmit all unacknowledged packets
15. Go-Back-N
Receiver:
If a packet with seq # n is received correctly and is in
order
ACK is sent and data is delivered to upper layers
For all other cases
Receiver discards the packet and resends ACK for most
recently received in order packet
Packets are delivered one at a time to upper layers
If a packet k has been received and delivered, then all
packets with seq # lower than k have also been delivered.
Receiver discards out of order packets
No receiver buffering
Need only remember expectedseqnum
