Error Detection & Correction in Data Comm: CRC, Seq Numbers, & 3-way Handshake, Slides of Computer Science

Download Error Detection & Correction in Data Comm: CRC, Seq Numbers, & 3-way Handshake and more Slides Computer Science in PDF only on Docsity! Error control An Engineering Approach to Computer Networking Docsity.com CRC ■ Detects ◆ all single bit errors ◆ almost all 2-bit errors ◆ any odd number of errors ◆ all bursts up to M, where generator length is M ◆ longer bursts with probability 2^-m Docsity.com Packet errors ■ Different from bit errors ◆ types ✦ not just erasure, but also duplication, insertion,etc. ◆ correction ✦ retransmission, instead of redundancy Docsity.com Types of packet errors ■ Loss ◆ due to uncorrectable bit errors ◆ buffer loss on overflow ✦ especially with bursty traffic • for the same load, the greater the burstiness, the more the loss ✦ loss rate depends on burstiness, load, and buffer size ◆ fragmented packets can lead to error multiplication ✦ longer the packet, more the loss Docsity.com Types of packet errors (cont.) ■ Duplication ◆ same packet received twice ✦ usually due to retransmission ■ Insertion ◆ packet from some other conversation received ✦ header corruption ■ Reordering ◆ packets received in wrong order ✦ usually due to retransmission ✦ some routers also reorder Docsity.com Using sequence numbers ■ Loss ◆ gap in sequence space allows receiver to detect loss ✦ e.g. received 0,1,2,5,6,7 => lost 3,4 ◆ acks carry cumulative seq # ◆ redundant information ◆ if no ack for a while, sender suspects loss ■ Reordering ■ Duplication ■ Insertion ◆ if the received seq # is “very different” from what is expected ✦ more on this later Docsity.com Sequence number size ■ Long enough so that sender does not confuse sequence numbers on acks ■ E.g, sending at < 100 packets/sec (R) ◆ wait for 200 secs before giving up (T) ◆ receiver may dally up to 100 sec (A) ◆ packet can live in the network up to 5 minutes (300 s) (maximum packet lifetime) ◆ can get an ack as late as 900 seconds after packet sent out ◆ sent out 900*100 = 90,000 packets ◆ if seqence space smaller, then can have confusion ◆ so, sequence number > log (90,000), at least 17 bits ■ In general 2^seq_size > R(2 MPL + T + A) Docsity.com MPL ■ How can we bound it? ■ Generation time in header ◆ too complex! ■ Counter in header decremented per hop ◆ crufty, but works ◆ used in the Internet ◆ assumes max. diameter, and a limit on forwarding time Docsity.com Packet insertion in the Internet ■ Packets carry source IP, dest IP, source port number, destination port number ■ How we can have insertion? ◆ host A opens connection to B, source port 123, dest port 456 ◆ transport layer connection terminates ◆ new connection opens, A and B assign the same port numbers ◆ delayed packet from old connection arrives ◆ insertion! Docsity.com Solutions ■ Per-connection incarnation number ◆ incremented for each connection from each host ◆ - takes up header space ◆ - on a crash, we may repeat ✦ need stable storage, which is expensive ■ Reassign port numbers only after 1 MPL ◆ - needs stable storage to survive crash Docsity.com Solutions (cont.) ■ Assign port numbers serially: new connections have new ports ◆ Unix starts at 1024 ◆ this fails if we wrap around within 1 MPL ◆ also fails of computer crashes and we restart with 1024 ■ Assign initial sequence numbers serially ◆ new connections may have same port, but seq # differs ◆ fails on a crash ■ Wait 1 MPL after boot up (30s to 2 min) ◆ this flushes old packets from network ◆ used in most Unix systems Docsity.com Loss detection ■ At receiver, from a gap in sequence space ◆ send a nack to the sender ■ At sender, by looking at cumulative acks, and timeing out if no ack for a while ◆ need to choose timeout interval Docsity.com Nacks ■ Sounds good, but does not work well ◆ extra load during loss, even though in reverse direction ■ If nack is lost, receiver must retransmit it ◆ moves timeout problem to receiver ■ So we need timeouts anyway Docsity.com Timeouts ■ Set timer on sending a packet ■ If timer goes off, and no ack, resend ■ How to choose timeout value? ■ Intuition is that we expect a reply in about one round trip time (RTT) Docsity.com New TCP scheme (Jacobson) ■ introduce new term = mean deviation from mean (m) ■ m = | srtt - RTT | ■ sm = a * sm + (1-a) * m ■ timeout = srtt + b * sm Docsity.com Intrinsic problems ■ Hard to choose proper timers, even with new TCP scheme ◆ What should initial value of srtt be? ◆ High variability in R ◆ Timeout => loss, delayed ack, or lost ack ✦ hard to distinguish ■ Lesson: use timeouts rarely Docsity.com Retransmissions ■ Sender detects loss on timeout ■ Which packets to retransmit? ■ Need to first understand concept of error control window Docsity.com Selective retransmission ■ Somehow find out which packets lost, then only retransmit them ■ How to find lost packets? ◆ each ack has a bitmap of received packets ✦ e.g. cum_ack = 5, bitmap = 101 => received 5 and 7, but not 6 ✦ wastes header space ◆ sender periodically asks receiver for bitmap ◆ fast retransmit Docsity.com Fast retransmit ■ Assume cumulative acks ■ If sender sees repeated cumulative acks, packet likely lost ■ 1, 2, 3, 4, 5 , 6 ■ 1, 2, 3 3 3 ■ Send cumulative_ack + 1 = 4 ■ Used in TCP Docsity.com SMART ■ Ack carries cumulative sequence number ■ Also sequence number of packet causing ack ■ 1 2 3 4 5 6 7 ■ 1 2 3 3 3 3 ■ 1 2 3 5 6 7 ■ Sender creates bitmap ■ No need for timers! ■ If retransmitted packet lost, periodically check if cumulative ack increased. Docsity.com