Comp 343/443 Fall 2008, 25EP-602, 4:15-6:45 Week 3 2.4: error detection parity 1 parity bit catches all 1-bit errors No generalization to N! checksums ones-complement sum of A and B: form twos-complement sum A+B if there is an overflow bit, add it back in as low-order bit Fact: ones-complement sum is never 0000 unless all bits are 0. Rule of 9's; check sum is in fact the remainder upon dividing by 2^16 - 1 CRC (skimmed) Based on long division of polynomials Reasonably secure hash, in that it is very hard for systematic errors to result in same hash code. (For sums, byte transposition or "matching bit" errors leaves sum unchanged) Straightforward mathematical means for tweaking last bytes of msg2 so crc(msg1) == crc(msg2) secure hashes (md5, etc) Nobody knows at all how to produce two messages with same hash 2-D parity (corrects 1-bit errors) fundamental role of error-correcting codes (= "forward error correction") ====================================================================================== Sliding Windows 2.5, P&D 2.5: stop-and-wait versus sliding windows four stop-and-wait scenarios: p 99 (a) Frame/ACK (b) Frame / lost ACK (c) Lost Frame, retransmitted (d) late ACK (arriving after Frame is retransmitted) retransmit-on-timeout v. retransmit-on-duplicate sorcerers' apprentice bug (both sides retransmit on duplicate) 1st/last packet: special handling! lost final packet duplicated first packet just gave diagram of SWS=4 sliding windows basic ideas: SWS, RWS, LFS, LFA, NFE sender: SWS: Sender Window Size LAR: Last ACK received; window is LAR+1 ... LAR+SWS LFS: Last Frame Sent, usually close to LAR+SWS receiver: LCFR: Last Cumulative Frame Received. All frames <= LCFR have been received. LFR: LCFR < LFR <= LAF LAF: Last (highest) Acceptable Frame: LAF = LCFR+RWS receive window: LCFR+1 ... LAF NFE: Next Frame Expected: = LCFR+1 slow sender v slow router bandwidth*delay sending window: LAR+1 to LAR+SWS, receive window: NFE to LFA=NFE+RWS-1 Four regions of sender line: x <=LAR, LARA direction, all connections are infinitely fast. In the A->B direction, the A->R1 link is infinitely fast, but the other four each have a bandwidth of 1 packet/second. This makes the R1->R2 link the "bottleneck link" (it has the minimum bandwidth, and although there's a tie for the minimum this link is the first such one encountered) Alternative example: C----S1----S2----D assume: C-S1 link is infinitely fast (zero delay) S1->S2, S2->D each take 1.0 sec bandwidth delay (so two packets take 2.0 sec, per link, etc) Acks have same delay in reverse direction In both scenarios: no-load RTT = 4.0 sec Bandwidth = 1.0 packet/sec (= min link bandwidth) We assume a SINGLE CONNECTION is made; there is no competition. Bandwidth * Delay here is 4 packets (1 packet/sec * 4 sec RTT) Case 1: SWS = 2 window < bandwidth*delay (delay = RTT): less than 100% utilization delay is fixed as cwnd changes; is "base" rtt bandwidth proportional to cwnd example: SWS= 2. Throughput = 2/4 packets/sec each second, *two* of the routers R1-R4 are idle actual_RTT = 4 Case 2: SWS = 4 When SWS=4, throughput = 1 packet/sec, actual_RTT=4, and each second all four bottleneck links are busy. Case 3: SWS = 6 window > bandwidth*delay: pile up at router somewhere delay rises (artificially) bandwidth is that of bottleneck link example: SWS=6. Then the actual RTT rises to 6.0 sec. Each second, there are two packets in the queue at R1. avg_queue + bandwidth*no-load-RTT = 2+4 = 6 = SWS Now, however, *actual-RTT* is 6, and to the sender it *appears* that SWS = bandwidth * actual-RTT. =============================================================================== 2.6: Ethernet. See also my notes. Ethernet: Read section 2.6 on Ethernet logical: broadcast bus NI interrupts CPU if any of the following apply: * packet destaddr matches NI's physical addr * packet destaddr is b'cast addr * packet destaddr is multicast and NI has "subscribed" to that m'cast addr * NI is in promiscuous mode Why we need a TYPE field That covers RECEIVING; what about SENDING? Ethernet (addresses, collisions, performance) traditional broadcast-bus; role of hub eavesdropping story: In 1994 I changed the admin password on several remote unix machines, using telnet. I told no one. Within two hours, someone else logged into one of the remote machines, using the new password, from inria.fr (then rife with hackers, as I suppose was Loyola) physical addresses, bcast address operation of sending csma/cd collisions how CD works Signal propagation on the line: 1 bit = 23 m min packet size / max diamater requirement[!] SLOT TIME: min packet size collision detection time max diameter of network compare max packet size repeaters: simple amplifiers; max segment length need collision signal to be strong enough to be detected! change geometry too repeaters == hubs! Two issues relating to cable length: faintness of signal window of opportunity for an undetected collision scaling to 100Mbps; min packet revisited collisions and hubs collisions and switches Exponential backoff algorithm Transmit immediately when line is free. This leads to a collision if someone else was waiting also. After N collisions (including N=1): choose a random k, 0<=k<2^N (choose an N-bit random k) wait k slots try again to transmit. Options: idle/seize_channel, idle/collide, busy hidden bias against hosts that have been waiting longest: "unfairness" Timeline of typical exponential backoff Ethernet myths re capacity