540 likes | 685 Views
Protocol Strategies. Idle RQ (Stop-and-Wait). Transmission Initiated. Ack Received Send Next. Send N+1. Send N. Fig 1.23. Message is lost. Repeat N. Send N+1. Send N. Fig 1.23. Ack is lost. Repeat N. Send N+1. Send N. Fig 1.23. Message Propagates.
E N D
Idle RQ (Stop-and-Wait) Transmission Initiated Ack Received Send Next Send N+1 Send N Fig 1.23
Message is lost Repeat N Send N+1 Send N Fig 1.23
Ack is lost Repeat N Send N+1 Send N Fig 1.23
Message Propagates First bit of message arrives at receiver -> Propagation delay Fig 1.24
Message Transmission Transmission time SAME Transmission time Fig 1.24
Message Transmission Plus Propagation Transmission + Propagation time Fig 1.24
Receiver Processes Turnaround time Fig 1.24
Receiver Send Ack Short time to transmit ACK Fig 1.24
ACK Propagates First bit of ACK arrives at receiver -> Propagation delay… same as before Fig 1.24
Continuous RQ Sender continues sending, eventually acks arrive from the receiver At the same rate as they depart from the transmitter No Errors Idealistic Fig 1.26
Aggressive Sending Strategy but messages are lost What is the strategy being used by the receiver when receiving messages out of sequence? Receiver recognizes Sender knows N+1 problem Sends in next slot Fig 1.27
Now ACK is lost! Fig 1.27
A different retransmissionstrategy Information frame lost Fig 1.28
Again ACK is Lost Fig 1.28
Strategies • Idle RQ -> Stop and Wait • Continuous RQ-> • Selective Repeat • Go-Back-N
Idle RQ • Send a message • Do not send the next until ACK is received • Messages and ACKS numbered 0/1/0/1/…. • If “a” is large, • capacity of link may be severely underutilized • Overall user delay may be excessive (why wait)
Selective repeat • Aggressive sending • Multiple outstanding messages (w/o ACK) • If error at receiver • Receiver keeps later messages buffered at a lower level and only passes them up when the missing frames arrive • Sender only resends error messages • Extra management effort required at receiver
Go-Back-N • Aggressive sending • Multiple outstanding messages (w/o ACK) • If error at receiver • Receiver REJECTs out of order messages • Sender only resends ALL messages from point of error • Simple management effort required at receiver
How do you number frames? Fig 1.29
SIZE not NAMES Fig 1.29
This Shows How To Name Fig 1.30
N=4, K=3 (will lead to a problem) Sender Receiver Send M1, M2 and M3 Recv M1, M2 and M3 ACK M1, M2 and M3 Recv ACK M1, M2 and M3 Send M4, M1* and M2* time
N=4, K=3 ACKs are lost Sender Receiver Send M1, M2 and M3 Recv M1, M2 and M3 ACK M1, M2 and M3 Recv ACK M1, M2 and M3 ReSend M1, M2 and M3 time
N=7, K=3 (NO problems) Sender Receiver Send M1, M2 and M3 Recv M1, M2 and M3 ACK M1, M2 and M3 Recv ACK M1, M2 and M3 Send M4, M5 and M6 time
N=7, K=3 ACKs lost.. No problems Sender Receiver Send M1, M2 and M3 Recv M1, M2 and M3 ACK M1, M2 and M3 Recv ACK M1, M2 and M3 ReSend M1, M2 and M3 time
Naming… A summary Fig 1.30
PiggyBacked ACKs • Traffic frequently going in the reverse direction • No send to send an entire new frame with additional overhead. • Typically, a message contains the name of the message in transit AND the name of the ack message, message expected in the other direction
What if nothing in the other driection? • Set a timer waiting for return travel • If no return travel before the timer goes off, • Send a separate ACK when the timer expires. • ELSE • Piggyback on return traffic.
What about reverse traffic • Discussion only focuses on traffic in one direction • Problem is symmetric. • Software is tricky but the send and receive code are integrated into the same process.
Link Layer Complexity Link SubLayers Fig 1.31
Link Layer Complexity Timer to alert sender to resend Fig 1.31
Events From Side From Above From Below Fig 1.32
State Diagram event action state change Fig 1.33
State Machine and Events Figs 1.32 and 1.33
Actions Create Outgoing Events(Events at the receiver) Figs 1.32 and 1.33
These Outgoing Events Are INCOMING to the receivervia MAC layer sender receiver Figs 1.33 and 1.34
One more time Ls_User Creates LdataReq TxFrame to destination iRCVD from MAC_provider to destination
Three Ways = Same State Transition Diagram Program Event-State Table
Event-State Table Fig 1.33
Program Choose -action -next State based on -current state -event Main Loop Fig 1.33
network link physical physical link network network link link network