Discrepancy in packets received via receive callback versus trace files

[Kevin Peters]

I have a receive callback setup on my single sink node to record
whenever a packet is received from other nodes in the simulation.
The callback does get and report some packets that are received, but
nowhere near as many received UDP packets that I see in the trace file
or the pcap file for the sink node. As an example, for the duration
of my simulation run, I see the trace and pcap file record ~8500 UDP
packets received by the sink whereas the receive callback only gets
~1500 packets.

I want to rely on the receive callback because I record other
information about that particular simulation run like the number of
nodes, mobility model, etc. so I can easily compare different
simulation runs. When looking at the trace and pcap files, I do not
see a difference between the packets that make it up to the receive
callback and those that do not.

What can cause this discrepancy? What areas can I look at that would
prevent packets from getting up to the receive callback of the Socket?

[Mathieu Lacage]

On Tue, Dec 15, 2009 at 4:46 AM, Kevin Peters <kev...@gmail.com> wrote:

I have a receive callback setup on my single sink node to record
whenever a packet is received from other nodes in the simulation.
The callback does get and report some packets that are received, but
nowhere near as many received UDP packets that I see in the trace file
or the pcap file for the sink node.  As an example, for the duration
of my simulation run, I see the trace and pcap file record ~8500 UDP
packets received by the sink whereas the receive callback only gets
~1500 packets.

I suspect that your mention below of mobility models means that you are using the wifi MAC/PHY models. If so, the wifi trace hooks record all packets going on the medium and this includes data packet retransmissions with duplicates being supressed at the wifi MAC reception layer to avoid forwarding them to the ip layer. Depending on your configuration, it could also include all control messages (i.e., wifi MAC-level ACKs). I want to rely on the receive callback because I record other

information about that particular simulation run like the number of
nodes, mobility model, etc. so I can easily compare different
simulation runs.  When looking at the trace and pcap files, I do not
see a difference between the packets that make it up to the receive
callback and those that do not.

What can cause this discrepancy?  What areas can I look at that would
prevent packets from getting up to the receive callback of the Socket?

 

Mathieu
--
Mathieu Lacage <mathieu...@gmail.com>

[Kevin Peters]

On Tue, Dec 15, 2009 at 1:37 AM, Mathieu Lacage <mathieu...@gmail.com> wrote:

On Tue, Dec 15, 2009 at 4:46 AM, Kevin Peters <kev...@gmail.com> wrote:

I have a receive callback setup on my single sink node to record
whenever a packet is received from other nodes in the simulation.
The callback does get and report some packets that are received, but
nowhere near as many received UDP packets that I see in the trace file
or the pcap file for the sink node.  As an example, for the duration
of my simulation run, I see the trace and pcap file record ~8500 UDP
packets received by the sink whereas the receive callback only gets
~1500 packets.

I suspect that your mention below of mobility models means that you are using the wifi MAC/PHY models.

 

Correct (I should have mentioned that). 

 

If so, the wifi trace hooks record all packets going on the medium and this includes data packet retransmissions with duplicates being supressed at the wifi MAC reception layer to avoid forwarding them to the ip layer.

 

Is there a trace besides the default Phy/State/RxOk and Phy/State/Tx traces that YansWifiPhyHelper sets up that would show packets actually passed up to the IP layer?  MacRxDrop doesn't seem to be for dropping duplicates.

 

Depending on your configuration, it could also include all control messages (i.e., wifi MAC-level ACKs). 

 

I make sure to only look at received UDP packets with a payload of 1000 bytes (which is how large I have configured the packets to be sent to the sink).

 

 

I want to rely on the receive callback because I record other
information about that particular simulation run like the number of
nodes, mobility model, etc. so I can easily compare different
simulation runs.  When looking at the trace and pcap files, I do not
see a difference between the packets that make it up to the receive
callback and those that do not.

What can cause this discrepancy?  What areas can I look at that would
prevent packets from getting up to the receive callback of the Socket?

 

Mathieu
--
Mathieu Lacage <mathieu...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Mathieu Lacage]

On Tue, Dec 15, 2009 at 6:03 PM, Kevin Peters <kev...@gmail.com> wrote:

If so, the wifi trace hooks record all packets going on the medium and this includes data packet retransmissions with duplicates being supressed at the wifi MAC reception layer to avoid forwarding them to the ip layer.

 

Is there a trace besides the default Phy/State/RxOk and Phy/State/Tx traces that YansWifiPhyHelper sets up that would show packets actually passed up to the IP layer?  MacRxDrop doesn't seem to be for dropping duplicates.

The PHY layer obviously does not know which packets will be dropped during duplicate detection at the MAC layer but the MAC layer should give you only the packets forwarded to the upper layer with the Mac/MacRx trace source. See wifi/wifi-mac.h/cc

If the above does not work, I am out of ideas: you could try to post your example script or the pcap trace you generate.
 

[Kevin Peters]

My main motivation for looking into this is I cannot figure out why the PDR is so poor for my simulations.

 

I am working on a GPS based routing protocol for high speed aeronautical networks.  Basically, the simulation is of 60 nodes moving up to 1200 m/s in a 150km  squared area.  They are all sending data at a constant rate to a non-mobile sink that is right in the middle of the map.  The nodes have a 27800m transmission range based on setting the transmission power to 94.  I came up with this transmission power with a simple non-mobile two node scenario where the nodes were able to communicate with a transmission power of 94, 1000 byte packet, wifib-11mbs, and LogDistancePropagationLossModel.

 

Based on randomly placing 60 nodes in the 150km map with a 27800 transmission range, I would expect the network to be connected for the most part.  However, the PDR is almost 0% when the nodes are non-mobile. 

 

To keep things simple and my custom routing out of the picture, I see similiar poor PDR with OLSR that I see with my GPS routing protocol.  The attached script illustrates this and generates the data in the attached spreadsheet.  The graph I made in the spreadsheet from this data shows packets delivered per second to the sink for OLSR for both non-mobile and random waypoint mobility when the sending rate of the nodes is 1 packet/s.  You can see that with the non-mobile scenario, almost no packets are delivered.  For the mobile scenario, the peak packets/s is 4.  At 100% PDR, I would expect to see 60 nodes * 1 packet/s = 60 packets/s.  AND this is with a slow 1 packet/s sending rate (aggregate of 8kbs*60nodes = ~.5Mbs).

 

I cannot figure out why the PDR is so poor (especially for non-mobile).  I can see from my GPS based routing logging that all of the nodes are getting updated routing beacons from other nodes but not very many of the actual data packets make it to the sink.  I use a similar beaconing mechanism as OLSR so I assume the OLSR nodes are also getting updated routing information (OLSR and my GPS routing have similar PDR results as well).  The flowmonitor output also shows that the routing beacon flows have very good PDR but the data packet flows do not.

 

I am running ns3.6.

 

Thanks for looking into this as I'm really struggling with tuning and identifying the bottleneck to tweak for better throughput for larger simulations like this.

 

-Kevin

[Mathieu Lacage]

On Thu, Dec 17, 2009 at 6:39 PM, Kevin Peters <kev...@gmail.com> wrote:

On Thu, Dec 17, 2009 at 2:17 AM, Mathieu Lacage <mathieu...@gmail.com> wrote:

On Tue, Dec 15, 2009 at 6:03 PM, Kevin Peters <kev...@gmail.com> wrote:

If so, the wifi trace hooks record all packets going on the medium and this includes data packet retransmissions with duplicates being supressed at the wifi MAC reception layer to avoid forwarding them to the ip layer.

 

Is there a trace besides the default Phy/State/RxOk and Phy/State/Tx traces that YansWifiPhyHelper sets up that would show packets actually passed up to the IP layer?  MacRxDrop doesn't seem to be for dropping duplicates.

The PHY layer obviously does not know which packets will be dropped during duplicate detection at the MAC layer but the MAC layer should give you only the packets forwarded to the upper layer with the Mac/MacRx trace source. See wifi/wifi-mac.h/cc

If the above does not work, I am out of ideas: you could try to post your example script or the pcap trace you generate.
 

 

My main motivation for looking into this is I cannot figure out why the PDR is so poor for my simulations.

PDR = Packet Drop Rate ? How do you measure it ? at the application layer ?
 

I am working on a GPS based routing protocol for high speed aeronautical networks.  Basically, the simulation is of 60 nodes moving up to 1200 m/s in a 150km  squared area.  They are all sending data at a constant rate to a non-mobile sink that is right in the middle of the map.  The nodes have a 27800m transmission range based on setting the transmission power to 94.  I came up with this transmission power with a simple non-mobile two node scenario where the nodes were able to communicate with a transmission power of 94, 1000 byte packet, wifib-11mbs, and LogDistancePropagationLossModel.

 

Based on randomly placing 60 nodes in the 150km map with a 27800 transmission range, I would expect the network to be connected for the most part.  However, the PDR is almost 0% when the nodes are non-mobile. 

 

To keep things simple and my custom routing out of the picture, I see similiar poor PDR with OLSR that I see with my GPS routing protocol.  The attached script illustrates this and generates the data in the attached spreadsheet.  The graph I made in the spreadsheet from this data shows packets delivered per second to the sink for OLSR for both non-mobile and random waypoint mobility when the sending rate of the nodes is 1 packet/s.  You can see that with the non-mobile scenario, almost no packets are delivered.  For the mobile scenario, the peak packets/s is 4.  At 100% PDR, I would expect to see 60 nodes * 1 packet/s = 60 packets/s.  AND this is with a slow 1 packet/s sending rate (aggregate of 8kbs*60nodes = ~.5Mbs).

 

I cannot figure out why the PDR is so poor (especially for non-mobile).  I can see from my GPS based routing logging that all of the nodes are getting updated routing beacons from other nodes but not very many of the actual data packets make it to the sink.  I use a similar beaconing mechanism as OLSR so I assume the OLSR nodes are also getting updated routing information (OLSR and my GPS routing have similar PDR results as well).  The flowmonitor output also shows that the routing beacon flows have very good PDR but the data packet flows do not.

It really unclear to me what you are measuring and how but I did run your example program and looked at the generate wifi pcap files as well as looking at the NS_LOG=AdhocWifiMac output. Both appear to show that, indeed, data packets are being forwarded up the stack to ipv4 from the MAC layer so, if you are measuring your reception rate at a higher level layer, then, they are getting lost somewhere in-between.

NS_LOG=Ipv4L3Protocol might help you a bit. Maybe you just need to put a breakpoint in the Ipv4L3Protocol::Receive method and look at what is happening to your packets with a debugger.
 

Mathieu

--
Mathieu Lacage <mathieu...@gmail.com>

[Kevin Peters]

PDR = packet delivery ratio

I am measuring the PDR at the application level via a receive callback on the sink Socket.  I also see the same numbers when using FlowMonitor.

There are definitely packets being delivered to the sink but nowhere near as many as there should be.  I can see the expected number of packets are getting sent at the routing layer but not very many end up at the next hop or at the Socket receive callback of the sink node.

I will try the Ipv4l3 logging that you suggested.

The low packet delivery seems to rear its ugly head with many nodes sending.  Is there a way just to follow one single packet out of 1000s of packets in detailed mode?   Its difficult to see what is going on when lots of logging is enabled for all packets.

Thanks,
Kevin

On Dec 18, 2009 7:36 AM, "Mathieu Lacage" <mathieu...@gmail.com> wrote:

On Thu, Dec 17, 2009 at 6:39 PM, Kevin Peters <kev...@gmail.com> wrote: > > On Thu, Dec 17, 2009 at ...

PDR = Packet Drop Rate ? How do you measure it ? at the application layer ?
 

> > I am working on a GPS based routing protocol for high speed aeronautical networks.  Basically, ...

It really unclear to me what you are measuring and how but I did run your example program and looked at the generate wifi pcap files as well as looking at the NS_LOG=AdhocWifiMac output. Both appear to show that, indeed, data packets are being forwarded up the stack to ipv4 from the MAC layer so, if you are measuring your reception rate at a higher level layer, then, they are getting lost somewhere in-between.

NS_LOG=Ipv4L3Protocol might help you a bit. Maybe you just need to put a breakpoint in the Ipv4L3Protocol::Receive method and look at what is happening to your packets with a debugger.
 

Mathieu

--

Mathieu Lacage <mathieu...@gmail.com>

-- You received this message because you are subscribed to the Google Groups "ns-3-users" group. T...

[Mathieu Lacage]

On Fri, Dec 18, 2009 at 5:47 PM, Kevin Peters <kev...@gmail.com> wrote:

PDR = packet delivery ratio

I am measuring the PDR at the application level via a receive callback on the sink Socket.  I also see the same numbers when using FlowMonitor.

There are definitely packets being delivered to the sink but nowhere near as many as there should be.  I can see the expected number of packets are getting sent at the routing layer but not very many end up at the next hop or at the Socket receive callback of the sink node.

I will try the Ipv4l3 logging that you suggested.

Yes, you need to pick a couple of arbitrary packets to figure out which layers they reach and where they disappear.
 

The low packet delivery seems to rear its ugly head with many nodes sending.  Is there a way just to follow one single packet out of 1000s of packets in detailed mode?   Its difficult to see what is going on when lots of logging is enabled for all packets.

Print the packet uid and grep for it ? I don't believe that the default Packet::Print method outputs it.

[Gustavo Carneiro]

2009/12/18 Mathieu Lacage <mathieu...@gmail.com>

But with fragmentation and Packet::Copy the UID becomes unreliable.  It is probably safer to follow via the "identifier" in the IPv4 header.

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Mathieu Lacage]

On Fri, Dec 18, 2009 at 6:50 PM, Gustavo Carneiro <gjcar...@gmail.com> wrote:

On Fri, Dec 18, 2009 at 5:47 PM, Kevin Peters <kev...@gmail.com> wrote:

PDR = packet delivery ratio

I am measuring the PDR at the application level via a receive callback on the sink Socket.  I also see the same numbers when using FlowMonitor.

There are definitely packets being delivered to the sink but nowhere near as many as there should be.  I can see the expected number of packets are getting sent at the routing layer but not very many end up at the next hop or at the Socket receive callback of the sink node.

I will try the Ipv4l3 logging that you suggested.

Yes, you need to pick a couple of arbitrary packets to figure out which layers they reach and where they disappear.
 

The low packet delivery seems to rear its ugly head with many nodes sending.  Is there a way just to follow one single packet out of 1000s of packets in detailed mode?   Its difficult to see what is going on when lots of logging is enabled for all packets.

Print the packet uid and grep for it ? I don't believe that the default Packet::Print method outputs it.

But with fragmentation and Packet::Copy the UID becomes unreliable.  It is probably safer to follow via the "identifier" in the IPv4 header.

In that case, no fragmentation is performed, hence my suggestion to use the uid. Packet::Copy does not change anything to the uid so, it should be safe in this case.
 
Mathieu

--
Mathieu Lacage <mathieu...@gmail.com>

[Kevin Peters]

The first problem I found was I had all 60 nodes' OnOff application starting at the exact same time.  I changed it such that they all start at a random time between 30 and 31 seconds in the simulation.  This definitely helped throughput.  However, even after this, I still only get a PDR peaking at around 60%.

 

I've also updated my OLSR with patches from http://www.nsnam.org/bugzilla/show_bug.cgi?id=733, http://www.nsnam.org/bugzilla/show_bug.cgi?id=740, and http://www.nsnam.org/bugzilla/show_bug.cgi?id=780.

 

I enabled Ipv4L3Protocol logging.  I looked through ipv4-l3-protocol.cc's code (the class that defines Ipv4L3Protocol logging component), and the logging that would indicate a problem with the packet (no route, interface is down, etc.), seemed to all contain the word "drop".  When running the simulation, I did not find any Ipv4L3Protocol logging with the word "drop" (I also added missing message for when packet is dropped due to bad checksum).

 

I added UID to Packet::Print so I could see the packet ID in the trace file.  I also changed Ipv4L3Protocol::Receive and Ipv4L3Protocol::Send to log out the packet ID.  Unfortunately, I could not get the packet ID on my sink Socket within the simulation script because I get a seg fault at:

 

#0  0x101b93ea in ns3::PacketMetadata::GetUid (this=0x24) at ../src/common/packet-metadata.cc:965
#1  0x101de32a in ns3::Packet::GetUid (this=0x0) at ../src/common/packet.cc:392
#2  0x00401998 in AeroExperiment::ReceivePacket (this=0x22cbd0, socket={m_ptr = 0x1504d410})
    at ../scratch/usergroup-simulation.cc:116

 

 

The only thing significant that I could find was comparing the tracing from "WifiNetDevice/Phy/State/RxOk" and "WifiNetDevice/Phy/State/Tx" (when setting YansWifiPhyHelper::EnableAsciiAll) with detailed logging in the routing protocol I am working on.  For a specific packet ID that I followed that didn't make it to the destination, I can see that the last node to get the packet can hear routing beacons from the destination (confirmed through Phy trace and routing trace), and so the routing decision is made to send to the destination.  However, I can see through the Phy tracing that the packet ID is transmitted by the source but never received by the destination (other nearby neighbors do receive the packet though).  So, the problem, at least for this specific packet, does not seem to be at IP.

 

My theory was that maybe "boundary" nodes that are just at the transmission range can exchange beacons with each other but have issues when transmitting larger data packets.  To test this theory, instead of using the random rectangle position allocator, I used the grid position allocator to evenly separate the nodes (vertically and horizontally) by 15,000m which is well within the transmission range of 27,800m, and makes the nodes tighter together than randomly placing them throughout a 150,000m X 150,000m layout like I was.  This actually made things worse and reduced the PDR by almost 50% (true for both my custom routing protocol and OLSR).

 

So, I'm stuck and still having problems getting decent PDR even with this low data rate and non-mobile nodes.  I've attached my latest script that has the staggered OnOff application starting times and commented out grid position allocator.  Any ideas on how to further troubleshoot?  Do you think setting up "PhyRxDrop" trace from wifi-phy.cc would help?

 

Thanks,

Kevin

[peters...@gmail.com]

hi，Kevin，I am learning aeronautical networks and can't find the ns3 module,do u have the aeronautical networks module in ns3? Thx a lot!

在 2009年12月19日星期六 UTC+8上午12:47:38，Kevin Peters写道：