Question? Leave a message!




Transport Layer of Computer Communication Networks (CCN)

Transport Layer of Computer Communication Networks (CCN)
Computer Communication Networks (CCN) 1Chapter Goals • Understand principles behind transport layer services: – multiplexing/demultiplexing – reliable data transfer – flow control – congestion control • Instantiation and implementation in the Internet Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 2Chapter Overview • Transport layer services • Multiplexing/demultiplexing • Connectionless transport: UDP • Principles of reliable data transfer • Connectionoriented transport: TCP – reliable transfer – flow control – connection management • Principles of congestion control • TCP congestion control Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 3Transport services and protocols • Provide logical communication between app’ processes running on different hosts • Transport protocols run in end systems • Transport vs. network layer services: – network layer: data transfer between end systems – transport layer: data transfer between processes – Relies on, enhances, network layer services Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 4Transport Services and Protocols application transport network data link network physical data link network physical data link physical network data link physical network data link physical network data link physical application transport network data link physical Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 5Transportlayer protocols Internet transport services: • Reliable, inorder unicast delivery (TCP) – congestion – flow control – connection setup • Unreliable (“besteffort”), unordered unicast or multicast delivery: UDP • Services not available: – realtime – bandwidth guarantees – reliable multicast Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 6Multiplexing / demultiplexing Recall: segment unit of data Demultiplexing: delivering exchanged between received segments to transport layer entities correct app layer processes – aka TPDU: transport protocol data unit receiver P3 P4 applicationlayer M M data application segment P1 P2 transport M header M network application application transport segment H M transport t network segment H network n Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 7Multiplexing / demultiplexing Multiplexing: gathering data from multiple 32 bits app processes, enveloping source port dest port data with header (later used for demultiplexing) other header fields multiplexing/demultiplexing: • based on sender, receiver port numbers, IP application addresses data – source, dest port s in (message) each segment – recall: wellknown port numbers for specific applications TCP/UDP segment format Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 8Multiplexing/demultiplexing: examples source port: x Web client dest. port: 23 server B host A host C source port:23 dest. port: x Source IP: C Source IP: C Dest IP: B Dest IP: B source port: y source port: x dest. port: 80 dest. port: 80 port use: simple telnet app Source IP: A Web Dest IP: B Web client source port: x server B dest. port: 80 host A port use: Web server Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 9UDP: User Datagram Protocol RFC 768 • “no frills,” “bare bones” Internet transport protocol • “best effort” service, UDP segments may be: – lost – delivered out of order to app • connectionless: – no handshaking between UDP sender, receiver – each UDP segment handled independently of others Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 10UDP: User Datagram Protocol RFC 768 Why is there a UDP • no connection establishment (which can add delay) • simple: no connection state at sender, receiver • small segment header • no congestion control: UDP can blast away as fast as desired. – May not be a good idea, though Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 11UDP: more • Often used for streaming multimedia apps – loss tolerant – rate sensitive • Other UDP uses (why): – DNS – SNMP • Reliable transfer over UDP: add reliability at application layer – applicationspecific error recovery Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 12UDP: more 32 bits source port dest port Length, in bytes of UDP checksum length segment, including header Application data (message) UDP segment format Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 13Error Detection and Correction • Single biterrors vs Burst Errors 110101  100101 vs 100001 • nbit codeword = m message bits + r check bits • Hamming Distance = of different bits 1010101 1001010 0011111  Hamming distance = 5 • Distance d code = minimum Hamming distance between any two code words written in the code • To detect dbit errors, distance d+1 code required • To correct dbit errors, distance 2d+1 code required Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 14Parity Checks 1 0 1 1 1 0 1 0 1 2 3 4 5 6 7 8 9 Odd Parity 1 0 1 1 1 0 1 0 0 0 0 1 1 1 0 1 0 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1bit error 0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 1 0 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 3bit error 2bit error Even Parity 1 0 1 1 1 0 1 1 0 1 2 3 4 5 6 7 8 9 Parity is a distance 2 code = can detect 1bit errors Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 15UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: • treat segment contents as sequence of 16 bit integers • checksum: addition (1’s complement sum) of segment contents • sender puts checksum value into UDP checksum field • In reality some IP header fields are included w/ the UDP segment for checksumming. Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 16UDP checksum Receiver: • compute checksum of received segment • check if computed checksum equals checksum field value: – NO error detected – YES no error detected. • But maybe errors nonetheless • More in chap 5 on stronger error detection methods Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 17UDP Checksum Example • Consider three 16bit words: 0110011001100110 0101010101010101 0000111100001111 • (1’s complement) sum of first two 16bit words is: 1011101110111011 • Adding the third word to the above sum gives: 1100101011001010 • 1’s complement of this sum = invert 0’s and 1’s 0011010100110101 (this is the checksum field) • If no errors, sum of all four 16bit words (incl. Checksum) will be all 1s, I.e., 1111111111111111 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 18UDP Servers • Most UDP servers are “iterative” = a single server process receives and handles incoming requests on a “well known” port. • Can filter client requests based on incoming IP/port addresses or wild card filters • Port numbers may be reused, but packet is delivered to at most one endpoint. • Queues to hold requests if server busy Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 19Principles of Reliable Data Transfer • Important in app., transport, link layers • top10 list of important networking topics • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 20Reliable Data Transfer: Getting Started rdtsend(): called from above, deliverdata(): called by rdt (e.g., by app.). Passed data to to deliver data to upper deliver to receiver upper layer send receive side side udtsend(): called by rdt, rdtrcv(): called when packet to transfer packet over arrives on rcvside of channel unreliable channel to receiver Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 21Reliable Data Transfer: Getting Started We’ll: • incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) • consider only unidirectional data transfer – but control info will flow on both directions • use finite state machines (FSM) to specify sender, receiver Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 22Reliable Data Transfer: Getting Started event causing state transition actions taken on state transition state: when in state state event this “state” 1 2 actions next state uniquely determined by next event Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 23Rdt1.0: Reliable Transfer over a Reliable Channel • underlying channel perfectly reliable – no bit errors – no loss of packets • separate FSMs for sender, receiver: – sender sends data into underlying channel – receiver read data from underlying channel Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 24Rdt1.0: Reliable Transfer over a Reliable Channel (cont.) Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 25Rdt2.0: Channel with Bit Errors • Underlying channel may flip bits in packet – recall: UDP checksum to detect bit errors • The question: how to recover from errors: – acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 26Rdt2.0: Channel with Bit Errors (cont.) – negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors – sender retransmits pkt on receipt of NAK • new mechanisms in Rdt2.0 (beyond Rdt1.0): – error detection – receiver feedback: control msgs (ACK,NAK) rcvrsender Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 27Temporal Redundancy Model Packets • Sequence Numbers • CRC or Checksum Timeout • ACKs Status Reports • NAKs, • SACKs • Bitmaps Retransmissions • Packets • FEC information Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 28Reliability Models • Reliability = requires redundancy to recover from uncertain loss or other failure modes. • Two types of redundancy: – Spatial redundancy: independent backup copies • Forward error correction (FEC) codes • Problem: requires huge overhead, since the FEC is also part of the packet(s) it cannot recover from erasure of all packets – Temporal redundancy: retransmit if packets lost/error • Lazy: trades off response time for reliability • Design of status reports and retransmission optimization important Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 29Rdt2.0: FSM Specification sender FSM receiver FSM Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 30Rdt2.0: In Action (no errors) sender FSM receiver FSM Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 31Rdt2.0: In action (error scenario) sender FSM receiver FSM Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 32Reliability mechanisms learnt so far… • Mechanisms: – Checksum in pkts: detects pkt corruption – ACK: “packet correctly received” – NAK: “packet incorrectly received” – aka: stopandwait Automatic Repeat reQuest (ARQ) protocols • Reliability capabilities achieved: – An errorfree channel – A forward channel which has biterrors Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 33Rdt2.0 has a Fatal Flaw What happens if ACK/NAK corrupted • Reverse channel biterrors • Sender doesn’t know what happened at receiver What to do • Sender ACKs/NAKs receiver’s ACK/NAK Problem: What if sender ACK/NAK lost • Retransmit packet. Problem: if original pkt correctly received, this is a duplicate. Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 34Rdt2.0 has a Fatal Flaw (cont.) Handling duplicates, garbled ACK/NAKs: • sender adds sequence number to each pkt • sender retransmits current pkt if ACK/NAK garbled • receiver discards (doesn’t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 35Rdt2.1: Sender, Handles Garbled ACK/NAKs Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 36Rdt2.1: Receiver, Handles Garbled ACK/NAKs Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 37Rdt2.1: Discussion Sender: • seq added to pkt • two seq. ’s (0,1) will suffice. Why • must check if received ACK/NAK corrupted • twice as many states – state must “remember” whether “current” pkt has 0 or 1 seq. Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 38Rdt2.1: Discussion Receiver: • must check if received packet is duplicate – state indicates whether 0 or 1 is expected pkt seq • Note: receiver cannot know if its last ACK/NAK received OK at sender Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 39Reliability mechanisms learnt so far… • Mechanisms: – Checksum: detects corruption in pkts acks – ACK: “packet correctly received” – NAK: “packet incorrectly received” – Sequence number: identifies packet or ack – 1bit sequence number used only in forward channel aka: alternatingbit protocols • Reliability capabilities achieved: – An errorfree channel – A forward reverse channel with biterrors – Detects duplicates of packets/acks/naks Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 40Rdt2.2: a NAKfree Protocol • Same functionality as rdt2.1, using ACKs only. – Why bother • Instead of NAK, receiver sends ACK for last pkt received OK – Receiver must explicitly include seq of pkt being ACKed • Duplicate ACK at sender results in same action as NAK: retransmit current pkt Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 41Rdt2.2: a NAKfree Protocol sender FSM Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 42Mechanisms learnt so far… • Mechanisms: – Checksum: detects corruption in pkts acks – ACK: “packet correctly received” – Duplicate ACK: “packet incorrectly received” – Sequence number: identifies packet or ack • 1bit sequence number used both in forward reverse channel • Reliability capabilities achieved: – An errorfree channel – A forward reverse channel with biterrors – Detects duplicates of packets/acks – NAKs eliminated Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 43Rdt3.0: Channels with Errors and Loss New assumption: underlying channel can also lose packets (data or ACKs) – What’s the difference, anyway – Checksum, seq. , ACKs, retransmissions will help, but not enough Q: how to deal with loss – Sender waits until certain data or ACK lost, then retransmits – Yuck: drawbacks Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 44Rdt3.0: Channels with Errors and Loss Approach: sender waits “reasonable” amount of time for ACK • Retransmits if no ACK received in this time • if pkt (or ACK) just delayed (not lost): – retransmission will be duplicate, but use of seq. ’s already handles this – receiver must specify seq of pkt being ACKed • requires countdown timer Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 45Rdt3.0 Sender Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 46Rdt3.0 in Action Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 47Rdt3.0 in Action Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 48Mechanisms learnt so far… • Mechanisms: – Checksum: detects corruption in pkts acks – ACK: “packet correctly received” – Duplicate ACK: “packet incorrectly received” – Sequence number: identifies packet or ack • 1bit sequence number used both in forward reverse channel – Timeout only at sender • Reliability capabilities achieved: – An errorfree channel – A forward reverse channel with biterrors – Detects duplicates of packets/acks – NAKs eliminated – A forward reverse channel with packeterrors (loss) Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 49Performance of Rdt3.0 • rdt3.0 works, but performance stinks • example: 1 Gbps link, 15 ms e2e prop. delay, 1KB packet: 8kb/pkt T = = 8 microsec transmit 109 b/sec 8 microsec fraction of time = = 0.00015 Utilization = U = sender busy sending 30.016 msec – 1KB pkt every 30 msec 33kB/sec thruput over 1 Gbps link – Problem: network protocol limits use of physical resources Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 50Stop and Wait Efficiency No loss or biterrors t frame U= 2t +t prop frame t Data frame 1 = t prop 2 + 1 U Ack Data  Light in vacuum Ack = 300 m/s Light in fiber t Distance/Speed of Signal prop  = = = 200 m/s Frame size /Bit rate t frame Electricity Distance  Bit rate = 250 m/s = Frame size Speed of Signal Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 51Utilization: More Examples • Satellite Link: – Propagation Delay t = 270 ms prop Frame Size = 4000 bits = 500 bytes Data rate = 56 kbps  t = 4/56 = 71 ms frame  = t /t = 270/71 = 3.8 prop frame U = 1/(2+1) = 0.12 (too low ) • Short Link (eg: LAN): Note: no loss – 1 km = 5 s, or biterrors Rate=10 Mbps, Frame=500 bytes  t = 4k/10M= 400 s frame =t /t =5/400=0.012  U=1/(2+1)= 0.98 (great) prop frame Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 52StopandWait ARQ: w/ loss • P=Probability of biterror Tf 0  = T /T Tp p f • U=T /N (T +2T ) Nak f r f p 0 = 1/N (1+2) r i1 • N = i P (1P) r Nak 0 =1/(1P) • U=(1P)/(1+2) Ack Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 53Pipelined protocols Pipelining: sender allows multiple, “inflight”, yettobe acknowledged pkts – range of sequence numbers must be increased – buffering at sender and/or receiver – Also called “sliding window” protocols Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 54Pipelined protocols • Two generic forms of pipelined protocols: 1. goBackN 2. selective repeat A.k.a “sliding window” protocols Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 55Sliding Window Protocols: Efficiency Nt frame U= 2t +t prop frame t frame Data N t prop 2+1 = 1 if N2+1 Ack Note: no loss or biterrors Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 56GoBackN Sender: • kbit seq in pkt header k – Allows upto N = 2 – 1 packets inflight, unacked • “Window”: limit on of consecutive unacked pkts – In GBN, window = N Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 57GoBackN • ACK(n): ACKs all pkts up to, including seq n “cumulative ACK” – Sender may receive duplicate ACKs (see receiver) – Robust to losses on the reverse channel – Can pinpoint the first packet lost, but cannot identify blocks of lost packets in window • One timer for oldestinflight pkt • Timeout = retransmit pkt “base” and all higher seq pkts in window Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 58GBN: Sender Extended FSM Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 59GBN: Receiver Extended FSM Receiver: • ACKonly: always send ACK for correctlyreceived pkt with highest in order seq – may generate duplicate ACKs – need only remember expectedseqnum – A.k.a. “receiver window” Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 60GBN: Receiver Extended FSM • outoforder pkt: – discard (don’t buffer) no receiver buffering – ACK pkt with highest inorder seq Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 61GBN in action Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 62Mechanisms learnt so far… • Checksum: detects corruption in pkts acks • ACK: “packet correctly received” – Duplicate ACK: “packet incorrectly received” – Cumulative ACK: acks all pkts upto incl. seq • Sequence number: identifies packet or ack – 1bit sequence number used both in forward reverse channels – kbit sequence number in both forward reverse channels • Timeout only at sender. – One timer for entire window • Window: sender and receiver side. Limits on what can be sent (or expected to be received). • Buffering at sender only Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 63Capabilities learnt so far… • Reliability capabilities achieved: – An errorfree channel – A forward reverse channel with biterrors – Detects duplicates of packets/acks – NAKs eliminated – A forward reverse channel with packet errors (loss) – Pipelining efficiency. • GobackN: Entire outstanding window retransmitted if pkt loss/error Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 64Selective Repeat • Receiver individually acknowledges all correctly received pkts – Buffers pkts, as needed, for eventual in order delivery to upper layer • Sender only resends pkts for which ACK not received – sender timer for each unACKed pkt • Sender window – N consecutive seq ’s – Limits seq s of sent, unACKed pkts Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 65Selective Repeat: Sender, Receiver Windows Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 66Selective Repeat Sender Data from above : • if next available seq in window, send pkt • timeout(n): – resend pkt n, restart timer • ACK(n) in sendbase,sendbase+N: – mark pkt n as received – if n smallest unACKed pkt, advance window base to next unACKed seq Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 67Selective repeat Receiver Pkt n in rcvbase, rcvbase+N1 • send ACK(n): “selective ack” • outoforder: buffer • inorder: deliver (also deliver buffered, in order pkts), advance window to next not yetreceived pkt pkt n in rcvbaseN,rcvbase1 • ACK(n) otherwise: • ignore Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 68Selective repeat in action Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 69Selective Repeat: Performance • Error Free: U = 1 if N2+1 1 N/(2+1) otherwise Nak 1 1 • With Errors: i1 N = i P (1P) r =1/(1P) • U= (1P) if N(1+2) N(1P)/(1+2) otherwise Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 70Selective Repeat: Dilemma Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 71Selective repeat: dilemma Example: • seq ’s: 0, 1, 2, 3 • window size=3 • receiver sees no difference in two scenarios • incorrectly passes duplicate data as new in (a) Q: what relationship between seq size and window size A: sequence space = 2window Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 72Reliability Mechanisms: Summary • Checksum: detects corruption in pkts acks • ACK: “packet correctly received” – Duplicate ACK: “packet incorrectly received” – Cumulative ACK: acks all pkts upto incl. seq (GBN) – Selective ACK: acks pkt “n” only (selective repeat) • Sequence number: identifies packet or ack – 1bit sequence number used both in forward reverse channels – kbit sequence number in both forward reverse channels. k • Let N = 2 – 1 = sequence number space size Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 73Reliability Mechanisms: Summary • Timeout only at sender. – One timer for entire window (gobackN) – One timer per pkt (selective repeat) • Window: sender and receiver side. – Limits on what can be sent (or expected to be received). – Window size (W) upto N –1 (GobackN) – Window size (W) upto N/2 (Selective Repeat) • Buffering – Only at sender (GobackN) – Outoforder buffering at sender receiver (Selective Repeat) Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 74Reliability capabilities: Summary • Reliability capabilities achieved: – An errorfree channel – A forward reverse channel with biterrors – Detects duplicates of packets/acks – NAKs eliminated – A forward reverse channel with packeterrors (loss) – Pipelining efficiency. • GobackN: Entire outstanding window retransmitted if pkt loss/error • Selective Repeat: only lost packets retransmitted – performance penalty if ACKs lost (because acks noncumulative) more complexity Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman © Biplab Sikdar 75