1 / 50

Computer Networks

Computer Networks. Lecture 17 Congestion Control; AIMD; TCP Reno 10/31/2013. Admin.: Assignment 4. Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11:55 pm, Nov. 15 Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11:55 pm, Nov. 19.

urban
Télécharger la présentation

Computer Networks

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. Computer Networks Lecture 17 Congestion Control; AIMD; TCP Reno 10/31/2013

  2. Admin.: Assignment 4 Part 1: Design discussion with instructor or a TF: Nov. 11; Code check point: 11:55 pm, Nov. 15 Part 2: Design discussion with instructor or a TF: Nov. 14; Code and report: 11:55 pm, Nov. 19. proj-sol (part 1): 129 400 3045 FishThread.java 388 1457 12873 Node.java 51 167 1145 PingRequest.java 83 250 2106 SimpleTCPSockSpace.java 181 605 5248 TCPManager.java 889 3088 26381 TCPSock.java 60 149 1316 TCPSockID.java 123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 2051 6998 61039 total proj: 129 400 3045 FishThread.java 341 1301 11313 Node.java 51 167 1145 PingRequest.java 50 128 909 TCPManager.java 132 460 3146 TCPSock.java 123 382 3866 TransferClient.java 147 500 5059 TransferServer.java 973 3338 28483 total

  3. Recap: Connection Management • Connection setup: • agree on initial sequence numbers to avoid accepting duplicate/out of order packets • Internet solution: Three-Way-Handshake (TWH) • Connection close • both sides can release allocated resources • Internet solution: time wait

  4. CLOSED SYN SENT SYN ESTABLSIHED ACK SYN/ACK FIN ACK %netstat -t -a CLOSED LISTEN SYN RCVD ESTABLSIHED ESTABLSIHED ESTABLSIHED FINWAIT 1 FIN CLOSEWAIT LASTACK FINWAIT 2 TIMEWAIT ACK

  5. A Summary of Questions • How to improve the performance of rdt3.0? • sliding window protocols • What if there are duplication and reordering? • network guarantee: max packet life time • transport guarantee: sender not reuses a seq# before life time • seq# management and connection management • How to determine the “right” parameters?

  6. History • Key parameters for TCP in mid-1980s • fixed window size W • timeout value = 2 RTT • Network collapse in the mid-1980s • UCB  LBL throughput dropped by 1000X ! • Blamed timeout and fixed window size

  7. Ideal timeout = RTT too short: premature timeout unnecessary retransmissions/duplicates too long: slow reaction to segment loss Measure RTT: measuretime from segment transmission until ACK receipt Timeout

  8. From Ideal to Implementation • Problem: SampleRTTvary, want a “smoother”estimated RTT • use several recent measurements, not just current SampleRTT EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT • Exponential weighted moving average • influence of past sample decreases exponentially fast • typical value:  = 0.125

  9. Problem: using the average of SampleRTT will generate many timeouts due to network variations Solution: EstimtedRTT plus “safety margin” Q: what is margin in original TCP Margin should depend on variation: large variation in EstimatedRTT -> larger safety margin RTT Setting Timeout

  10. freq. RTT TCP Timeout DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT

  11. An Example TCP Session

  12. A Summary of Questions • How to improve the performance of rdt3.0? • sliding window protocols • What if there are duplication and reordering? • network guarantee: max packet life time • transport guarantee: sender not reuses a seq# before life time • seq# management and connection management • How to determine the “right” parameters? • timeout: mean + variation • sliding window size

  13. Big picture: How to determine a flow’s sending rate? a top-10 problem! Congestion: informally: “too many sources sending too much data too fast for the network to handle” different from flow control ! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) wasted bandwidth Principles of Congestion Control

  14. Some General Questions • How can congestion happen? • What is congestion control? • Why is congestion control difficult?

  15. Cause/Cost of Congestion: Single Bottleneck flow 1 5 Mbps 20 Mbps 10 Mbps 20 Mbps flow 2 (5 Mbps) 20 Mbps router 1 router 2 • - Flow 2 has a fixed sending rate of 5 Mbps • - We vary the sending rate of flow 1 from 0 to 20 Mbps • - Assume • no retransmission; link from router 1 to router 2 has infinite buffer delay at central link throughput: e2e packets delivered in unit time Delay? throughput of flow 1 & 2 (Mbps) sending rate by flow 1 (Mbps) 10 5 0 sending rate by flow 1 (Mbps) 5 5 0

  16. Cause/Cost of Congestion: Single Bottleneck router 5 router 3 flow 1 5 Mbps 20 Mbps 10 Mbps 20 Mbps flow 2 (5 Mbps) 20 Mbps router 2 router 1 router 4 router 6 • Assume • no retransmission • the link from router 1 to router 2 has finite buffer • throughput: e2e packets delivered in unit time • Zombie packet: a packet dropped at the link from router 2 to router 5; the upstream transmission from router 1 to router 2 used for that packet was wasted! throughput of flow 1 & 2 (Mbps) 10 sending rate by flow 1 (Mbps) 5 x 5 0

  17. packet loss knee cliff Throughput congestion collapse Load Delay Load Summary: The Cost of Congestion Cost • Packet loss • wasted upstream bandwidth when a pkt is discarded at downstream • wasted bandwidth due to retransmission (a pkt goes through a link multiple times) • High delay

  18. Outline • Admin and recap • Transport congestion control • what is congestion • congestion control

  19. Rate-based vs. Window-based Rate-based: • Congestion control by explicitly controlling the sending rate of a flow, e.g., set sending rate to 128Kbps • Example: ATM Window-based: • Congestion control by controlling the window size of a transport scheme, e.g., set window size to 64KBytes • Example: TCP Discussion: rate-based vs. window-based

  20. Window-based Congestion Control • A main advantage of window-based congestion control is self-clocking: considers flow conservation, andadjusts to RTT variation automatically

  21. cwnd * MSS throughput  Bytes/sec RTT Sliding Window Congestion Control • Transmission rate limited by congestion window size, cwnd, over segments: cwnd • Assume cwnd segments, each with MSS bytes sent in one RTT: MSS: Minimum Segment Size

  22. The Desired Properties of a Congestion Control Scheme • Efficiency: close to full utilization but low delay • fast convergence after disturbance • Fairness (resource sharing) • Distributedness (no central knowledge for scalability)

  23. A Simple Model User 1 x1 d =  xi > Xgoal? x2  User 2 xn User n Flows observe congestion signal d, and locally take actions to adjust rates.

  24. Linear Control • Proposed by Chiu and Jain (1988) • The simplest control strategy Discussion: values of the parameters?

  25. fairness line: x1=x2 x(0) efficiency line: x1+x2=C State Space of Two Flows x2 overload underload x1

  26. x0 efficiency: distributed linear rule x0 x0 fairness intersection congestion x0 efficiency

  27. Implication: Congestion (overload) Case • In order to get closer to efficiency and fairness after each update, decreasing of rate must be multiplicative decrease (MD) • aD = 0 • bD < 1

  28. no-congestion x0 efficiency: distributed linear rule x0 x0 fairness convergence x0 efficiency

  29. Implication: No Congestion Case • In order to get closer to efficiency and fairness after each update, additive and multiplicative increasing (AMI), i.e., • aI > 0, bI > 1 • Simply additive increase gives better improvement in fairness (i.e., getting closer to the fairness line) • Multiplicative increase is faster

  30. Four Special Cases Discussion: state transition trace.

  31. fairness line:x1=x2 overload efficiency line: x1+x2=C underload AIMD: State Transition Trace x2 x0 x1

  32. Another Look • Consider the difference or ratio of the rates of two flows • AIAD • MIMD • MIAD • AIMD

  33. Mapping A(M)I-MD to Protocol • What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?

  34. Mapping A(M)I-MD to Protocol • What do we need to apply the A(M)I-MD algorithm to a sliding window protocol?

  35. Implicit: congestion inferred by end systems through observed loss, delay Explicit: routers provide feedback to end systems explicit rate sender should send at single bit indicating congestion (SNA, DECbit, TCP ECN, ATM) Implicit vs. Explicit

  36. Outline • Admin and recap • Transport congestion control • what is congestion • congestion control principle • TCP congestion control: Reno

  37. TCP Congestion Control • Closed-loop, end-to-end, window-based congestion control • Designed by Van Jacobson in late 1980s, based on the AIMD alg. of Dah-Ming Chu and Raj Jain • Works well when the bandwidth of the Internet has increased by more than 200,000 times • Many versions • TCP/Tahoe: this is a less optimized version • TCP/Reno: many OSs today implement Reno type congestion control • TCP/Vegas: not currently used • TCP CUBIC For more details: see TCP/IP illustrated; or readhttp://lxr.linux.no/source/net/ipv4/tcp_input.c for linux implementation

  38. TCP/Reno Congestion Detection • Detect congestion (d) in two cases and react differently: • 3 dup ACKs • timeout event Philosophy: • 3 dup ACKs indicates network capable of delivering some segments • timeout is “more alarming”

  39. Basic Structure • Two “phases” • slow-start: MI • congestion avoidance: AIMD • Important variables: • cwnd: congestion window size • ssthresh: threshold between the slow-start phase and the congestion avoidance phase

  40. Visualization of the Two Phases

  41. Slow Start: MI • What is the goal? • getting to equilibrium gradually but quickly • Implements the MI algorithm • doublecwnd every RTT until network congested get a rough estimate of the optimal of cwnd

  42. segment 1 cwnd = 1 ACK for segment 1 segment 2 segment 3 ACK for segments 2 + 3 segment 4 segment 5 segment 6 segment 7 Slow-start Initially: cwnd = 1; ssthresh = infinite (e.g., 64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; cwnd = 2 cwnd = 4 cwnd = 6 cwnd = 8

  43. Startup Behavior with Slow-start See [Jac89]

  44. TCP/Reno Congestion Avoidance • Maintains equilibrium and reacts around equilibrium • Implements the AIMD algorithm • increases window by 1 per round-trip time (how?) • cuts window size • to half when detecting congestion by 3DUP • to 1 if timeout • if already timeout, doubles timeout

  45. TCP/Reno Congestion Avoidance Initially: cwnd = 1; ssthresh = infinite (e.g., 64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; else /* congestion avoidance; cwnd increases (approx.) by 1 per RTT */ cwnd += 1/cwnd; Triple-duplicate ACKs: /* multiplicative decrease */ cwnd = ssthresh = cwnd/2; Timeout: ssthresh = cwnd/2; cwnd = 1; (if already timed out, double timeout value; this is called exponential backoff)

  46. TCP/Reno: Big Picture cwnd TD TD TD TO ssthresh ssthresh ssthresh ssthresh Time congestion avoidance slow start congestion avoidance congestion avoidance slow start congestion avoidance TD: Triple duplicate acknowledgements TO: Timeout

  47. A Session Question: when cwnd is cut to half, why sending rate is not?

  48. Backup Slides

  49. High-level Idea Ideally, we set timeout = RTT, but RTT is not a fixed value (why?) Set timeout = average + safe margin

  50. High-level Idea Ideally, we set timeout = RTT, but RTT is not a fixed value (why?) Set timeout = average + safe margin

More Related