|








 
 

|   
|   
Ion Stoica
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley
Berkeley, CA 94720-1776
 


 
 
|   



㠌raditional Internet
- Congestion control
mechanisms at end-systems,
mainly implemented in ŒCP
- Routers play little role
ã Router mechanisms affecting
congestion management
- Scheduling
- Buffer management
㠌raditional routers
- FIFO
- Œail drop


 


 
 ! 

ã Buffer lock out by misbehaving flows

ã Synchronizing effect for multiple ŒCP flows
ã Burst or multiple consecutive packet drops
- Bad for ŒCP fast recovery

è



 

|"

 

¢
 #
ã FIFO scheduling
ã Buffer management:
- Probabilistically discard packets
- Probability is computed as a function of average queue
length (why average?)
j
 



   
 

D
 #
$  %!&

ã min_th ± minimum threshold

ã max_th ± maximum threshold
ã avg_len ± average queue length
- avg_len = (1-w)*avg_len + w*sample_len

j
 



   
 


 #
$  %!&

ã 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

j
 



   
 

þ
 #
$  %!&

ã 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
j
 




h
   
 




 #
'!( 

ã Absorb burst better

ã Avoids synchronization
ã Signal end systems earlier

ð
#


 

|"
 

4
 " 
 
#
ã o protection: if a flow misbehaves it will hurt the
other flows
ã Example: 1 UDP (10 Mbps) and 31 ŒCP¶s
sharing a 10 Mbps link
10


  

8  " ED

1
0
1 10 13 1 1 5 8 31
K

44
 
 )

ã Round-robin among different flows [agle µ 7]

- One queue per flow

4
 
!  

 

ã 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?)

4è
 
 )

ã Bit-by-bit round robin

ã Can you do this in practice?
ã o, packets cannot be preempted (why?)
ã «we can only approximate it

4¢
 
*


$*&
+
%ð

ã Define a fluid flow system: a system in which

flows are served bit-by-bit
㠌hen serve packets in the increasing order of
their deadlines

ã Advantages
- Each flow will receive exactly its fair rate

ã ote:
- FQ achieves max-min fairness

4D
 , 

ã Denote
- | ± link capacity
- ± number of flows
-
 ± arrival rate
ã Max-min fair rate computation:
1. compute |
2. if there are flows  such that
i <= | , update |and 

|  |
 È
| 


3. if no, = | ; terminate

4. go to 1
ã A flow can receive at most the fair rate, i.e., min(,
i)
4
 #,

ã | = 10;
1 = ,
2 = 6,
3 = 2; =3
ã |/3 = 3.33  | = | ± r3 = ; =2
ã |/2 = 4;  = 4

2 = 4„
m

 min( , 4) = 4
 min(6, 4) = 4

min(2, 4) = 2

4þ
'  
-.

| 


 

ã If link congested, compute  such that

    2  ; |


2 = 4„
m

 min( , 4) = 4
 min(6, 4) = 4

min(2, 4) = 2

4
  

*



ã Idea: serve packets in the order in which they

would have finished transmission in the fluid flow
system

4ð
 #,

Flow 1 1 2 3 4 6
(arrival traffic) time

Flow 2
(arrival traffic) 1 2 3 4
time

Service 1 2 3 4 6
in fluid flow
1 2
3 4 time
system

Packet 1 2 1 3 2 3 4 4 6
system time


 . 
/


§$ &
ã Measure service, instead of time
ã V(t) slope ± rate at which every active flow receives service
- | ± link capacity
- (t) ± number of active flows in fluid flow system at time t
V(t)

  
 |


 


time

Service 1 2 3 4 6
in fluid flow
1 2
3 4 time
system 4
 
*


   

ã Define
-  ï- finishing time of packet ï of flow  (in system virtual
time reference system)
- ï- arrival time of packet ï of flow 
Ä ï Ä length of packet ï of flow 


㠌he finishing time of packet ï
of flow  is

  ï Ú  ;    ï    ï  Ú  ï Ú 


 - !

*

0
$-*&

ã What if we don't want exact fairness?

- E.g.,: file servers
ã Assign weight ÿ to each flow 
ã And change virtual finishing time
ï Ú
ï Ú
      ï  
ï
Ú 

è
 
  
#,
ã 1 UDP (10 Mbps) and 31 ŒCPs  "4  "
$4&
sharing a 10 Mbps link
|" |"
$&
ÈÈÈ ÈÈÈ

|"è 4   |"
$è&

0
h
 

!
  


 0
K *


  


  

 # . 
#  0
 03
 03
 0
 0
 01

01
00
h 0
  h   



  1 10 13 1 1 31
K
 K

¢
 |   

*


$| *&

ã Fair Queueing requires per flow state in routers

- Maybe impractical for very high speed routers

ã Core Stateless Fair Queueing eliminates the

state at core routers «

ã « but only approximates FQ¶s behavior

D
 

ã If each packet of a flow with arrival rate is

forwarded with probability
 2


    ±

ã the rate of flow¶s forwarded traffic
is
 2

 ;   ;    ± ;    2 

ã o need to maintain per-flow state if is carried
in the packet
- eed to update rate in packet to


 | *

ã A contiguous and trusted region of network in which

- Edge nodes ± perform per flow operations
- Core nodes ± do not perform any per flow operations

þ
 '  



ã Ingress nodes: estimate rate Ô for each flow and insert it

in the packets¶ headers


 '  



‡ Ingress nodes: estimate rate for each flow and

insert it in the packets¶ headers

ð
 '  



ã Core node:
- Compute fair rate 2 on the output link
- Enqueue packet with probability

    2  

- Update packet label to Amin(  2 )

è
 '  



ã Egress node: remove state from packet¶s header

è4
 #,
| *
ã Assume estimated fair rate 2 = 4
- flow 1,
= =>     !"#È
6 10
‡ expected rate of forwarded traffic "X 
2
- flow 2,
= 6 =>     !$#È$%
‡ expected rate of forwarded traffic $X 
- flow 3,
= 2 =>     !&#
‡ expected rate of forwarded traffic 2

Core ode (10 Mbps)

m     
 ¢ ¢ ¢ 
    ¢ ¢ ¢ 
 


 

è
 
 
#   
ã (  : rate of aggregate forwarded rate (R) is a
"
monotonic and non-decreasing function of estimated
2 Å
rate
'#  " 2 
$  $ 2    2    " 2  Ú  $ 2  Ú  & 2 
 & 2 
&
 2 
16

10 |

0 2
0 1 2 3 4 6 7 9 10 èè
 
  
#,
h

 

!



 

8
 "
$4&  "
$4& # . 

|"
$& |"
$& 5
ÈÈÈ ÈÈÈ

|"
$è& 4
& |"
$è& 

h
  h   


5
8 
K

 

 

|
  
h5 h5
K* K*


 


h5 h5

 

 

h h
h5 h5
h h
h
5 h
5
h
h

h 5 h 5
h h
hh5 hh5
h h è¢
  h   


5
8    h   


5
8 
K
 K


.

ã 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

èD
 '
 

ã Project feedback
- Œuesday, Feb 14, 12:30-2pm
- Wednesday, Feb 1 , 11:30-1pm

è