802.11, receiving packets out of order

461 views
Skip to first unread message

Kenny Mangler

unread,
Apr 21, 2014, 5:11:24 PM4/21/14
to ns-3-...@googlegroups.com
Greetings,

I am trying to use NS3 to simulate a two-node wireless network. Initially, I was working at the application layer, using UDP sockets to send data from one to the other. Within the data, I keep track of the sequence number of each "chunk" of data that gets sent. The chunks are sent sequentially - starting at sequence number 0 and counting up. As long as the packet interval is set to something really high, like 1 second, all the "chunks" arrive in order at the receiver. However, when the packet interval gets set to a smaller value, like 10 ms, the chunks do not arrive in order at the receiver. This is problematic because the protocol we are trying to develop relies on packets being delivered in order.

I have also tried using the netdevice to send and receive packets, and the effect is exactly the same.

All packets being sent are broadcast, if that makes a difference for some reason. The topology is simply two nodes that are very close together, ie, close enough that the loss rate is 0 at any physical rate.

What could be causing the problem, and what can I do to solve it?

Thanks,

Tommaso Pecorella

unread,
Apr 21, 2014, 5:32:53 PM4/21/14
to ns-3-...@googlegroups.com
Hi,

you don't "solve" this, you "cope with it".

Let me explain. UDP is based on IP, and IP doesn't provide any guarantee on anything. In particular it's not guaranteed:
  1. The packet delivery (IP does its best and that's it)
  2. The packet duplication (packets may arrive duplicated)
  3. Packet ordering (packets may arrive out of order)
UDP offers little or nothing more than raw IP, just the port demultiplexing and a (weak) data protection through a checksum.
As a consequence, you have to assume that packets may be lost, duplicated and disordered.

About why ns-3 disorder them... it's simple: nothing is done to prevent this. In the specific case, the disordering may be due to a number of reasons, including the NetDevice and its internal buffers.

How to "cope with it". That's not simple. You can use the same method VoIP uses, as is add a header providing sequence numbers. In the application you'll have to reorder the chunks, trash the duplicates and (eventually) request the retransmission of lost chunks.
Mind that this is perfectly normal, VoIP does it, NFS does it... basically all the protocols based on UDP do that.

Hope this helps,

T.

Kenny Mangler

unread,
Apr 21, 2014, 5:55:21 PM4/21/14
to ns-3-...@googlegroups.com
Thanks for the quick response. That was indeed very helpful, and exactly the sanity check I needed to keep going here.

For this particular project, we are actually working on what could basically be called a layer 2.5 protocol. That is, we don't really care about IP, UDP, or anything above the mac layer really.

Is it possible to feed packets to the MAC layer, and receive them from the MAC layer? Since all the packets are broadcast, they would just be sent with the broadcast MAC address, and picked up by other nodes operating in promiscuous mode or something along those lines. If there's some sort of odd buffering going on in the IP layer, would that fix it?

Thanks again,

-Kenny

Kenny Mangler

unread,
Apr 21, 2014, 5:59:21 PM4/21/14
to ns-3-...@googlegroups.com
I apologize for my NS3 n00b-ness - it is obvious to me that NS3 is a very powerful tool but unfortunately I have a very limited understanding of it.

Tommaso Pecorella

unread,
Apr 22, 2014, 2:27:32 AM4/22/14
to ns-3-...@googlegroups.com
Hi,

it's not n00bness, it's a matter of facing stuff that if often not in the text books (unfortunately).
Let's call it the difference between theory and practice.

About the L2.5 layer, it's not an easy task. Fortunately, there's a good example in ns-3: the sixlowpan module.
While the module is focused on header compression, you can see how it places itself below IP and above a NetDevice. From there you can do whatever processing you want. 
However, mind that the packets it will send may (again) arrive not in order, because one of the disordering elements is the NetDevice.
As a consequence, don't assume that packets are ordered even in a 2.5 shim layer.

Cheers,

T.

Kenny Mangler

unread,
Apr 23, 2014, 4:08:49 PM4/23/14
to ns-3-...@googlegroups.com
is there a quick and dirty way to send and receive data from below the NetDevice, or would that essentially require writing a new NetDevice class?

Thanks,

Tommaso Pecorella

unread,
Apr 23, 2014, 4:20:58 PM4/23/14
to ns-3-...@googlegroups.com
Hi,

not at all, you can hook directly the NetDevice functions. See the PacketSocket class.
  src/network/utils/packet-socket.cc
 
src/network/utils/packet-socket.h

Cheers,

T.

Kenny Mangler

unread,
Apr 23, 2014, 6:48:32 PM4/23/14
to ns-3-...@googlegroups.com
We dug into the mac and phy layers today and it turned out that the re-ordering was actually happening due to random and utterly berserk delays calculated by the mobility helper that we were using. By setting this delay to a constant value, or zero, the packets are both sent and received in order.

Thanks again for your assistance.


On Monday, April 21, 2014 5:11:24 PM UTC-4, Kenny Mangler wrote:
Reply all
Reply to author
Forward
0 new messages