Tutorial 2 Solution

Q1. Consider a channel that can lose packets but has a maximum delay that is known. Modify protocol rdt2.1 to include sender timeout and retransmit. Argue why the protocol can work correctly.

wait for call #0 wait for ACK/NAK wait for call #1 wait for ACK/NAK wait for pkt #0 wait for pkt #1 senderreceiver pkt #0 ACK pkt #1 rdt2.1 in action: no error

wait for call #0 wait for ACK/NAK wait for call #1 wait for ACK/NAK wait for pkt #0 wait for pkt #1 senderreceiver pkt #0 NAK ACK pkt #1 rdt 2.1 in action: corrupt packet corrupt pkt #0 re-transmision ACK

wait for call #0 wait for ACK/NAK wait for call #1 wait for ACK/NAK wait for pkt #0 senderreceiver pkt #0 ACK pkt #1 rdt 2.1 in action: corrupt ACK corrupt wait for pkt #1 pkt #0 re-transmission ACK discard pkt

wait for call #0 wait for ACK/NAK wait for pkt #0 senderreceiver pkt #0 rdt 2.1 in action: data packet is lost lost ? ?

wait for call #0 wait for ACK/NAK wait for pkt #0 wait for pkt #1 senderreceiver pkt #0 ACK rdt 2.1 in action: ACK/NAK is lost ? ? lost

Modifications Changes of the sender –Timer events –When to start the timer –How long is the timeout? –What will the sender do for a timeout event Changes of the receiver? –Check how the original receiver responds to new events (i.e., lost packets or ACKs)

Timeout udt_send(sndpkt) Start timer Timeout udt_send(sndpkt) Start timer Stop timer Start timer Stop timer timer >= 2 * maximum delay

How the Receiver Responds Suppose the timeout is caused by a lost data packet, i.e., a packet on the sender-to-receiver channel. The receiver never received the previous transmission and, if the timeout retransmission is received, it look exactly the same as if the original transmission is being received. Suppose an ACK is lost. The sender will eventually retransmit the packet on a timeout. But a retransmission is exactly the same action that is take if an ACK is garbled. Thus the sender's reaction is the same with a loss, as with a garbled ACK. No changes are needed!

wait for call #0 wait for ACK/NAK wait for pkt #0 senderreceiver pkt #0 timer in action: data packet is lost lost start timer timeout pkt #0 start timer ACK stop timer re-tranmission

wait for call #0 wait for ACK/NAK wait for pkt #0 wait for pkt #1 senderreceiver pkt #0 ACK timer in action: ACK/NAK is lost lost start timer timeout pkt #0 re-tranmission start timer discard pkt stop timer

Q2. Redesign rdt2.1 without using NAK packets. In other words, the receiver in the new protocol can only use ACK packets. Draw the FSM of the new protocol.

rdt2.2: a NAK-free protocol same functionality as rdt2.1, using ACKs only instead of NAK, receiver sends ACK for last pkt received OK –receiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt

rdt2.2: sender, receiver fragments Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Wait for ACK 0 sender FSM fragment Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) receiver FSM fragment 