Upload
daniela-russell
View
215
Download
0
Embed Size (px)
DESCRIPTION
3 Fairness Goals Allocate resources fairly Isolate users –Router does not send explicit feedback to source –Still needs e2e congestion control Still achieve statistical muxing –One flow can fill entire pipe if no contenders –Work conserving scheduler never idles link if it has a packet
Citation preview
1
Fair QueuingFair Queuing
Hamed KhanmirzaPrinciples of NetworkUniversity of Tehran
2
Fairness
3
Fairness Goals• Allocate resources fairly
• Isolate users– Router does not send explicit feedback to source– Still needs e2e congestion control
• Still achieve statistical muxing– One flow can fill entire pipe if no contenders– Work conserving scheduler never idles link if it has a
packet
4
What is Fairness?• MAX-MIN Fairness
– No user receives more than its share– No other scheme satisfy this condition which has higher min allocation
Ui = MIN (Ui,Ri)-
• What does “user” means?– Per source of packet
• Restrict for example File Servers– Per receiver
• Malicious user can reduce receiver bandwidth– Per host process
• Encourage user to start several communication simultaneously– Source-Destination pair
• Allows source consume unlimited resources for different destinations
• However the last one seems the best trade-off
iUU
5
Queuing Algorithm for Fairness
6
Queuing Algorithms• Controls:
– Order of sending packets– Buffer usage
• Queuing Algorithms do not directly affect congestion, must be combined with intelligent queue manager
• Why not simple round robin?– Variable packet length can get more service by sending
bigger packets– Unfair instantaneous service rate
• What if arrive just before/after packet departs?
7
Implementing MAX-MIN Fairness• Generalized processor sharing (GPS)
– Fluid fairness– Bitwise round robin among all queues– We assume we have a server which can service N bits
simultaneously from N flows.– Generally we have a variable keeps amount of service that
each flow has received since last busy period– Objective is equalizing this amount named as “potential”– Approaches differs in way updating potentials
8
Implementing MAX-MIN Fairness• One way is defining “System Potential (Virtual Time)”
function– When a flow goes idle, after activation its potential is set
equal to value of system potential– Different approaches have different functions to maintain
System Potential
9
GPS
10
Packet by Packet GPS• In packet system GPS is not feasible
– Though, scheduler can not update potentials of all flows at the same rate
• One of the well known approaches is WFQ (Weighted Fair Queuing)
• Single flow: clock ticks when a bit is transmitted. For packet i:– Pi = length, Ai = arrival time, Si = begin transmit time, Fi =
finish transmit time– Fi = Si+Pi = max (Fi-1, Ai) + Pi
• Multiple flows:– Send packet with smallest Fi
11
WFQ (Weighted Fair Queuing)
11
1010
1010
Si Fi
q
iii WLSF
),( 1 ii FAiMAXS
Wq = 10
Wq = 1
Wq = 1
12
Delay Allocation• Reduce delay for flows using less than fair share
– Advance finish times for sources whose queues drain temporarily
• Schedule based on Bi instead of Fi
– Fi = Pi + max (Fi-1, Ai) Bi = Pi + max (Fi-1, Ai - )
– If Ai < Fi-1, conversation is active and has no effect
– If Ai > Fi-1, conversation is inactive and determines how much history to take into account
• Infrequent senders do better when history is used
13
PP GPS• Problems
– Needs Sorting at least among active sessions– System Potential Problem
• How we should store? With Time ? How about for variable bit rate servers?
• When we must update System Potential?– How we must assign newly arrived packet potential during a packet is
sending• System Potential is always increasing function of time
– If busy time lasts too long, System Potential maybe overflow– Is It fair enough??
14
WFQ & GPS• Suppose a system from start
– Session 1 has 11 packets with weight 0.5– 10 other sessions has weight 0.05– All packets has 1 unit length– Our system services 1 packet at one time unit
15
WFQ & GPS
WFQ
GPS
16
WFQ & GPS• Impact on Link Sharing & Real Time Service
– Much larger delay bounds• Impact on Feedback-Based Algorithms
– Oscillation of RTT
The Most Exact Approximation : WF2Q
17
WF2Q• selects packet among Eligible ones no from all of the
packets in all sessions (SEFF Policy).
• Eligible means set of packets which has started receiving service in GPS system at time t.
• We have one Start and Finish time for a session not for each packet
18
WF2Q
GPS
WF2Q
19
WF2Q
WFQ
WF2Q
20
WF2Q & WF2Q+• Yes, we achieved better granulity but
– Now we have to sort twice !– How we should compute Virtual Time !– We should run GPS system in background !
• WF2Q+ : Has exactly the same properties with lighter complexity
))(min,)(max()( )()(2
22th
itBiQWFQWFi
QWFStVtV
21
Other Famous Variations• Self Clocked FQ (SCFQ)
– Calculating Virtual Time• V(t) is the finish time of the packet being serviced or was serviced
• Start Time FQ (STFQ)– Calculating Virtual Time
• During busy period, V(t) is the Si of the packet being serviced• At the end of busy period V(t) is Fi of the last packet was serviced
– SSF (Smallest Start time First)
22
Other Simple Approaches• FIFO• Strict Priority
– Starvation– Just for important flow or determined rate flows
• RR– Simply do round robin– Do not consider packet lengths
• DRR (Deficit Round Robin)– Each Queue has a “quantum” based on its weight and a “Deficit
Counter”– In each round can send quantum bytes and the Deficit counter keeps
count of sent bytes and remained quantum– If the queue is empty Deficit counter will be set to zero
23
Deficit Round Robin
50020064700
100
5121024
100100100
Quantum = 1500
DC = 700
DC = 500
DC = 400
√
24
Deficit Round Robin
50020064700
5121024
Quantum = 1500
DC = 700
DC = 100
DC = 400
√
25
Deficit Round Robin
50020064700
1024
Quantum = 1500
DC = 188
DC = 0
DC = 400
26
Deficit Round Robin
50020064700
1024
Quantum = 1500
DC = 1688
DC = 0
DC = 1900
√
27
DRR++
50020064700
100
5121024
100100100
QBE = 1500
DC = 700
DC = 500
DC = 400
QLC = 1000
500250
28
DRR++• Advantages
– Reduces delay comparing with DRR– Reduces burst comparing with PQ
• BUT …– Sensitive to transient bursts
– Hard to configure (QLC)• Esp. for TCP traffic in the core!
– worst-case condition configuration