Skip to content

Implementation progress updates

Sumukha Pk edited this page Nov 11, 2018 · 28 revisions

Files added/changed :

  • fq-pie-queue-disc.h
  • fq-pie-queue-disc.cc
  • fq-pie-example-udp.cc
  • fq-pie-example-tcp.cc
  • pie-example-udp.cc
  • pie-example-tcp.cc

Implementation of fq-pie-queue-disc.cc

  • DoEnqueue : The incoming packet is hashed on to the right queue using, h = item->Hash (m_perturbation) % m_flows; or h = ret % m_flows;. Then the dropping routine occurs the queues. (To be thought of, based on which queue drops occur in and how the queues enqueue). The routine for enqueuing must be :
  1. Find where the packet must be hashed to.
  2. If there is no matching hash, create a new flow.
  3. If the packet filter is not able to hash the packet, drop the packet(doesnt belong here)
  4. After the above routine to manage flow queueing, PIE takes over.
  5. Here we have to change PIE to work on the flow/queue we have chosen to hash the packet in. (This is done by assigning the selected flows, queue disc to the PIE algorithm to work on.)
    Create a new flow -> flow = m_flowFactory.Create<FqPieFlow> ();
    Create a new queue disc-> qd = m_queueDiscFactory.Create<QueueDisc> ();
    Inititalising the queue disc -> qd->Initialize ();
    Assigning the queue disc to the flow-> flow->SetQueueDisc (qd);
  6. After this, rest is the DropEarly or Drop-due-to-no-space routine. Here the above queue disc, qd is passed on.
  7. If the packet passes all the above conditions, it is enqueued. Like shown : bool retval = qd->GetInternalQueue (0)->Enqueue (item);
  8. Whenever a new flow is created, it has its parameters initialised to desired values. Like dropProb , qDelayold etc.
  • DoDequeue : Here the DRR algorithm is used in order to determine which queue has to dequeue. While checking for flows to dequeue, new flows are checked first. A flow is rendered old right after its checked for a packet to DQ. If there are no appropriate packets in new flow, an old flow is considered. (Dont know how old and new flows are populated, debate on this)

  • CalculateP : This is linked to Simulator::Schedule() which runs this function every mt_Update unit of time. Here we need to make the function to run for every queue/flow that is present. Thus necessary changes have been made. We altered the function to take in a parameter (flow) and apply the function to only that flow. We make the simulator run a new function we created, CalculatePFlow which calls the function CalcluateP for each flow.

  • The QueueDiscSizePolicy is set to MULTIPLE_QUEUES, we still have to figure out about the addition of quantum of deficit to the queues(DRR related- added to how many of the queues and when)

Other parameters of PIE have to be plugged into the functions. (Parameters must be independent for each queue, which is maintained as a flow in the form of a std::list)

Implementation of fq-pie-example(tcp-udp).cc

The following dumbbell topology is set up:

   10Mb/s, 2ms                            10Mb/s, 4ms
   n0--------------|                    |---------------n4
                   |    1.5Mbps, 20ms   |
                   n2------------------n3
      10Mb/s, 3ms  |  QueueLimit = 100  |    10Mb/s, 5ms
   n1--------------|                    |---------------n5
  

Currently the changes are limited to installing a different traffic control mechanism in the same topology as used for pie-example. All these necessary changes and dependency requirements are met. Further plans are to write a new topology for the same. To check whether Flow queueing is happening, we set one of the nodeContainers to have UDP and other as TCP as their Transport Protocol. This enables us to figure out if both TCP and UDP have a fair chance at the bottleneck in the topology of the network. For the above we created 2 files, one each for the protocols tcp and udp being set up on one of the links. We also split pie-example into 2 files so that we can compare the same with flow-queueing implemented.

Implementation of fq-pie-queue-disc.h

  • New functions used are to be added in here along with the variables and constants. Unused variables and functions have to be cleaned up.
  • A new flow class called FqPieFlow was added to maintain the multiple flows. So the flows will be maintained in a list, each based on this class.
  • Variables like ObjectFactory m_flowFactory , ObjectFactory m_queueDiscFactory , std::list<Ptr<FqPieFlow> > m_newFlows , std::list<Ptr<FqPieFlow> > m_oldFlows are added to facilitate the added features.