cs 268 router support for congestion control n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CS 268: Router Support for Congestion Control PowerPoint Presentation
Download Presentation
CS 268: Router Support for Congestion Control

Loading in 2 Seconds...

play fullscreen
1 / 25

CS 268: Router Support for Congestion Control - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

CS 268: Router Support for Congestion Control. Ion Stoica February 11, 2004. Router Support For Congestion Management. Traditional Internet Congestion control mechanisms at end-systems, mainly implemented in TCP Routers play little role Router mechanisms affecting congestion management

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 'CS 268: Router Support for Congestion Control' - rufus


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
router support for congestion management
Router Support For Congestion Management
  • Traditional Internet
    • Congestion control mechanisms at end-systems, mainly implemented in TCP
    • Routers play little role
  • Router mechanisms affecting congestion management
    • Scheduling
    • Buffer management
  • Traditional routers
    • FIFO
    • Tail drop

istoica@cs.berkeley.edu

drawbacks of fifo with tail drop
Drawbacks of FIFO with Tail-drop
  • Buffer lock out by misbehaving flows
  • Synchronizing effect for multiple TCP flows
  • Burst or multiple consecutive packet drops
    • Bad for TCP fast recovery

istoica@cs.berkeley.edu

fifo router with two tcp sessions
FIFO Router with Two TCP Sessions

istoica@cs.berkeley.edu

slide5
RED
  • FIFO scheduling
  • Buffer management:
    • Probabilistically discard packets
    • Probability is computed as a function of average queue length (why average?)

Discard Probability

1

0

min_th

max_th

queue_len

Average

Queue Length

istoica@cs.berkeley.edu

red cont d
RED (cont’d)
  • min_th – minimum threshold
  • max_th – maximum threshold
  • avg_len – average queue length
    • avg_len = (1-w)*avg_len + w*sample_len

Discard Probability

1

0

min_th

max_th

queue_len

Average

Queue Length

istoica@cs.berkeley.edu

red cont d1
RED (cont’d)
  • If (avg_len < min_th)  enqueue packet
  • If (avg_len > max_th)  drop packet
  • If (avg_len >= min_th and avg_len < max_th)  enqueue packet with probability P

Discard Probability (P)

1

0

queue_len

min_th

max_th

Average

Queue Length

istoica@cs.berkeley.edu

red cont d2
RED (cont’d)
  • P = max_P*(avg_len – min_th)/(max_th – min_th)
  • Improvements to spread the drops

P’ = P/(1 – count*P), where

    • count – how many packets were consecutively enqueued since last drop

Discard Probability

max_P

1

P

0

Average

Queue Length

queue_len

min_th

max_th

avg_len

istoica@cs.berkeley.edu

red advantages
RED Advantages
  • Absorb burst better
  • Avoids synchronization
  • Signal end systems earlier

istoica@cs.berkeley.edu

red router with two tcp sessions
RED Router with Two TCP Sessions

istoica@cs.berkeley.edu

problems with red
Problems with RED
  • No protection: if a flow misbehaves it will hurt the other flows
  • Example: 1 UDP (10 Mbps) and 31 TCP’s sharing a 10 Mbps link

UDP

istoica@cs.berkeley.edu

solution
Solution?
  • Round-robin among different flows [Nagle ‘87]
    • One queue per flow

istoica@cs.berkeley.edu

round robin discussion
Round-Robin Discussion
  • Advantages: protection among flows
    • Misbehaving flows will not affect the performance of well-behaving flows
    • FIFO does not have such a property
  • Disadvantages:
    • More complex than FIFO: per flow queue/state
    • Biased toward large packets – a flow receives service proportional to the number of packets (When is this bad?)

istoica@cs.berkeley.edu

solution1
Solution?
  • Bit-by-bit round robin
  • Can you do this in practice?
  • No, packets cannot be preempted (why?)
  • …we can only approximate it

istoica@cs.berkeley.edu

fair queueing fq dks 89
Fair Queueing (FQ) [DKS’89]
  • Define a fluid flow system: a system in which flows are served bit-by-bit
  • Then serve packets in the increasing order of their deadlines
  • Advantages
    • Each flow will receive exactly its fair rate
  • Note:
    • FQ achieves max-min fairness

istoica@cs.berkeley.edu

max min fairness
Max-Min Fairness
  • Denote
    • C – link capacity
    • N – number of flows
    • ri – arrival rate
  • Max-min fair rate computation:
    • compute C/N
    • if there are flows i such that ri <= C/N, update C and N
    • if no, f = C/N; terminate
    • go to 1
  • A flow can receive at most the fair rate, i.e., min(f, ri)

istoica@cs.berkeley.edu

example

f = 4:

min(8, 4) = 4

min(6, 4) = 4

min(2, 4) = 2

8

10

4

6

4

2

2

Example
  • C = 10; r1 = 8, r2 = 6, r3 = 2; N = 3
  • C/3 = 3.33  C = C – r3 = 8; N = 2
  • C/2 = 4; f = 4

istoica@cs.berkeley.edu

alternate way to compute fair rate
Alternate Way to Compute Fair Rate
  • If link congested, compute f such that

f = 4:

min(8, 4) = 4

min(6, 4) = 4

min(2, 4) = 2

8

10

4

6

4

2

2

istoica@cs.berkeley.edu

implementing fair queueing
Implementing Fair Queueing
  • Idea: serve packets in the order in which they would have finished transmission in the fluid flow system

istoica@cs.berkeley.edu

example1
Example

Flow 1

(arrival traffic)

1

2

3

4

5

6

time

Flow 2

(arrival traffic)

1

2

3

4

5

time

Service

in fluid flow

system

1

2

3

4

5

6

1

2

3

4

5

time

5

Packet

system

1

2

1

3

2

3

4

4

5

6

time

istoica@cs.berkeley.edu

system virtual time v t
System Virtual Time: V(t)
  • Measure service, instead of time
  • V(t) slope – rate at which every active flow receives service
    • C – link capacity
    • N(t) – number of active flows in fluid flow system at time t

V(t)

time

Service

in fluid flow

system

1

2

3

4

5

6

1

2

3

4

5

time

istoica@cs.berkeley.edu

fair queueing implementation
Fair Queueing Implementation
  • Define
    • - finishing time of packet k of flow i (in system virtual time reference system)
    • - arrival time of packet k of flow i
    • - length of packet k of flow i
  • The finishing time of packet k+1 of flow i is

istoica@cs.berkeley.edu

weighted fair queueing wfq
“Weighted Fair Queueing” (WFQ)
  • What if we don't want exact fairness?
    • E.g.,: file servers
  • Assign weight wi to each flow i
  • And change virtual finishing time

istoica@cs.berkeley.edu

fq advantages
FQ Advantages
  • FQ protect well-behaved flows from ill-behaved flows
  • Example: 1 UDP (10 Mbps) and 31 TCP’s sharing a 10 Mbps link

istoica@cs.berkeley.edu

summary
Summary
  • FQ does not eliminate congestion  it just manages the congestion
  • You need both end-host congestion control and router support for congestion control
    • End-host congestion control to adapt
    • Router congestion control to protect/isolate
  • Don’t forget buffer management: you still need to drop in case of congestion. Which packet’s would you drop in FQ?
    • One possibility: packet from the longest queue

istoica@cs.berkeley.edu