ee 122 congestion control and avoidance
Download
Skip this Video
Download Presentation
EE 122: Congestion Control and Avoidance

Loading in 2 Seconds...

play fullscreen
1 / 29

EE 122: Congestion Control and Avoidance - PowerPoint PPT Presentation


  • 192 Views
  • Uploaded on

EE 122: Congestion Control and Avoidance. Kevin Lai October 23, 2002. Problem. At what rate do you send data? flow control make sure that the receiver can receive sliding-window based flow control: receiver reports window size to sender higher window  higher throughput

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' EE 122: Congestion Control and Avoidance' - adair


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
problem
Problem
  • At what rate do you send data?
  • flow control
    • make sure that the receiver can receive
    • sliding-window based flow control:
      • receiver reports window size to sender
      • higher window  higher throughput
      • throughput = wnd/RTT
  • congestion control
    • make sure that the network can deliver

[email protected]

solutions
Solutions
  • Everyone sends as fast as they can
    • excess gets dropped
    • very bad idea: leads to congestion collapse
  • Reserve bandwidth
    • low utilization
    • never have packet drops, queueing delays
  • Congestion control and avoidance
    • high utilization
    • occasionally have packet drops, queueing delays

[email protected]

non decreasing efficiency under load

ok?

cliff

Non-decreasing Efficiency under Load
  • Efficiency = useful_work/time
  • critical property of system design
    • network technology, protocol or application
  • otherwise, system collapses exactly when most demand for its operation
  • trade lower overall efficiency for this?

good

knee

Efficiency

Load

[email protected]

congestion collapse
Congestion Collapse
  • Decrease of network efficiency under load
    • efficiency = utilization of bandwidth
  • Waste resources on useless or undelivered data
  • Network layer
    • loaddrops, 1 fragment dropped
  • Transport layer
    • retransmit too many times
    • no congestion control / avoidance

[email protected]

transport layer congestion collapse 1
Transport Layer Congestion Collapse 1
  • network is congested (a router drops packets)
  • the receiver didn’t get a packet
  • sender waits, but not long enough
    • timeout too short,
  • retransmit again
    • adds to congestion, increases likelihood that retransmission will be dropped, or delayed
  • rinse, repeat
  • assume that everyone is doing the same
  • network will become more and more congested
    • with duplicate packets rather than new packets
  • Solution: fix timeout (previous lecture)

[email protected]

transport layer congestion collapse 2
Transport LayerCongestion Collapse 2

Penalized

  • Waste resources on undelivered data
  • A flow sends data at a high rate despite loss
  • Its packets consume bandwidth at earlier links, only to be dropped at a later link

90% loss

bw wasted

ignores loss

[email protected]

congestion collapse and efficiency
Congestion Collapse and Efficiency

knee

cliff

  • knee – point after which
    • throughput increasesslowly
    • delay increases quickly
  • cliff – point after which
    • throughput decreases quicklyto zero (congestion collapse)
    • delay goes to infinity
  • Congestion avoidance
    • stay at knee
  • Congestion control
    • stay left of (but usually close to) cliff

congestion collapse

Throughput

under utilization

over utilization

saturation

Load

Delay

Load

[email protected]

tcp congestion control
TCP Congestion Control
  • Operate to the left of the cliff
    • less efficient than operating at the knee, but requires less support from network
  • Solution: Carefully manage number of packets in network
    • starting up: increase number of packets allowed
    • equilibrium: maintain constant number of packets
      • must probe periodically for more available bandwidth
    • congestion: decrease number of packets allowed

[email protected]

tcp congestion control components
TCP Congestion Control Components
  • Measure available bandwidth
    • slow start
      • fast, hard on network
    • additive increase/multiplicative decrease
      • slow, gentle on network
  • Detecting congestion
    • timeout based on RTT (last lecture)
      • robust, causes low throughput
    • duplicate acks (Fast Retransmit)
      • can be fooled, maintains high throughput
  • Recovering from loss
    • Fast recovery: avoid slow start when few packets lost

[email protected]

congestion window cwnd
Congestion Window (cwnd)
  • Limits how much data can be in transit
  • Integrate with flow control
  • implemented as # of bytes, describe as # packets

MaxWindow = min(cwnd, AdvertisedWindow)

EffectiveWindow = MaxWindow – (LastByteSent – LastByteAcked)

LastByteAcked

LastByteSent

sequence number increases

[email protected]

slow start goal
Slow Start Goal
  • Goal: discover congestion quickly
    • used to get rough initial estimate of cwnd
  • Slow Start used when
    • a new connection, or
    • after timeout, or
    • after connection has been idle for a while
slow start algorithm
Slow Start Algorithm
  • Algorithm:
    • Set cwnd =1
    • Each time a segment is acknowledged increment cwnd by one (cwnd++)
  • Slow Start increases cwnd exponentially
    • called “Slow” because it gradually increases sending rate according to the RTT
    • predecessor just increased to advWin immediately

[email protected]

slow start example

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

ACK for segments 4+5+6+7

Slow Start Example
  • cwnd doubles every RTT

cwnd = 2

cwnd = 4

cwnd = 8

[email protected]

slow start problem
Slow Start Problem
  • Slow Start can cause serious loss
    • loss = bottleneck bandwidth * RTT
  • Example:
    • bottleneck link is 8 Mb/s
    • RTT is 100ms
    • at some point cwnd = 800,000 bits
      • exactly right for bottleneck
    • 100 ms late, cwnd = 1,600,000 bits
      • twice the bottleneck, 800,000 bits lost (oops)
  • Need to switch to something else when throughput is close to bottleneck bandwidth

[email protected]

exiting slow start
Exiting Slow Start
  • cwnd>=advWin
    • limited by receiver’s advertised window  if cwnd allowed to increase, would grow unbounded
  • congestion
    • reached available bandwidth  switch to AI/MD
  • cwnd>=ssthresh
    • ssthresh: slow start threshold
    • ssthresh is a hint about when to slow down, calculated from previous congestion on same connection
    • “we experienced congestion beyond this point before, slow down”

[email protected]

additive increase multiplicative decrease
Additive Increase/Multiplicative Decrease
  • Used Slow Start to get rough estimate of cwnd
  • Goal: maintain operating point at the left of the cliff
    • Additive increase: starting from the rough estimate, slowly increase cwnd to probe for additional available bandwidth
    • Multiplicative decrease: cut congestion window size aggressively if congestion occurs
  • Why not AI/AD, MI/MD, MI/AD:
    • mathematical models show A/M is only choice that converges to fairness and efficiency
ai md algorithm
AI/MD Algorithm
  • ssthresh = 
  • a segment is acknowledged
    • increment cwnd by 1/cwnd (cwnd += 1/cwnd)
    • as a result, cwnd is increased by one only if all segments in a cwnd have been acknowledged.
  • congestion detected
    • timeout: ssthresh = cwnd/2; cwnd = 1; begin slow start
    • duplicate acks (Fast Retransmit): later

[email protected]

slow start ai md example
Slow Start/AI/MD Example
  • Assume that ssthresh = 8

ssthresh

Cwnd (in segments)

Roundtriptimes

[email protected]

the big picture
The big picture

cwnd

Timeout

Timeout

AI/MD

AI/MD

ssthresh

SlowStart

SlowStart

SlowStart

Time

slow start ai md pseudocode
Slow Start/AI/MD Pseudocode

Initially:

cwnd = 1;

ssthresh = infinite;

New ack received:

if (cwnd < ssthresh)

/* Slow Start*/

cwnd = cwnd + 1;

else

/* Congestion Avoidance */

cwnd = cwnd + 1/cwnd;

Timeout:

/* Multiplicative decrease */

ssthresh = win/2;

cwnd = 1;

ai md problem
AI/MD Problem
  • If available bandwidth increases suddenly
    • e.g., other flows finish, route changes
  • then AI/MD will be slow to use it
  • Without help from network, there is a fundamental tradeoff between
    • being able to take available bandwidth and
    • causing loss

[email protected]

congestion detection
Congestion Detection
  • Wait for Retransmission Time Out (RTO)
    • RTO kills throughput
  • In BSD TCP implementations, RTO is usually more than 500ms
    • the granularity of RTT estimate is 500 ms
    • retransmission timeout is RTT + 4 * mean_deviation
  • Solution: Don’t wait for RTO to expire

[email protected]

fast retransmit

segment 1

cwnd = 1

Fast Retransmit
  • Resend a segment after 3 duplicate ACKs
    • a duplicate ACK means that an out-of sequence segment was received
  • Notes:
    • packet reordering can cause duplicate ACKs
    • window may be too small to get enough duplicate ACKs

ACK 2

cwnd = 2

segment 2

segment 3

ACK 3

ACK 4

cwnd = 4

segment 4

segment 5

3 duplicate

ACKs

segment 6

segment 7

ACK 4

ACK 4

ACK 4

[email protected]

fast recovery after a fast retransmit
Fast Recovery: After a Fast Retransmit
  • ssthresh = cwnd / 2
  • cwnd = ssthresh
    • instead of setting cwnd to 1, cut cwnd in half (multiplicative decrease)
  • for each dup ack arrival
    • dupack++
    • MaxWindow = min(cwnd + dupack, AdvWin)
    • indicates packet left network, so we may be able to send more
  • receive ack for new data (beyond initial dup ack)
    • dupack = 0
    • exit fast recovery
  • But when RTO expires still do cwnd = 1

[email protected]

fast recovery problem
Fast Recovery Problem
  • Can’t recover when more than half the window size is lost
    • cwnd is cut in half
    • MaxWindow is only increased when dup ack is received
    • if more than half the window is lost, less than cwnd/2 dup acks will be received by sender
    • sender will not be able to send anything, must wait for timeout
  • more than half the window lost indicates serious congestion anyway

[email protected]

fast retransmit and fast recovery
Fast Retransmit and Fast Recovery

cwnd

  • Retransmit after 3 duplicated acks
    • Prevent expensive timeouts
  • Reduce slow starts
  • At steady state, cwnd oscillates around the optimal window size

AI/MD

Slow Start

Fast retransmit

Time

other tcp related techniques
Other TCP-related techniques
  • TCP SACK
    • instead of cumulative acknowledgements, receiver tells sender exactly what was lost
    • useful when more than one packet lost in a window
  • Router support
    • have higher utilization, more fairness with router support

[email protected]

tcp congestion control summary
TCP Congestion Control Summary
  • Measure available bandwidth
    • slow start
      • fast, hard on network
    • additive increase/multiplicative decrease
      • slow, gentle on network
  • Detecting congestion
    • timeout based on RTT
      • robust, causes low throughput
    • Fast Retransmit
      • can be fooled, maintains high throughput
  • Recovering from loss
    • Fast recovery: avoid timeout when few packets lost

[email protected]

ad