Why Is There a Need to Implement a Weighted Fair Queue? Requirement for transmitting different data types : -Video, voice, data Quality of service requirement -Delay, jitter and loss Optimize utilization of resources

Differences Between a FIFO Queue and a Weighted Fair Queue All traffic in the queue is treated similarly S Queue Output link How does it work? Optimum way to implement the WFQ would be to visit the queues in repeated sequences. In each cycle, the scheduler should serve number of bits equal to the queue weight of each queue.

Weighted Fair Queue Each queue handles a certain traffic category WFQ makes use of extra capacity in serving active queues S1 S2 S3 Queue 1 Queue 3 Queue 2 Output link

Advantages WFQ Queues WFQ can have a control on the delay Better utilization of resources in WFQ

Description of System to Be Modeled N sources N Queues Output link Scheduler

Description of System to Be Modeled 3 queues fed by 3 different sources Each queue is given a weight, which assigns its relative share of the bandwidth when all queues are active

Description of System to Be Modeled For each queue, the share is calculated using the following equation:

Description of System to Be Modeled Why do we need a scheduler ? Scheduler determines the sequence in which the data should be sent to the output link

Concept of Virtual Finish Time (VFT) Packets have to be served as they are VFT solves this problem

Concept of Virtual Finish Time (VFT) SVT is the system virtual time

Flowchart for Queue Was the queue empty when packet arrives YES Update queue status and increase the number of active queue Calculate the packet Virtual Finish Time (VFT) Attach the VFT to the packet and insert the packet in the queue Wait for a new packet to arrive

Flowchart for WFQ Scheduler Access the VFT for the packet at the head of each queue Get the packet with smallest VFT. Update SVT and send the packet on the link Update queue status and decrement the number of active queues Go to serve the next packet Are there active queues If queue becomes empty Set SVT = 0 and wait till a queue becomes active YES

Our Modeling Approach Started from single queue design previously implemented Changes made to accommodate our design

Our Modeling Approach SINGLE QUEUE WFQ -Simple FIFO queue -OPNET commands on queues -3 queues (or N queues) -OPNET commands on subqueues and queues -No need for calculation of VFT and SVT (no need for scheduling packets) -Need to calculate VFT and SVT in order to schedule packets -Created a formatted packet

Our Design Finite State Machine - (2 minutes) - explain interrupts -     -    explain how going from green state to red state is a condition -     -    the arrow for initial state -     -    event driven and not clock driven -     -    explain the path of the packets, explain what each state does

Overview of the Code Previous knowledge of C Use of library functions in OPNET

Some OPNET Functions Used Queue package: op_q_empty () Subqueue package: op_subq_pk_access(subqueue_index, OPC_QPOS_HEAD) op_subq_pk_remove (subqueue_index, OPC_QPOS_HEAD) Packet package: op_pk_get(op_intrpt_strm()) op_pk_total_size_get(pkptr) op_pk_send_forced (pkptr, stream_index)

Challenges in implementation – Formatted Packet Problem - Attach virtual finish time to packet - Best solution

Overview of Code – Formatted Packet How? Field 1: “Packet” Size: inherited Field 2: “VFT” Size: 0 ( draw the formatted packet and explain the fields) (attach virtual finish time to packet, flow chart of the queue) (it was the best solution because it does not influence the length of the packet, and statistics)

How Did We Debug the Code? Proved the sequence of the states by writing to an output file (fprintf commands) Checked the values of the variables Tested the content of the packets by printing it to the console

Sample Output File INITIAL op_sim_time(): 0.0000 weight0 : 8 IDLE STATE op_sim_time(): 0.2234 ARRIVAL packet number (sequence in which they arrive): 1 subqueue 0 active : 0 subqueue 1 active : 1 subqueue 2 active : 0 number of active queues : 1 weight of the active queue : 4.00 which queue became active now : 1 length of the packet :1024.00 calculate the total weight :4.000 the virtual service time :0.333 svt :0.0000 virtual finish time :0.333 Time when packet is inserted :0.2233 Insert_ok:1 SCHEDULER queue1 is active, here is the VF1 :0.333 max_possible_virtual_time :1.333 min vft : 0.333 Current queue from which the packet will be send (my_queue1) 1 packet length (to determine service time) pk_len1 : 1024.0000 service_rate : 3072  

Our Strategies for Testing Simulation using a SIMPLE SOURCE Three test cases used to illustrate the performance of the WFQ: 1. All queues with the same weight 2. All queues with different weights 3. Priority queue

CASE 1: All Queues With the Same Weight (Using Exponential Source) 1024 bps 3072 bps

CASE 1: All Queues With the Same Weight (Using Exponential Source) Traffic Packets Time

CASE 1: All Queues With the Same Weight (Using Exponential Source) Delay Delay Time

CASE 1: All Queues With the Same Weight (Using Exponential Source) Source & Sink Packets Note: Similar to FIFO queue Time

CASE 2: All Queues With Different Weights (Using Constant Source) 1024 bps 3072 bps Weight of Queue 0: 8 Weight of Queue 1: 4 Weight of Queue 2: 3

CASE 2: All Queues With Different Weights (Using Constant Source) Delays Delay Delays are proportional to the weights of the queues Time

CASE 2: All Queues With Different Weights (Using Constant Source) Table Arrival Sequence Queue # of Active Queues Send Sequence 2(q0,q1) 2 1(q1) 1 3(q0,q1,q2) 3 4 1 2(q0,q2) 6 5 2 2(q0,q2) 8 2 9 7

CASE 2: All Queues With Different Weights (Using Constant Source) Table Arrival Sequence Queue # of Active Queues Send Sequence Arrival Sequence Queue # of Active Queues Send Sequence 1(q1) 1 5 2(q0,q1) 2 2(q0,q1) 2 10 3(q0,q1,q2) 2 3 6 3(q0,q1,q2) 2 4 3 1 8 2(q0,q2) 5 2(q0,q2) 11 2(q0,q2) 6 4 2 11 2(q0,q2) 2 7 7 2(q0,q2) 8 9 2(q0,q2) 2 9 2(q0,q2) 12

CASE 2: All Queues With Different Weights (Using Constant Source) Output File IDLE STATE op_sim_time(): 0.2234 ARRIVAL sequence : 1 which queue is active : 1 virtual finish time :0.3333 op_sim_time(): 0.2271 sequence : 2 number of active queues : 2 which queue is active : 0 virtual finish time :0.5OO op_sim_time(): 0.3640 sequence : 3 number of active queues : 3 which queue is active : 2 virtual finish time :1.66666 IDLE STATE op_sim_time(): 0.5511 ARRIVAL sequence : 4 number of active queues : 3 which queue is active : 2 virtual finish time :3.33333 op_sim_time(): 0.5567 SEND Queue from which the packet is sent: 1 # of active queues before sending: 3 New svt :0.0222 op_sim_time(): 0.6297 sequence : 5 which queue is active : 0 svt :0.0222 virtual finish time :0.9583

CASE 3: Priority Queue (Using Exponential Source) 1024 bps 0 bps 2078 bps Weight of Queue 0: 100 Weight of Queue 1: 1 Queue 2 not active

CASE 3: Priority Queue (Using Exponential Source) Delays Delay Time

Analysis When the weights for all queues are the same, the delays for the queues are very similar When the weights are different, the delays and the queue size vary accordingly to the weights

Analysis In the case of the priority queue, the delays for the queue with the highest weight is very small, and the delay for the queue with the lowest weight is very large In summary, the delays for the weighted fair queue are inversely proportional to their weights

Conclusion Designed a WFQ in OPNET using 3 queues Made it dynamic ( N queues ) Tested it with output file Showed the effect of the weights of queues which are fed with similar sources