Presentation on theme: "1 TCP Congestion Control. 2 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement."— Presentation transcript:
1 TCP Congestion Control
2 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) RST, SYN, FIN: connection management (reset, setup teardown commands) # bytes rcvr willing to accept ACK: ACK # valid counting by bytes of data (not segments!) Also in UDP URG: urgent data (generally not used) PSH: push data now (generally not used)
3 TCP Flow Control receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than the most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast flow control receiver buffering RcvBuffer = size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer Questions: 1.What is the maximum size of RcvBuffer? 2. Can sender estimate the size of RcvBuffer? 3. Can receiver change its RcvBuffer size in the middle of a session? 4. Can Sender know the change?
4 Outline Principle of congestion control TCP/Reno congestion control
5 Principles of Congestion Control Big picture: How to determine a flow’s sending rate? 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) wasted bandwidth long delays (queueing in router buffers) a top-10 problem!
6 History TCP congestion control in mid-1980s fixed window size w timeout value = 2 RTT Congestion collapse in the mid-1980s UCB LBL throughput dropped by 1000X!
7 Some General Questions How can congestion happen? What is congestion control? Why is congestion control difficult? Will congestion disappear in the future due to technology advances (e.g. faster links, routers)? How does TCP provide congestion control?
8 flow 2 (5 Mbps) flow 1 router 1router 2 10 Mbps 5 Mbps 20 Mbps Cause/Cost of Congestion: Scenario 1 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 The link from router 1 to router 2 has infinite buffer Throughput: packets go through 10 Mbps 20 Mbps sending rate by flow 1 (Mbps) Total throughput of flow 1 & 2 (Mbps) 5 10 sending rate by flow 1 (Mbps) Delay at link maximum achievable throughput large delays when congested 0 0 delay due to randomness
9 flow 2 (5 Mbps) flow 1 router 1 10 Mbps 5 Mbps 20 Mbps Cause/Cost of Congestion: Scenario 2 Assume No retransmission The link from router 1 to router 2 has finite buffer Throughput: packets go through 5 Mbps sending rate by flow 1 (Mbps) Total throughput of flow 1 & 2 (Mbps) when packet dropped at the link from router 2 to router 6, the upstream transmission from router 1 to router 2 used for that packet was wasted! 0 router 3 router 4 router 2 router 5 router 6 What if retransmission?
10 Summary: The Cost of Congestion Cost High delay 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) Load Delay Throughput kneecliff congestion collapse packet loss
11 Approaches towards congestion control End-end congestion control: no explicit feedback from network congestion inferred from end- system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at Two broad approaches towards congestion control:
12 Open-loop vs. Closed-loop Open-loop: A flow does not adjust its sending rate dynamically according to the status of the network Need reservation to avoid congestion collapse Closed-loop: A flow adjusts its rate dynamically according to the status of the network
13 End-to-end vs. Hop-by-hop End-to-end congestion control: A flow determines its rate Hop-by-hop: Routers on the path implement flow control between each other e.g. ATM credit-based Scheduling for flows at a link
14 Implicit vs. Explicit 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)
15 Window-based: Congestion control by controlling the window size of a transport scheme, e.g. set window size to 64KBytes Example: TCP Rate-based: Congestion control by explicitly controlling the sending rate of a flow, e.g. set sending rate to 128Kbps Example: ATM Rate-based vs. Window-based
16 Self-Clocking of Window-based Schemes
17 Outline TCP Overview Principle of congestion control TCP/Reno congestion control
18 TCP Congestion Control Closed-loop, end-to-end, implicit, window-based congestion control Transmission rate limited by congestion window size, cwnd, over segments: w segments, each with MSS bytes sent in one RTT: throughput w * MSS RTT Bytes/sec cwnd
19 TCP Congestion Control: Basic Question Ideally, we want to set the window size (approximately) to the product of available bandwidth (for this flow) and round-trip delay However, We don’t know these parameters at the beginning of a flow Further, the available bandwidth and round-trip are changing, because of competing flows
20 TCP Congestion Control: Basic Structure Two “phases” SlowStart congestion avoidance (AIMD) Important variables: cwnd: congestion window size ssthresh: threshold between the slow-start phase and the congestion avoidance phase Many versions of TCP TCP/Tahoe: this is a less optimized version TCP/Reno: this is what we are talking about today; most OSs today implement TCP/Reno TCP/Vegas: currently not used
22 TCP AIMD AIMD [Jacobson 1988]: Additive Increase : In every RTT W = W + 1*MSS Multiplicative Decrease : Upon a congestion event W = W/2 Sender Receiver TCP Acknowledgment Packets 0 Time Congestion Window Size AI MD 1 RTT Data Packets Network
23 TCP Slow Start When connection begins, CongWin = 1 MSS Example: MSS = 500 bytes & RTT = 200 msec initial rate = 20 kbps available bandwidth may be >> MSS/RTT desirable to quickly ramp up to respectable rate When connection begins, increase rate exponentially fast until first loss event double CongWin every RTT done by incrementing CongWin for every ACK received Why call it slowstart: initial rate is slow but ramps up exponentially fast
25 Fast Retransmit After 3 dup ACKs: CongWin is cut in half window then grows linearly But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially to a threshold, then grows linearly 3 dup ACKs indicates network capable of delivering some segments timeout before 3 dup ACKs is “more alarming” Philosophy:
26 Fast Recovery Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event
27 TCP/Reno: Big Picture Time cwnd slow start congestion avoidance TD TD: Triple duplicate acknowledgements TO: Timeout TO ssthresh congestion avoidance TD congestion avoidance slow start congestion avoidance
28 Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.