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

sender receiver

pkt #0

ACK

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

sender receiver

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

sender receiver

pkt #0

ACK

ACK

pkt #1

rdt 2.1 in action: corrupt ACK

corrupt

wait for pkt #1pkt #0

re-transmission

ACK discard pkt

wait for call #0

wait for ACK/NAK

wait for pkt #0

sender receiver

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

sender receiver

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

Start timer

Start timer

Stop timer

Start timer

Start timer

Stop timerStop 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

sender receiver

pkt #0

timer in action: data packet is lost

lost

start timer

timeout

pkt #0start timer

ACK stop timer

re-tranmission

wait for call #0

wait for ACK/NAK

wait for pkt #0

wait for pkt #1

sender receiver

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 FSMfragment

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 FSMfragment

Λ