1 / 93

ECE/CS 372 – introduction to computer networks Lecture 7

Announcements: HW1 is due today LAB2 is due tomorrow. ECE/CS 372 – introduction to computer networks Lecture 7. Acknowledgement: slides drawn heavily from Kurose & Ross. Our goals: understand principles behind transport layer services: reliable data transfer flow control

avian
Télécharger la présentation

ECE/CS 372 – introduction to computer networks Lecture 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Announcements: HW1 is due today LAB2 is due tomorrow ECE/CS 372 – introduction to computer networksLecture 7 Chapter 3, slide: Acknowledgement: slides drawn heavily from Kurose & Ross

  2. Our goals: understand principles behind transport layer services: reliable data transfer flow control congestion control learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport TCP congestion control Chapter 3: Transport Layer Chapter 3, slide:

  3. provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical application transport network data link physical logical end-end transport Transport services and protocols Chapter 3, slide:

  4. network layer: logical communication between hosts transport layer: logical communication between processes Household case: 12 kids (East coast house) sending letters to 12 kids (West coast house) Ann is responsible for the house at East coast Bill is responsible for the house at West coast Postal service is responsible for between houses Transport vs. network layer • Household analogy: • kids = processes • letters = messages • houses = hosts • home address = IP address • kid names = port numbers • Ann and Bill = transport protocol • postal service = network-layer protocol Chapter 3, slide:

  5. reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP services not available: delay guarantees bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Internet transport-layer protocols Chapter 3, slide:

  6. “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 Why is there a UDP? less delay: no connection establishment (which can add delay) simple: no connection state at sender, receiver less traffic: small segment header no congestion control: UDP can blast away as fast as desired UDP: User Datagram Protocol [RFC 768] Chapter 3, slide:

  7. often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! UDP: more 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format Chapter 3, slide:

  8. 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 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? …. UDP checksum • Goal: detect “errors” (e.g., flipped bits) in transmitted segment Chapter 3, slide:

  9. Internet Checksum Example • Note • When adding numbers, a carryout from the most significant bit needs to be added to the result • Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound sum checksum Chapter 3, slide:

  10. Principles of reliable data transfer Connection-oriented transport: TCP Principles of congestion control TCP congestion control Chapter 3 outline Chapter 3, slide:

  11. important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Principles of Reliable data transfer Chapter 3, slide:

  12. important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Principles of Reliable data transfer Chapter 3, slide:

  13. important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Principles of Reliable data transfer Chapter 3, slide:

  14. rdt_send():called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data():called by rdt to deliver data to upper udt_send():called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv():called when packet arrives on rcv-side of channel Reliable data transfer: getting started send side receive side Chapter 3, slide:

  15. We will: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer use finite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event event state 1 state 2 actions Reliable data transfer: getting started Chapter 3, slide:

  16. 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 rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) sender receiver rdt1.0: reliable transfer over a reliable channel Chapter 3, slide:

  17. underlying channel may flip bits in packet Receiver can detect bit errors (e.g., use checksum) But still no packet loss questions: (1) how does sender know and (2) what does it do when packet is erroneous: acknowledgements: positive ack (ACK): receiver tells sender that pkt received OK negative ack (NAK): receiver tells sender that pkt had erros retransmission: sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender assume ACK/NAK are error free rdt2.0: channel with bit errors Chapter 3, slide:

  18. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: operation with no errors rdt_send(data) receiver snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Chapter 3, slide:

  19. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) : errordt2.0r scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Chapter 3, slide:

  20. What happens if ACK/NAK is corrupted? That is, sender receives garbled ACK/NAK sender doesn’t know what happened at receiver! can’t sender just retransmit? Sure: sender retransmits current pkt if ACK/NAK garbled Any problem with this ?? Handling duplicates: sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt stop and wait stop and wait stop and wait Sender sends one packet, then waits for receiver response Sender sends one packet, then waits for receiver response rdt2.0 has a fatal flaw! Problem: duplicate Receiver doesn’t know whether received pkt is a retransmit or a new pkt Chapter 3, slide:

  21. Wait for ACK or NAK 0 Wait for call 1 from above Wait for ACK or NAK 1 rdt2.1: sender, handles garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) Wait for call 0 from above udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) Chapter 3, slide:

  22. Wait for 0 from below Wait for 1 from below rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Chapter 3, slide:

  23. 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. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # note: receiver can not know if its last ACK/NAK received OK at sender rdt2.1: discussion Chapter 3, slide:

  24. do we really need NAKs?? 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 rdt2.2: same functionality as rdt2.1, using ACKs only rdt2.2: a NAK-free protocol Chapter 3, slide:

  25. New assumption: packet may be lost: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough What else is needed? Approach: timeout policy: 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 rdt3.0: channels with errors and loss Chapter 3, slide:

  26. Announcements: LAB2 is due today HW2 is posted and is due Tuesday next week LAB3 is posted and is due Tuesday next week ECE/CS 372 – introduction to computer networksLecture 8 Chapter 3, slide: Acknowledgement: slides drawn heavily from Kurose & Ross

  27. rdt3.0 in action (still stop-n-wait w/ (0,1) sn) Chapter 3, slide:

  28. rdt3.0 in action (still stop-n-wait w/ (0,1) sn) Chapter 3, slide:

  29. rdt3.0 works, but performance stinks example: R=1 Gbps, RTT=30 ms, L=1000Byte packet: sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives L (packet length in bits) 8.103 b/pkt T = = = 8 microsec RTT last packet bit arrives, send ACK transmit R (transmission rate, bps) 109 b/sec ACK arrives, send next packet, t = RTT + L / R Performance of rdt3.0: stop-n-wait Chapter 3, slide:

  30. rdt3.0 works, but performance stinks example: R=1 Gbps, RTT=30 ms, L=1000Byte packet: sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Performance of rdt3.0: stop-n-wait • U sender: utilization – fraction of time sender busy sending Chapter 3, slide:

  31. rdt3.0 works, but performance stinks example: R=1 Gbps, RTT=30 ms, L=1000Byte packet: sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Performance of rdt3.0: stop-n-wait • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • network protocol limits use of physical resources! Chapter 3, slide:

  32. Increase utilization by a factor of 3! Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Question: What is the link utilization Usender Chapter 3, slide:

  33. Acknowledgment and retransmission Reliable delivery Sequence numbers Duplication detection Timeout and retransmit Deal with packet losses Stop-n-wait one packet at a time Problem: efficiency So far: rdt3.0 Chapter 3, slide:

  34. Pipelining: sender allows multiple, “in-flight”, yet-to-be-ACK’ed pkts What about the range of sequence numbers then?? What about buffering at receiver?? Two generic forms of pipelined protocols: go-Back-N and selective repeat Pipelined protocols Chapter 3, slide:

  35. Go-Back-N • Sender side • N pckts can be sent w/o being ACK’ed, “sliding window” • Single timer, oldest non-ACK’ed pckt • At timeout(n), retransmit pkt n and all successive pkts • Receiver side • Cumulative ACK • Discard out-of-order packets, no buffering Chapter 3, slide:

  36. GBN? GBN? GBN? Selective repeat in action Chapter 3, slide:

  37. Selective Repeat Sliding window N pckts on the fly Selective ACK One timer for each pckt Buffer out-of-order pksts Retransmit only lost or delayed pkt at timeout Selective Repeat via comparison • Go-Back-N • Sliding window • N pckts on the fly • Cumulative ACK • Single timer • Discard out-of-order • pkts • Retransmit all successive pkts at timeout Chapter 3, slide:

  38. Example: seq #’s: 0, 1, 2, 3 window size=3 Selective repeat:dilemma Chapter 3, slide:

  39. Example: seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! Even though, (a) is a retransmit pkt (b) is a new pkt in (a), receiver incorrectly passes old data as new Selective repeat:dilemma Q: what relationship between seq # size and window size to avoid duplication problem?? Chapter 3, slide:

  40. Duplication problem: illustration • Let’s assume window size W = 2 for illustration • Consider a scenario where: Only ACK 1 is lost • Now let’s assume that seqNbr space n = W =2 That is, seqNbr pattern is 0,1,0,1,0,1,…

  41. Duplication problem: illustration Scenario: n=W=2; only ACK 1 is lost Receiver thinks of retransmission of 2nd Pkt (Pkt1, SN=1) as a 4th/new Pkt (Pkt3,SN=1)  Duplication detection problem!

  42. Duplication problem: illustration Recap: • When window size W = seqNbr space n,  there is a duplication problem  receiver can’t tell a new transmission from a retransmission of a lost pkt • Let’s now see what happens if we increase n by 1: Now n=3 and seqNbr pattern is: 0,1,2,0,1,2,0… • Let’s revisit the scenario again

  43. Duplication problem: illustration Scenario: n=3;W=2; ACK 1 is lost Receiver still thinks of retrans. of 2nd Pkt (Pkt1, SN=1) as a new Pkt (4th w/ SN=1)  Increasing n by 1 didn’t solve the duplication detection problem this time!!

  44. Duplication problem: illustration Recap: • Increasing seqNbr space n from 2 to 3 didn’t solve the duplication problem yet! • Let’s now see what happens if we again increase n by 1: Now n=4 and seqNbr pattern is: 0,1,2,3,0,1,2,3,0… • Let’s revisit the scenario with n=4 and see

  45. Duplication problem: illustration Scenario: n=4;W=2; ACK 1 is lost Receiver now drops this retransmission of 2nd Pkt (Pkt1, SN=1) since its SN falls outside  Duplication detection problem is now solved when n=4 w=2

  46. Duplication problem: illustration Recap: • Increasing seqNbr space n from 2 to 4 did solve the duplication problem • That is, when seqNbr space = twice window size (n = 2w) the duplication problem was solved • Hence, in this case: when W ≤ n/2, the problem is solved • Can we generalize? Yes, W ≤ n/2 must hold in order to avoid dup problem

  47. SeqNbr space n & window size w relationship: general case seqNbr space • Sender: • Suppose ½ n < W < n • W segments with seqNbr in [0, W-1] are sent, but their ACKs are not received yet n-1 0 1 W-1 w pkts already sent, but ACKs not received yet = sender’s sliding window

  48. SeqNbr space n & window size w relationship: general case seqNbr expected by receiver • Receiver: Now assume: • receiver received all W segments (SeqNbr in [0,W-1]) • receiver sent all W ACKs, one for each received segment • receiver slides its window: Sliding window (SeqNbr of expected segments) from: W to x = 2W-n-1 Hint: (n-1-W+1) + (x-0+1)=W  x=2W–n-1 0 n-1 1 x=2W-n-1 W

  49. SeqNbr space n & window size w relationship: general case • Consider worst case scenario: all W ACKs are lost • Sender will re-transmit all the first W segments; i.e., with SeqNbr in [0,W-1] • But receiver is expecting segments with SeqNbr in [W,n-1] U [0,2W-n-1] • Retransmissions with seqNbr falling within [0,2W-n-1] will then be interpreted by receiver as new transmissions ( dup problem) To avoid dup problem, we must then have: 2W-n-1 ≤ -1  W ≤ ½ n seqNbr expected by receiver seqNbr overlap 0 n-1 x=2W-n-1 W seqNbr retransmitted by sender

  50. Announcements: HW2 and LAB3 are due Tuesday 4th week. A possible room change (Will send email with change if happened) Midterm July 19th, 2012 (Thursday 4th week) Ch1, Ch2, and Ch3. Make sure you review the material, HW, labs ECE/CS 372 – introduction to computer networksLecture 9 Chapter 3, slide: Acknowledgement: slides drawn heavily from Kurose & Ross

More Related