Bug 854

Summary:	Support DROP_QUEUE reason-code in Ipv4FlowProbe
Product:	ns-3	Reporter:	wilson thong <wilsonwk>
Component:	general	Assignee:	ns-bugs <ns-bugs>
Status:	RESOLVED FIXED
Severity:	minor	CC:	gjcarneiro, mikacros
Priority:	P5	Keywords:	feature-request, patch
Version:	ns-3.7
Hardware:	All
OS:	All
Attachments:	Support DROP_QUEUE reason-code in Ipv4FlowProbe Support DROP_QUEUE reason-code in Ipv4FlowProbe 02

Description wilson thong 2010-03-31 22:32:25 UTC

As of changeset be3fb855c65a (ie. ns-3.7), Ipv4FlowProbe does not probe into queue drop event. The patch attached implements this outstanding piece of codes.

Queue drop event can be listened by connecting a trace sink to the trace source ns3::Queue::Drop. However, Ipv4Header cannot be retrieved at this location because some other layer2 headers (e.g. PppHeader) could be added in the front of the Ipv4Header. Without Ipv4Header, Ipv4FlowProbe does not have enough information to call FlowMonitor for updating packet drop statistics.

The patch resolves this difficulty by using ns3::Tag. A new ns3::FlowProbeTag is introduced. It remembers the necessary attributes from Ipv4Header, and it is added to a packet. When Ipv4ProbeFlow sees a packet drop event from the trace source ns3::Queue:Drop, Ipv4FlowProbe retrieves the FlowProbeTag and reads all the necessary IP attributes before calling FlowMonitor.

See the patch for implementation details.


Thanks,
Wilson

Comment 1 wilson thong 2010-03-31 22:33:24 UTC

Created attachment 805 [details]
Support DROP_QUEUE reason-code in Ipv4FlowProbe

Comment 2 Gustavo J. A. M. Carneiro 2010-04-05 07:22:29 UTC

(In reply to comment #1)
> Created an attachment (id=805) [details]
> Support DROP_QUEUE reason-code in Ipv4FlowProbe

You should rename ns3::FlowProbeTag to ns3::Ipv4FlowProbeTag.

There's an #include <sstream>, which I am not sure if it is needed...

In, Ipv4FlowProbe::QueueDropLogger, if the tag is not found maybe it should abort with an error message?

Comment 3 wilson thong 2010-04-26 03:47:13 UTC

Created attachment 847 [details]
Support DROP_QUEUE reason-code in Ipv4FlowProbe 02

Comments from Gustavo are addressed.

> You should rename ns3::FlowProbeTag to ns3::Ipv4FlowProbeTag.
done.

> There's an #include <sstream>, which I am not sure if it is needed...
removed.

> In, Ipv4FlowProbe::QueueDropLogger, if the tag is not found maybe it should abort with an error message?
Program now aborts if such a tag is not found. More over, program also aborts when Ipv4FlowProbe is trying to add such a tag but the tag is already there.

Thanks for your comments,
Wilson

Comment 4 wilson thong 2010-04-26 03:48:27 UTC

The patches should be pushed in the following order
1st: ``Support DROP_QUEUE reason-code in Ipv4FlowProbe''
2nd: ``Support DROP_QUEUE reason-code in Ipv4FlowProbe 02''

Thanks,
Wilson

Comment 5 Gustavo J. A. M. Carneiro 2010-05-31 08:34:15 UTC

changeset:   6323:2a8ec4aee3b5
tag:         tip
user:        Wilson Thong  <wilsonwk@ee.cityu.edu.hk>
date:        Mon May 31 13:32:24 2010 +0100
summary:     Bug 854 - Support DROP_QUEUE reason-code in Ipv4FlowProbe

I just added a few cleanups to your patches, and documentation that WiFi/WiMax is not supported for DROP_QUEUE (they have no TxQueue, they'd need some changes to support it).

Comment 6 mikacros 2011-09-05 11:26:32 UTC

(In reply to comment #3)
> Created attachment 847 [details]
> Support DROP_QUEUE reason-code in Ipv4FlowProbe 02
> 
> Comments from Gustavo are addressed.
> 
> > You should rename ns3::FlowProbeTag to ns3::Ipv4FlowProbeTag.
> done.
> 
> > There's an #include <sstream>, which I am not sure if it is needed...
> removed.
> 
> > In, Ipv4FlowProbe::QueueDropLogger, if the tag is not found maybe it should abort with an error message?
> Program now aborts if such a tag is not found. More over, program also aborts
> when Ipv4FlowProbe is trying to add such a tag but the tag is already there.


The program aborts if a tag is not found then somme asserts will fail if the packet is not an UDP or TCP packets. The tag is not added for these packets and the " NS_ASSERT_MSG (tagFound, "Ipv4FlowProbeTag is missing"); " is triggered. For example I have an ICMP packet dropped by the device queue that triggers the assert.
The solution is either come back to the "if (tagFound)" or remove all headers before the ipPayload as the following programs. 

   bool LossTraceHelper::RemoveHeaderBeforeIp(Ptr<Packet> p ){
       PacketMetadata::ItemIterator i = p->BeginItem ();
       bool ipHeaderNOk = true;
       uint32_t size = 0;
	while (i.HasNext () && ipHeaderNOk )
	  {
	    PacketMetadata::Item item = i.Next ();
	    if (item.isFragment)
	      {
		NS_ASSERT_MSG(0, "No fragment please");
		switch (item.type) {
		  case PacketMetadata::Item::PAYLOAD:
		    NS_LOG_LOGIC( "Payload");
		    break;
		  case PacketMetadata::Item::HEADER:
		  case PacketMetadata::Item::TRAILER:
		    NS_LOG_LOGIC( item.tid.GetName ());
		    break;
		  }
		NS_LOG_LOGIC( " Fragment [" << item.currentTrimedFromStart<<":"
		  << (item.currentTrimedFromStart + item.currentSize) << "]" );
	      }
	    else
	      {
		switch (item.type) {
		  case PacketMetadata::Item::PAYLOAD:
		    NS_ASSERT_MSG(0, "No ipheaderFind");
		    NS_LOG_LOGIC( "Payload (size=" << item.currentSize << ")");
		    break;
		  case PacketMetadata::Item::HEADER:
		  case PacketMetadata::Item::TRAILER:
		    NS_LOG_LOGIC( item.tid.GetName () << " (");
		    ipHeaderNOk = (item.tid.GetName () != Ipv4Header().GetTypeId().GetName() );
		    if (ipHeaderNOk){
		      size += item.currentSize;
		    }
		    break;
		  }
	      }
	    if (!i.HasNext ())
	      {
		NS_LOG_LOGIC ("the packet is not IP : " << *p); 
		return false;
// 		NS_ASSERT_MSG(0,"error que de l'ip" << *p);
	      }
	  }
	  NS_LOG_LOGIC("packet before : " << *p);
	  p->RemoveAtStart(size);
	  NS_LOG_LOGIC("packet after : " << *p);
	  return true;
	
   }





> Thanks for your comments,
> Wilson

Comment 7 Gustavo J. A. M. Carneiro 2012-02-08 05:02:07 UTC

I forgot your last comment, and meantime bug 1302 appeared related to it.  I discuss it there.