Congestion Control u Issues in congestion control u

  • Slides: 20
Download presentation
Congestion Control u Issues in congestion control u TCP congestion control u Other techniques

Congestion Control u Issues in congestion control u TCP congestion control u Other techniques for congestion control CS 118/Spring 2000 1 May 24, 2000

Issues in congestion control u. Why does congestion occur? Intrinsic nature of statistical multiplexing:

Issues in congestion control u. Why does congestion occur? Intrinsic nature of statistical multiplexing: – not know what is the exact rate to transmit – send data whenever needed – control congestion if (and when) it occurs u. Congestion control: get the network out of congestion ucongestion avoidance: reduce the chance of network getting into congested state – taking actions early, before routers fill up their buffer queue and are forced to drop packets – does not guarantee network to be congestion 2 CS 118/Spring free 2000 May 24, 2000

TCP Flow & Congestion Control u TCP has a receiver-controlled window size u sender

TCP Flow & Congestion Control u TCP has a receiver-controlled window size u sender uses a congestion window, cwnd transmission window = MIN(cwnd, receive-window) u sender adjusts cwnd by observing network congestion level u cwnd adjustment: additive increase, multiplicative decrease (AIMD) – in the absence of congestion, increase cwnd by one mss per round trip – upon packet losses, decrease cwnd by half CS 118/Spring 2000 3 May 24, 2000

Additive congestion window increase Source u Initialization: Destination cwnd=1 maximum segment size 1 st

Additive congestion window increase Source u Initialization: Destination cwnd=1 maximum segment size 1 st RTT cwnd=1 mss (mss) u upon each ack arrival: RTT cwnd += mss 2 nd cwnd=2 mss the product is large, may take long to increase cwnd to proper size … u if CS 118/Spring 2000 4 May 24, 2000

TCP Slow-Start When starting a new TCP connection: uinitialize cwnd = 1 MSS uincrease

TCP Slow-Start When starting a new TCP connection: uinitialize cwnd = 1 MSS uincrease cwnd value exponentially – increase cwnd by 1 MSS upon receiving every ACK – result in doubling cwnd every round trip time CS 118/Spring 2000 5 May 24, 2000

An example of Slow-Start MSS=500 B (1) upon connection open, cwnd=500 B, send 1

An example of Slow-Start MSS=500 B (1) upon connection open, cwnd=500 B, send 1 packet (2) receive one ACK, cwnd=1000 B, send 2 packets (3) receive 2 ACKs, cwnd=2000 B, send 4 packets (4)receive 4 ACKs, cwnd=4000 B, send 8 packets (1) CS 118/Spring 2000 (2) (3) (4) 6 time May 24, 2000

When to slow down? ulearn from observations: if retransmission timer goes off, have gone

When to slow down? ulearn from observations: if retransmission timer goes off, have gone too far uremember the half-point of cwnd at the loss point (“Congestion-threshold”, or Slow-Start-threshold, ssthresh) uwhen cwnd < ssthresh, increase cwnd exponentially uwhen cwnd ssthresh, increase cwnd linearly CS 118/Spring 2000 7 May 24, 2000

implementation u. Initialize cwnd=1 mss, ssthresh=win-size uupon receiving an ACK – if (cwnd <

implementation u. Initialize cwnd=1 mss, ssthresh=win-size uupon receiving an ACK – if (cwnd < ssthresh) cwnd += mss – else cwnd += mss x mss/cwnd uupon timeout: – ssthresh = cwnd / 2 – cwnd = 1 MSS cwnd: 500 1000 timeout 2000 2500 ssthresh=1250 cwnd=500 Assume mss=500 B, ssthresh=2000 B, CS 118/Spring 2000 8 May 24, 2000

Slow-Start and Go-Back-N ucurrent TCP window flow control: go- back-N uupon retransmission timeout, cwnd=1

Slow-Start and Go-Back-N ucurrent TCP window flow control: go- back-N uupon retransmission timeout, cwnd=1 MSS, one segment retransmitted immediately uif only one segment lost, next ACK will ack all received data Assume mss=500 B, ssthresh=2000 B, cwnd: 500 1000 2500 Ack(500) Ack(1500) CS 118/Spring 2000 timeout ssthresh=1250 cwnd=500 Ack(6000) Ack(3500) 9 May 24, 2000

TCP fast retransmission u. Using timeout to detect losses and trigger retransmission can take

TCP fast retransmission u. Using timeout to detect losses and trigger retransmission can take long ucan use duplicate ACK’s as a faster way to detect packet losses – receiver resends the last ACK for each out-oforder packet arrival – when seeing 3 duplicate ACK’s, sender assumes that packet is lost, send the first unack-ed packet – ssthresh = cwnd / 2 u. Slow-Start unchanged: upon timeout, – ssthresh = cwnd / 2, cwnd = 1 MSS CS 118/Spring 2000 10 May 24, 2000

An example for fast retransmit ureceiver Sender resends the Packet 1 last ACK for

An example for fast retransmit ureceiver Sender resends the Packet 1 last ACK for each out. Packet 2 of-order packet arrival Packet 3 Packet 4 u. Packet 3 gets lost Packet 5 First ack ureceiver sent ack-2 Packet 6 upon receiving Dup. Ack 1 packets 4 -6 Dup. Ack 2 Dup. Ack 3 uwhen 3 rd duplicate Retransmit packet 3 ack 2 arrives, sender retransmits packet 3 CS 118/Spring 2000 11 Receiver ACK 1 ACK 2 ACK 6 May 24, 2000

Limitations of fast retransmit u. When the window size is small, may not have

Limitations of fast retransmit u. When the window size is small, may not have enough packets in the fly to get 3 duplicate ack's – e. g. cwnd=4, 2 nd packet lost 2 duplicate ack's only uwhen multiple packets lost in a row, fastretransmit only gets the first lost packet retransmitted quickly timeout 1 2 3 45 6 7 8 Retransmit 3 ack 3 CS 118/Spring 2000 Retransmit 4 12 May 24, 2000

Food for thought u how much may the lower layer protocols help the transport

Food for thought u how much may the lower layer protocols help the transport protocol? – in particular, shouldn’t IP do a better job so that TCP doesn’t have to work so hard? u If a network guarantees reliable data delivery, do we still need a transport protocol to do that? u reference: – RFC 2001, “TCP Slow-Start, Congestion Avoidane, Fast Retransmit, and Fast Recovery Algorithms”, http: //info. internet. isi. edu/in-notes/rfc/files/rfc 2001. txt CS 118/Spring 2000 13 May 24, 2000

Different approaches to network traffic control Two places of implementation uhosts (transport protocol) urouters

Different approaches to network traffic control Two places of implementation uhosts (transport protocol) urouters inside the network congestion feedback: DECBIT, RED Bottomline: best control schemes can only make available bandwidth better utilized – nothing can substitute for adequate resource provisioning CS 118/Spring 2000 14 May 24, 2000

TCP Vegas u. Basic idea: TCP transmitter watches for signs of router’s packet queue

TCP Vegas u. Basic idea: TCP transmitter watches for signs of router’s packet queue building up – throughput is flattened – RTT is increasing ucontrol parameters: – base. RTT: the min. RTT value from all measured RTTs – Expected. Rate = Congestion-window/base. RTT – sender calculates Actual. Rate once per RTT – diff = Expected. Rate - Actual. Rate CS 118/Spring 2000 15 May 24, 2000

TCP Vegas The algorithm uif diff is very small, increase congestion window uelse if

TCP Vegas The algorithm uif diff is very small, increase congestion window uelse if diff is noticeably big, decrease congestion window uelse leave the window unchanged CS 118/Spring 2000 16 May 24, 2000

Congestion avoidance by network feedback uhow to detect network congestion – Data traffic is

Congestion avoidance by network feedback uhow to detect network congestion – Data traffic is bursty – packet queue often goes up and down rapidly !!Instant queue length is not a good measure for congestion – using sustained average queue length as congestion measure CS 118/Spring 2000 17 May 24, 2000

Congestion Notification uhow to signal end users to adjust their transmissions – traffic load

Congestion Notification uhow to signal end users to adjust their transmissions – traffic load changes randomly – communication with end users takes time » the delay will be different for different users – very large number of users sharing the network uextremely difficult, if not impossible, to tell individual users exactly how fast they should send CS 118/Spring 2000 18 May 24, 2000

An example packet queue at routers Queue length time • the queue size can

An example packet queue at routers Queue length time • the queue size can go up and down very quickly • heavy traffic load does not mean that the queue never goes empty, but the queue size can stay high for very long time CS 118/Spring 2000 19 May 24, 2000

DECBIT u measure average queue length Q over each busy-idle cycle u whenever Q

DECBIT u measure average queue length Q over each busy-idle cycle u whenever Q > threshold, set congestion bit on the arriving data packet u receiver puts the bit value in ACK’s to sender u sender adjusts congestion window size based on the average – if > 50% packets with bit set, decrease congestion window by 0. 875 times – otherwise increase window size by one packet – But over what time interval to take the average? CS 118/Spring 2000 20 May 24, 2000