1 / 16

Lecture 9: TCP and Congestion Control

This lecture covers the implementation of TCP's sliding window protocol for flow control and explores different congestion control techniques used in TCP. It explains the challenges in determining network congestion and how TCP adjusts its sending rate based on congestion signals like packet loss and duplicate acknowledgements.

rodriguezsusan
Télécharger la présentation

Lecture 9: TCP and Congestion Control

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. Lecture 9:TCP and Congestion Control ITCS 6166/8166 091 Spring 2007 Jamie Payton Department of Computer Science University of North Carolina at Charlotte February 7, 2007 Slides adapted from: Congestion slides for Computer Networks: A Systems Approach (Peterson and Davis) Chapter 3 slides for Computer Networking: A Top Down Approach Featuring the Internet (Kurose and Ross)

  2. Announcements • Homework 2 is available • Due: Feb. 14 • Schedule change • Updated on primary course website • Additional homework before midterm • Lab 1 due date changed

  3. Transmission Control Protocol • Implementation of sliding window protocol TCP uses sliding windows at sender and receiver (buffers) TCP Segment (Packet) Structure

  4. Flow Control • What happens if the receiving process is slow and the sending process is fast? • TCP provides flow control • sender won’t overflow receiver’s buffer by transmitting too much, too fast

  5. Window “Syndromes” • Silly Window Syndrome • Sender has data available to send • Flow control reduces effective window to very small size • Size of segment dominated by the header information • Tinygram Syndrome • Sender doesn’t have much data to send • Size of segment dominated by the header information • Nagle’s algorithm combats this problem • Coalesces small messages into a single segment if some data is currently unack’d

  6. Congestion: Informally: “too many sources sending too much data too fast for network to handle” Different from flow control! Manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) A top-10 problem in computer network research! Congestion Control

  7. TCP Congestion Control • Idea • assumes best-effort network (FIFO or FQ routers) • each source determines network capacity for itself • uses implicit feedback • ACKs pace transmission (self-clocking) • Challenges • determining the available capacity in the first place • adjusting to changes in the available capacity

  8. TCP Congestion Control Principles • Simple idea • Congestion: reduce sending rate • No congestion: increase sending rate • How does the source determine whether or not the network is congested? • Lost packets! • Timeout signals that a packet was lost • Duplicate acknowledgements signal packet was lost (later...) • How is rate controlled in TCP? • Control congestion window size • Rate approximately congestion window size / RTT

  9. TCP Congestion Control Components • Additive Increase/Multiplicative Decrease • Slow start • Fast Retransmit and Fast Recovery

  10. Additive Increase Multiplicative Decrease • New state variable per connection: CongWin • Counterpart to flow control’s advertised window • Limits how much data is in transit MaxWin = MIN(CongWin, AdvertisedWindow) EffWin = MaxWin - (LastByteSent - LastByteAcked) • Congestion control approach: • increase CongWin when congestion goes down • decrease CongWin when congestion goes up • Now EffectiveWindow includes both flow control and congestion control

  11. time Additive Increase Multiplicative Decrease • Approach: • increase transmission rate, probing for usable bandwidth, until loss occurs • additive increase: increase CongWin by 1 MSS every RTT until loss detected • multiplicative decrease: cut CongWin in half after loss Host A Host B one segment RTT two segments Three segments

  12. Host A Host B one segment RTT two segments four segments time Slow Start • Objective: determine the available capacity at first • increase congestion window rapidly from a cold start • Idea: • begin with CongWin = 1 packet • doubleCongWin each RTT • Implemented : increment by 1 packet for each ACK

  13. 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 Initially set to large value Refinement 1

  14. Refinement 2 • Philosophy • Duplicate ACKs also indicate loss • 3 duplicate ACKs indicates network capable of delivering some segments • Timeout indicates a “more alarming” congestion scenario • Fast recovery • skip the slow start phase • go directly to threshold • half the last successful CongWin

  15. TCP Flavors • TCP Tahoe • Slow start • Switch to AIMD when hit threshold • Handling loss • Unconditional reduction of window to 1 MSS • TCP Reno • Slow start • Switch to AIMD when hit threshold • Handling loss • Reduction of window to ½ when triple duplicate ACKS • “Fast recovery”: skip slow start, go to threshold

  16. Summary: TCP Reno • 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

More Related