FEC vs. ARQ Administrivia FEC provides constant throughput and predictable delay If high error rate, need long codes/complex circuitry Does not protect against all errors, or packet loss Last time: Framing Error detection Today: reliable transmission how to correct problems after we find them SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 3 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 1 FEC Reliable Transmission How do we do Forward Error Correction? Which is harder, Error Detection or Error Correction? Need to recover from corrupt frames Correct them using Error Correction Codes (ECC) Forward Error Correction (FEC) Alternatively, detect errors and retransmit if necessary Automatic Repeat request (ARQ) Which should you use? What is the tradeoff? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 4 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 2
Hamming Code (cont d) Forward Error Correction (or Error Correcting Codes) At the receiver, the received word is (r0,...,r7) The following are computed s0 = r1 + r2 + r3 + r4; s1 = r0 + r1 + r3 + r5; s2 = r0 + r2 + r3 + r6; What is the value of (s0, s1, s2) if there are no errors? Try by example General idea is to include enough redundant information to allow recovery from many errors Majority Encoding: Repeat every message (or character) several times; assume the majority is correct Example: Transmit HHHEEELLLLLLOOO WWWOOORRRLLLDDD instead of HELLO WORLD Can recover from 1 character errors If you receive HAHEEELL1aLLO!O WWWOO)RRLLLL1DD you can recover the message by taking majority for each character SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 7 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 5 (s0,s1,s2) Error Location 000 None 001 r6 010 r5 011 r0 100 r4 101 r2 110 r1 111 r3 Can correct any 1 error Error Location How does it compare to majority encoding? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 6 m = (m0, m1, m2, m3) c = (m0, m1, m2, m3, b0, b1, b2) b0= (m1 + m2 + m3) b1= (m0 + m1 + m3) b2= (m0 + m2 + m3) Let the message blocks and code words be as follows (for Hamming code 4, 7) Hamming Code SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 8
Alternative Approach: Retransmission Error Correction: a little Intuition If you can figure out that a packet was corrupted, retransmit it How to detect that a packet was corrupted? Suggestion 1: If error check fails send a warning? (Negative Acknowledgement or N) What if packet is lost completely? What if N is lost? Suggestion 2: If error check succeeds send acknowledgement () Retransmit if is not received during a specified time limit How will this work? How do spell checkers work? Suppose you receive STIP, what are the possible original transmissions? English Words are close to each other, difficult to correct sometimes if close, easy to turn one into the other and difficult to correct On the Other hand... rhearecsers in Cmdrabgie hvae funod out taht the haumn mnid deos not raed ervey lteter. So it can frgiue out waht is witretn as lnog as the frsit and lsat lrttees are crorcet. The rset can be a mses! SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 11 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 9 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 12 Potential of duplication of packets How to discriminate packet from duplicate? Delayed packets? What are the problems/drawbacks? (b) (d) Sender Receiver Sender Receiver (a) (c) Time Sender Receiver Sender Receiver Idea: use acknowledgements and timeouts Automatic Repeat ReQuest (ARQ) Reliable Transmission Every packet has to be received correctly Need to recover from corrupt frames (bit errors) Bit Errors Correct them using Error Correction Codes? What if they are too messed up? What about missing packets? What about delayed packets? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 10
Stop-and-wait Dont send a packet until you receive for previous one Problem: Keeping the pipe full; the link can be severely underutilized Example: T-1 link (1.5Mbps) with 45 ms RTT = 67.5Kb (8KB). Assuming a frame size of 1KB, stop-and-wait uses one eighth of link capacity What can we do to improve this? Problem 2: delay time to detect loss can be large SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 13 Sliding Window Protocols Use Pipelining Time Sender Receiver Idea: allow sender to send multiple frames before receiving an ack for one of them There is a limit on the number of frames that can be outstanding Limit chosen to keep the pipe full? SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 14 Sliding Window Algorithm Sender Receiver Assign Sequence Number to each frame (seqnum) Maintain three state variables: send window size (SWS) last ack received (LAR) last frame sent (LFS) Keep LFS LAR SWS LAR SWS When arrives, advance LAR, thereby opening window (allowing sending another frame) Buffer up to SWS frames LFS Maintain three state variables receive window size (RWS) last frame received (LFR) largest acceptable frame (LAF) KeepLAF LFR RWS seqnum arrives: NFE RWS if LFR < seqnum LAF accept the frame, otherwise discard What happens when a frame times out? Two flavors of sliding window algorithm Go- Back-N and Selective Repeat LFA SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 15 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 16
Go-Back-N Selective Repeat s are cumulative; an of a frame indicates that all frames before it have already been received Traditional GBN receiver discards frames received out of order why?? When a timeout occurs, resend all the frames that have been sent but not acknowledged what do you think? Can we improve on this? Use Nack s? GBN has several drawbacks; if the channel has a lot of errors, many redundant retransmissions Selective Repeat: each frame acknowledged/times out independently Sender resends frames that timeout Receiver acknowledges frames as they come; when the base frame is received, advance the window to the next unack d frame Lets do an example TCP uses a hybrid of both (in detail when we get to TCP) SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 17 SUNY-BINGHAMTON CS428/528 SPRING 2013 LEC. #6 18