1 Congestion Control EE122 Fall 2012 Scott Shenker Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson.

Slides:



Advertisements
Similar presentations
CS144 Review Session 4 April 25, 2008 Ben Nham
Advertisements

1 EE 122:TCP Congestion Control Ion Stoica TAs: Junda Liu, DK Moon, David Zats (Materials with thanks to Vern Paxson,
Congestion Control Jennifer Rexford Advanced Computer Networks Tuesdays/Thursdays 1:30pm-2:50pm.
Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project.
TCP Congestion Control Dina Katabi & Sam Madden nms.csail.mit.edu/~dina 6.033, Spring 2014.
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Fourth Edition,Peterson.
School of Information Technologies TCP Congestion Control NETS3303/3603 Week 9.
Transport Layer 3-1 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate.
TDC365 Spring 2001John Kristoff - DePaul University1 Internetworking Technologies Transmission Control Protocol (TCP)
Katz, Stoica F04 EECS 122: Introduction to Computer Networks Congestion Control Computer Science Division Department of Electrical Engineering and Computer.
Transport Layer3-1 Congestion Control. Transport Layer3-2 Principles of Congestion Control Congestion: r informally: “too many sources sending too much.
Congestion Control Reading: Sections COS 461: Computer Networks Spring 2011 Mike Freedman
Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Third Ed.,Peterson.
1 Congestion Control EE122 Fall 2011 Scott Shenker Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
15-744: Computer Networking L-10 Congestion Control.
CSCE 515: Computer Network Programming Chin-Tser Huang University of South Carolina.
Computer Networks : TCP Congestion Control1 TCP Congestion Control.
Networks : TCP Congestion Control1 TCP Congestion Control.
Networks : TCP Congestion Control1 TCP Congestion Control Presented by Bob Kinicki.
Advanced Computer Networks: TCP Congestion Control 1 TCP Congestion Control Lecture material taken from “Computer Networks A Systems Approach”, Fourth.
1 K. Salah Module 6.1: TCP Flow and Congestion Control Connection establishment & Termination Flow Control Congestion Control QoS.
TCP: flow and congestion control. Flow Control Flow Control is a technique for speed-matching of transmitter and receiver. Flow control ensures that a.
1 EE 122: Advanced TCP Ion Stoica TAs: Junda Liu, DK Moon, David Zats (Materials with thanks to Vern Paxson,
Courtesy: Nick McKeown, Stanford 1 TCP Congestion Control Tahir Azim.
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429 Introduction to Computer Networks Lecture 15: Congestion Control I Slides used with.
Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control!
1 Transport Protocols (continued) Relates to Lab 5. UDP and TCP.
CSE 461 University of Washington1 Topic How TCP implements AIMD, part 1 – “Slow start” is a component of the AI portion of AIMD Slow-start.
TCP: Transmission Control Protocol Overview Connection set-up and termination Interactive Bulk transfer Timers Improvements.
EE 122: Congestion Control and Avoidance Kevin Lai October 23, 2002.
Copyright 2008 Kenneth M. Chipps Ph.D. Controlling Flow Last Update
Project 2 – Implement Reliable Transport
1 TCP - Part II Relates to Lab 5. This is an extended module that covers TCP data transport, and flow control, congestion control, and error control in.
Lecture 9 – More TCP & Congestion Control
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Computer Networking Lecture 18 – More TCP & Congestion Control.
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
Katz, Stoica F04 EECS 122: Introduction to Computer Networks Congestion Control Computer Science Division Department of Electrical Engineering and Computer.
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429/556 Introduction to Computer Networks Principles of Congestion Control Some slides.
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
Winter 2008CS244a Handout 71 CS244a: An Introduction to Computer Networks Handout 7: Congestion Control Nick McKeown Professor of Electrical Engineering.
Recap of Lecture 19 If symptoms persist, please consult Dr Jacobson.
ECE 4110 – Internetwork Programming
Congestion Control EE 122: Intro to Communication Networks Fall 2010 (MW 4-5:30 in 101 Barker) Scott Shenker TAs: Sameer Agarwal, Sara Alspaugh, Igor Ganichev,
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking Congestion Control 0.
@Yuan Xue A special acknowledge goes to J.F Kurose and K.W. Ross Some of the slides used in this lecture are adapted from their.
1 TCP ProtocolsLayer name DNSApplication TCP, UDPTransport IPInternet (Network ) WiFi, Ethernet Link (Physical)
@Yuan Xue A special acknowledge goes to J.F Kurose and K.W. Ross Some of the slides used in this lecture are adapted from their.
1 Flow & Congestion Control Some slides are from lectures by Nick Mckeown, Ion Stoica, Frans Kaashoek, Hari Balakrishnan, and Sam Madden Prof. Dina Katabi.
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Chapter 6 TCP Congestion Control
Introduction to Networks
Introduction to Congestion Control
EECS 122: Introduction to Computer Networks Congestion Control
Project 2 is out! Goal: implement reliable transport protocol
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Lecture 19 – TCP Performance
So far, On the networking side, we looked at mechanisms to links hosts using direct linked networks and then forming a network of these networks. We introduced.
CS640: Introduction to Computer Networks
TCP Congestion Control
EE 122: Lecture 10 (Congestion Control)
Transport Layer: Congestion Control
TCP flow and congestion control
Presentation transcript:

1 Congestion Control EE122 Fall 2012 Scott Shenker Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson and other colleagues at Princeton and UC Berkeley

Announcements No office hours on Thursday! 2

3 TCP Refresher Same slides, but crucial for rest of lecture

4 TCP Header Source portDestination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Starting sequence number (byte offset) of data carried in this segment This is the number of the first byte of data in packet!

5 TCP Header Source portDestination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Acknowledgment gives seq # just beyond highest seq. received in order. “What’s Next”

6 3-Way Handshaking Client (initiator) Server SYN, SeqNum = x SYN + ACK, SeqNum = y, Ack = x + 1 ACK, Ack = y + 1 Active Open Passive Open connect() listen() accept()

7 Sequence Numbers Host A Host B TCP Data TCP HDR TCP HDR ISN (initial sequence number) Sequence number = 1 st byte ACK sequence number = next expected byte

Data and ACK in same packet The sequence number refers to data in packet –Packet from A carrying data to B The ACK refers to received data in other direction –A acking data that it received from B 8

9 TCP Header Source portDestination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Buffer space available for receiving data. Used for TCP’s sliding window. Interpreted as offset beyond Acknowledgment field’s value.

10 TCP Segment IP packet –No bigger than Maximum Transmission Unit (MTU) –E.g., up to 1,500 bytes on an Ethernet TCP packet –IP packet with a TCP header and data inside –TCP header  20 bytes long TCP segment –No more than Maximum Segment Size (MSS) bytes –E.g., up to 1460 consecutive bytes from the stream –MSS = MTU – (IP header) – (TCP header) IP Hdr IP Data TCP HdrTCP Data (segment)

11 Congestion Control Overview Everything in this lecture is oversimplified. Lots of details omitted. But the basic points remain valid….

12 Flow Control vs Congestion Control Flow control keeps one fast sender from overwhelming a slow receiver Congestion control keeps a set of senders from overloading the network

Huge Literature on Problem In mid-80s Jacobson “saved” the Internet with CC One of very few net topics where theory helps; many frustrated mathematicians in networking Less of a research focus now in the wide area –But still actively researched in datacenter networks –And commercial activity in wide area (e.g., Google) …but still far from academically settled –E.g. battle over “fairness” with Bob Briscoe… 13

Because Internet traffic is bursty! If two packets arrive at the same time –The node can only transmit one –… and either buffers or drops the other If many packets arrive in a short period of time –The node cannot keep up with the arriving traffic –… delays, and the buffer may eventually overflow 14 Congestion is Natural

15 Load and Delay Average Packet delay Load Typical queuing system with bursty arrivals Must balance utilization versus delay and loss Average Packet loss Load

Who Takes Care of Congestion? Network? End hosts? Both? 16

Answer End hosts adjust sending rate Based on feedback from network Hosts probe network to test level of congestion –Speed up when no congestion –Slow down when congestion 17

18 Drawbacks Suboptimal (always above or below optimal point) Relies on end system cooperation Messy dynamics –All end systems adjusting at the same time –Large, complicated dynamical system –Miraculous it works at all!

19 Basics of TCP Congestion Control Congestion window (CWND) –Maximum # of unacknowledged bytes to have in flight –Congestion-control equivalent of receiver window –MaxWindow = min{congestion window, receiver window}  Typically assume receiver window much bigger than cwnd Adapting the congestion window –Increase upon lack of congestion: optimistic exploration –Decrease upon detecting congestion

20 Detecting Congestion Network could tell source (ICMP Source Quench) –Risky, because during times of overload the signal itself could be dropped (and add to congestion)! Packet delays go up (knee of load-delay curve) –Tricky: noisy signal (delay often varies considerably) Packet loss –Fail-safe signal that TCP already has to detect –Complication: non-congestive loss (checksum errors)

Not All Losses the Same Duplicate ACKs: isolated loss –Still getting ACKs Timeout: possible disaster –Not enough dupacks –Must have suffered several losses 21

22 How to Adjust CWND? Consequences of over-sized window much worse than having an under-sized window –Over-sized window: packets dropped and retransmitted –Under-sized window: somewhat lower throughput Approach: –Gentle increase when uncongested (exploration) –Rapid decrease when congested

AIMD Additive increase –On success of last window of data, increase by one MSS Multiplicative decrease –On loss of packet, divide congestion window in half 23

24 Leads to the TCP “Sawtooth” t Window halved Loss

25 Slow-Start In what follows refer to cwnd in units of MSS

26 AIMD Starts Too Slowly! t Window It could take a long time to get started! Need to start with a small CWND to avoid overloading the network.

27 “Slow Start” Phase Start with a small congestion window –Initially, CWND is 1 MSS –So, initial sending rate is MSS/RTT That could be pretty wasteful –Might be much less than the actual bandwidth –Linear increase takes a long time to accelerate Slow-start phase (actually “fast start”) –Sender starts at a slow rate (hence the name) –… but increases exponentially until first loss

28 Slow Start in Action Double CWND per round-trip time Simple implementation: on each ack, CWND += MSS D A DD AADD Src Dest D D AAAA 8

29 Slow Start and the TCP Sawtooth Loss Exponential “slow start” t Window Why is it called slow-start? Because TCP originally had no congestion control mechanism. The source would just start by sending a whole window’s worth of data.

30 This has been incredibly successful Leads to the theoretical puzzle: If TCP congestion control is the answer, then what was the question? Not about optimizing, but about robustness –Hard to capture…

31 Congestion Control Details

32 Increasing CWND Increase by MSS for every successful window Increase a fraction of MSS per received ACK # packets (thus ACKs) per window: CWND / MSS Increment per ACK: CWND += MSS / (CWND / MSS) Termed: Congestion Avoidance –Very gentle increase

33 Fast Retransmission Sender sees 3 dupACKs Multiplicative decrease: CWND halved

34 CWND with Fast Retransmit segment 1 cwnd = 1 ACK 2 cwnd = 2 segment 2 segment 3 ACK 4 cwnd = 4 segment 4 segment 5 segment 6 segment 7 ACK 4 ACK 3 cwnd = 3 ACK 4 segment 4 3 duplicate ACKs cwnd = 2

35 Loss Detected by Timeout Sender starts a timer that runs for RTO seconds Restart timer whenever ack for new data arrives If timer expires: –Set SSTHRESH  CWND / 2 (“Slow-Start Threshold”) –Set CWND  MSS –Retransmit first lost packet –Execute Slow Start until CWND > SSTHRESH –After which switch to Additive Increase

36 Summary of Decrease Cut CWND half on loss detected by dupacks –“fast retransmit” Cut CWND all the way to 1 MSS on timeout –Set ssthresh to cwnd/2 Never drop CWND below 1 MSS

Summary of Increase “Slow-start”: increase cwnd by MSS for each ack Leave slow-start regime when either: –cwnd > SSThresh –Packet drop Enter AIMD regime –Increase by MSS for each window’s worth of acked data 37

38 Repeating Slow Start After Timeout t Window Slow-start restart: Go back to CWND of 1 MSS, but take advantage of knowing the previous value of CWND. Slow start in operation until it reaches half of previous CWND, I.e., SSTHRESH Timeout Fast Retransmission SSThresh Set to Here

More Advanced Fast Restart Set ssthresh to cwnd/2 Set cwnd to cwnd/2 + 3 –for the 3 dup acks already seen Increment cwnd by 1 MSS for each additional duplicate ACK After receiving new ACK, reset cwnd to ssthresh 39

40 Throughput Equation In what follows refer to cwnd in units of MSS

Calculation on Simple Model Assume loss occurs whenever cwnd reaches W –Recovery by fast retransmit Window: W/2, W/2+1, W/2+2, …W, W/2, … –W/2 RTTs, then drop, then repeat Average throughput:.75W(MSS/RTT) –One packet dropped out of (W/2)*(3W/4) –Packet drop rate p = (8/3) W -2 Throughput = (MSS/RTT) sqrt(3/2p) 41

Some implications Flows get throughput inversely proportional to RTT –Fairness issue? One can dispense with TCP and just match eqtn: –Equation-based congestion control –Measure drop percentage p, and set rate accordingly –Useful for streaming applications 42

How does this work at high speed? Assume that RTT = 100ms, MSS=1500bytes What value of p is required to go 100Gbps? –Roughly 2 x How long between drops? –Roughly 16.6 hours How much data has been sent in this time? –Roughly 6 petabits These are not practical numbers! 43

Adapting TCP to High Speed One approach: once speed is past some threshold, change equation to p -.8 rather than p -.5 We will discuss other approaches next time… 44

45 Why AIMD? In what follows refer to cwnd in units of MSS

Three Congestion Control Challenges Single flow adjusting to bottleneck bandwidth –Without any a priori knowledge –Could be a Gbps link; could be a modem Single flow adjusting to variations in bandwidth –When bandwidth decreases, must lower sending rate –When bandwidth increases, must increase sending rate Multiple flows sharing the bandwidth –Must avoid overloading network –And share bandwidth “fairly” among the flows 46

47 Problem #1: Single Flow, Fixed BW Want to get a first-order estimate of the available bandwidth –Assume bandwidth is fixed –Ignore presence of other flows Want to start slow, but rapidly increase rate until packet drop occurs (“slow-start”) Adjustment: –cwnd initially set to 1 (MSS) –cwnd++ upon receipt of ACK

48 Problems with Slow-Start Slow-start can result in many losses –Roughly the size of cwnd ~ BW*RTT Example: –At some point, cwnd is enough to fill “pipe” –After another RTT, cwnd is double its previous value –All the excess packets are dropped! Need a more gentle adjustment algorithm once have rough estimate of bandwidth –Rest of design discussion focuses on this

Problem #2: Single Flow, Varying BW Want to track available bandwidth Oscillate around its current value If you never send more than your current rate, you won’t know if more bandwidth is available Possible variations: (in terms of change per RTT) Multiplicative increase or decrease: cwnd  cwnd * / a Additive increase or decrease: cwnd  cwnd +- b 49

Four alternatives AIAD: gentle increase, gentle decrease AIMD: gentle increase, drastic decrease MIAD: drastic increase, gentle decrease –too many losses: eliminate MIMD: drastic increase and decrease 50

51 Problem #3: Multiple Flows Want steady state to be “fair” Many notions of fairness, but here just require two identical flows to end up with the same bandwidth This eliminates MIMD and AIAD –As we shall see… AIMD is the only remaining solution! –Not really, but close enough….

52 Buffer and Window Dynamics No congestion  x increases by one packet/RTT every RTT Congestion  decrease x by factor 2 AB C = 50 pkts/RTT x

53 AIMD Sharing Dynamics AB x1x1 DE No congestion  rate increases by one packet/RTT every RTT Congestion  decrease rate by factor 2 Rates equalize  fair share x2x2

54 AIAD Sharing Dynamics AB x1x1 DE No congestion  x increases by one packet/RTT every RTT Congestion  decrease x by 1 x2x2

55 Simple Model of Congestion Control Two TCP connections –Rates x 1 and x 2 Congestion when sum>1 Efficiency: sum near 1 Fairness: x’s converge User 1: x 1 User 2: x 2 Efficiency line 2 user example overload underload

56 Example User 1: x 1 User 2: x 2 fairness line efficiency line 1 1 Total bandwidth 1 Inefficient: x 1 +x 2 =0.7 (0.2, 0.5) Congested: x 1 +x 2 =1.2 (0.7, 0.5) Efficient: x 1 +x 2 =1 Not fair (0.7, 0.3) Efficient: x 1 +x 2 =1 Fair (0.5, 0.5)

57 AIAD User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (x 1h -a D,x 2h -a D ) (x 1h -a D +a I ), x 2h -a D +a I )) Increase: x + a I Decrease: x - a D Does not converge to fairness

58 MIMD User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (b d x 1h,b d x 2h ) (b I b D x 1h, b I b D x 2h ) Increase: x*b I Decrease: x*b D Does not converge to fairness

59 (b D x 1h +a I, b D x 2h +a I ) AIMD User 1: x 1 User 2: x 2 fairness line efficiency line (x 1h,x 2h ) (b D x 1h,b D x 2h ) Increase: x+a D Decrease: x*b D Converges to fairness

AIMD is only “fair” choice But how fair is it? Bandwidth depends on RTT Hosts that send more flows get more bandwidth 60

Thursday: Advanced Topics in CC 61