1 / 28

CS 372 – introduction to computer networks* Thursday July 8

Announcements: Lab 3 is posted and due is Monday July 19. Midterm is Wednesday July 21. CS 372 – introduction to computer networks* Thursday July 8. * Based in part on slides by Bechir Hamdaoui and Paul D. Paulson. Acknowledgement: slides drawn heavily from Kurose & Ross.

keiran
Télécharger la présentation

CS 372 – introduction to computer networks* Thursday July 8

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: Lab 3 is posted and due is Monday July 19. Midterm is Wednesday July 21. CS 372 – introduction to computer networks*Thursday July 8 * Based in part on slides by Bechir Hamdaoui and Paul D. Paulson. Chapter 3, slide: Acknowledgement: slides drawn heavily from Kurose & Ross

  2. 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:

  3. 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:

  4. 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:

  5. Sender: seq # added to pkt two seq. #’s (0,1) will suffice. Why? New pkt Retransmitted pkt 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:

  6. 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:

  7. 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:

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

  9. rdt3.0 in action (still stop-n-wait w/ (0,1) sn) rcv ACK1 do nothing Chapter 3, slide:

  10. rdt3.0 works, but performance stinks example: R=1 Gbps, 15 ms e-e prop. delay, 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:

  11. rdt3.0 works, but performance stinks example: R=1 Gbps, 15 ms e-e prop. delay, 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:

  12. rdt3.0 works, but performance stinks example: R=1 Gbps, 15 ms e-e prop. delay, 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:

  13. 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:

  14. 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:

  15. Go-Back-N: sender Sender: • k-bit seq # in pkt header • “window” of up to N, consecutive unACKed pkts allowed • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” • may receive duplicate ACKs (see receiver) • timeout(n): retransmit pkt n and all higher seq # pkts in window Chapter 3, slide:

  16. ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don’t buffer) -> no receiver buffering! Re-ACK pkt with highest in-order seq # GBN: receiver extended FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) Chapter 3, slide:

  17. GBN in action Chapter 3, slide:

  18. 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 again limits seq #s of sent, unACKed pkts Selective Repeat Chapter 3, slide:

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

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

  21. 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 Is this a pb in GBN? Why? doesn’t buffer out-of-order Selective repeat:dilemma Q: what relationship between seq # size and window size to avoid duplication problem?? Chapter 3, slide:

  22. 1 Transport-layer services 2 Multiplexing and demultiplexing 3 Connectionless transport: UDP 4 Principles of reliable data transfer 5 Connection-oriented transport: TCP 6 Principles of congestion control 7 TCP congestion control Chapter 3 outline Chapter 3, slide:

  23. Why need to estimate RTT? “timeout” and “retransmit” needed to address pkt loss need to know when to timeout and retransmit Ideal world: exact RTT is needed Real world: RTTs change over time bcause pkts may take different paths network load changes over time RTTs can only be estimated Some intuition What happens if too short: premature timeout unnecessary retransmissions What happens if too long: slow reaction to segment loss TCP Round Trip Time (RTT) and Timeout Chapter 3, slide:

  24. TCP Round Trip Time (RTT) and Timeout Technique: Exponential Weighted Moving Average (EWMA) EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT • 0 < < 1; typical value:  = 0.125 • SampleRTT: • measured time from segment transmission until ACK receipt • current value of RTT • Ignore retransmission • EstimatedRTT: • estimated based on past & present; smoother than SampleRTT • to be used to set timeout period Chapter 3, slide:

  25. TCP Round Trip Time (RTT) and Timeout Technique: Exponential Weighted Moving Average (EWMA) EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT • 0 < < 1; typical value:  = 0.125 • Example • Suppose 3 ACKs returned with SampleRTT1, SampleRTT2, and SampleRTT3. • Question: What would be EstimatedRTT after receiving the 3ACKs ? Assume that EstimatedRTT1 = SampleRTT1 Chapter 3, slide:

  26. TCP Round Trip Time (RTT) and Timeout Technique: Exponential Weighted Moving Average (EWMA) EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT • 0 < < 1; typical value:  = 0.125 • What happens if  is too small (say very close 0): • A sudden, real change in network load does not get reflected in EstimatedRTT fast enough • May lead to under- or overestimation of RTT for a long time • What happens if  is too large(say very close 1): • Transient fluctuations/changes in network load affects EstimatedRTT and makes it unstable when it should not • Also leads to under- or overestimation of RTT Chapter 3, slide:

  27. Example RTT estimation: Chapter 3, slide:

  28. Setting the timeout timeout = EstimtedRTT, any problem with this??? add a “safety margin” to EstimtedRTT large variation in EstimatedRTT -> larger safety margin see how much SampleRTT deviates from EstimatedRTT: TCP Round Trip Time (RTT) and Timeout DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT Chapter 3, slide:

More Related