CSS432 (Link Level Protocols) Reliable Transmission Textbook Ch 2.5

1. CSS432 (Link Level Protocols) Reliable TransmissionTextbook Ch 2.5 Prof. Athirai Irissappane http://courses.washington.edu/css432/athirai/ athirai@uw.edu CSS 432

2. Reliable Transmission • CRC is used to detect errors. • Some error codes are strong enough to correct errors. The overhead is typically too high. • Corrupt frames must be discarded. • A link-level protocol that wants to deliver frames reliably must recover from these discarded frames. • Protocols use Acknowledgements and Timeouts

3. Reliable Transmission • An acknowledgement (ACK for short) is a small control frame (only header no data) that a protocol sends back to its peer saying that it has received the earlier frame. • The receipt of an acknowledgement indicates to the sender of the original frame that its frame was successfully delivered. • If the sender does not receive an acknowledgment after a reasonable amount of time, then it retransmits the original frame. • The action of waiting a reasonable amount of time is called a timeout.

4. Frame Transfer Algorithms Sender Receiver Frame 0 Ack 0 Frame 1 Ack 1 Frame 0 Ack 0 Sender Receiver … Time … • Stop and wait • Stop a transmission and wait for ack to return or timeout • Add 1-bit sequence number to detect a duplication of the same frame • Sliding window • Allow multiple outstanding (un-ACKed) frames • Upper bound on un-ACKed frames, called window CSS 432

5. Stop and Wait (use seq num 0 to n) timeout // Test 2: client stop-and-wait message send ---------------------------------- intclientStopWait( UdpSocket &sock, constint max, int message[] ) { int retransmits = 0; // # retransmits int ack; // prepare a space to receive ack // transfer message[] max times for ( int sequence = 0; sequence < max; ) { message[0] = sequence; // message[0] has a sequence number sock.sendTo( (char *)message, MSGSIZE ); // udp message send // until a timeout (1500msecs) occurs // keep calling sock.poolRecvFrom( ) // if an ack came, exame if its ack sequence is the same as my sequence // if so, increment my sequence and go back to the loop top // if a timeout occurs, resend the same sequence and increment retransmits } return retransmits; } Frame sent 0 1 1 2 ack=1 seq=1 seq=2 ack=0 seq=1 ack=1 seq=0 late // Test 2: server reliable message receive ------------------------------------ void serverReliable( UdpSocket &sock, constint max, int message[] ) { int ack; // an ack message // receive message[] max times for ( int sequence = 0; sequence < max; ) { sock.recvFrom( (char *)message, MSGSIZE ); // udp message receive // if this is a message expected to receive send back an ack with this sequence number and increment sequence // if this message is < sequence number of expected message ignore the message, but send an acknowledgement for it } } Frame received 2 1 0 1 discarded CSS 432

6. Stop and Wait (HW2) CSS 432 Client writes a message sequence number in message[0], sends message[] and waits until it receives an integer acknowledgment from a server, while the server receives message[], copies the sequence number from message[0] to an acknowledgment, and returns it to the client. UDP bind client socket (connect, sendTo implicit bind but receiveFrom no implicit bind)

7. Stop and Wait • Problem: Can’t utilize the link’s capacity • Example 1 • Consider a 1.5 Mbps link with a 45 ms RTT • The link has a capacity, i.e., delay  bandwidth = 67.5 Kb ~ 8 KB • Sender can send only one frame (size = 1 KB) per RTT • 1KB for 45ms RTT (one-eighth of the link’s capacity) • To use the link fully, then sender should transmit up to eight frames before having to wait for an acknowledgement. CSS 432

8. Sliding Window Protocol • Utilizes link capacity • Transmit 8 frames before receiving ACK0 • Transmit 9th frame same time when ACK0 received • Allow multiple outstanding (un-ACKed) frames • Upper bound on un-ACKed frames (<=8), called window CSS 432

9. // Test 3: client sliding window + early-retransmission ----------------------- intclientSlidingWindow( UdpSocket &sock, constint max, int message[], constintwindowSize ){ int retransmits = 0; // # retransmits int ack; // prepare a space to receive ack intackSeq = 0; // the ack sequence expected to receive // transfer message[] max times for ( int sequence = 0; sequence < max || ackSeq < max; ) { if ( ackSeq + windowSize > sequence && sequence < max ) {//send till sliding window full message[0] = sequence; // message[0] has a sequence number sock.sendTo( (char *)message, MSGSIZE ); // udp message send // check if ack = ackSeq using sock.poolRecvFrom( ) if true increment ackSeq // increment sequence } else { // the sliding window is full! // until a timeout (1500msecs) occurs check for ack // keep calling sock.poolRecvFrom( ) // if an ack came, if ack >= ackSeq, ackSeq = ack + 1 // else resend the lost message (ack+1) and increment retransmits // break if (any) ack received // if a timeout occurs, resend the message corresponding to ackSeq and increment retransmits } } return retransmits; } Sliding Window window max = 5 TimeOUT frame sent 7 3 6 3 5 3 3 8 2 4 1 0 3 lost // Test 3: server early retransmission ---------------------------------------- void serverEarlyRetrans(UdpSocket &sock, constint max, int message[], constintwindowSize ){ int ack; // an ack message bool array[max]; //array[i]=true if i is received for ( int j = 0; j < max; j++ ) array[j] = false; // no message has arrived yet // receive message[] max times for ( int sequence = 0; sequence < max; ) { sock.recvFrom( (char *)message, MSGSIZE ); // receive a UDP message // if message[0] = sequence. //expected message received bool match=true //mark array[sequence]=true, //Increment sequence until you identify the first non-received message // else if message[0] > sequence //mark arrray[seqNum]=true. // if match=true //send ack=sequence // increment sequence // else send ack=sequence-1 } } lost Cum ACK 7 2 2 2 7 8 0 2 2 7 1 CSS 432

10. Sliding Window • No. of Packets Sent by Client before detecting packet loss = 5 + 3 • If the 3rd packet is lost • Client already has sent Window Size packets , i.e., 5 • Client has received ACK for 0, 1, 2 packets • Thus nPAckets sent before detecting packet loss = 8 • No extra time is taken by the server to send ACKs • Timer is triggered only when the expected ACK from Packet 3 is missing • If it takes 5us to send 1 packet and the timeout is 100us • Total time taken by sender to detect that packet 3 is lost = 8*5 + 100 = 140us CSS 432

11. Sliding Window (HW2) Client keeps writing a message sequence number in message[0] and sending message[] as far as the number of in-transit messages is less than a given window size Server receives message[], memorizes this message's sequence number in its array and returns as its acknowledgment the minimum sequence number of messages it has not yet received Repeat sending and receiving MAX times. CSS 432

12. Sequence Number Space • SeqNum field is finite; e.g., 3-bit SeqNum field (0..7) • Repeat sequence numbers, MaxSeqNum: e.g. 8 • SWS <= MaxSeqNum-1, differentiate between new, old incarnations when ACK is lost • If (RWS = 1), SWS <= MaxSeqNum-1 is sufficient • If (RWS = SWS), SWS <= MaxSeqNum-1 is not sufficient • suppose 3-bit SeqNum field (0..7) • SWS=RWS=7 • sender transmit frames 0..6 • arrive successfully, but ACKs lost • sender retransmits 0..6 • receiver expecting 7, 0..5, but receives second incarnation of 0..5 • SWS < (MaxSeqNum+1)/2 or 2 x SWS – 1 < MaxSeqNum CSS 432

13. Reviews • Stop-and-wait • Sliding window CSS 432