[sixlowpan] [UDP] Receiving more packets than the sent ones??

[Ahmed Raoof]

Hi everyone

I'm doing a research on 6LoWPAN, and had this weird problem. I'll start by explaining my simulation model:

• I have 4 nodes: one that is just receiving, and three are just sending nodes.
• I'm using UDP at transport, IPv6 and 6LoWPAN at network layer, and CSMA in a shared channel mode (all nodes are connected to a shared medium, simulating a wireless channel).
  
• UDP client/server application is used to send 100 packets from each sender to the receiver.
• I modified sixlowpan module to reflect my research point of interest, and I made a lot of output lines to check each step, among these outputs I check when a UDP packet is moved to/from 6LoWPAN and I also check when 6LoWPAN send a fragmented packet by outputing the header of FRAG1 and FRAGN fragments at both senders and receiver.
• According to network parameters, one sender should send 40 UDP packets, other one 64 packets, and the third one 100 packets.  In the attributes of UDP client app I set the number of sent packets to 100.

Now, when I run the simulation and count the number of sent/received UDP packets, I was surprised to find that sent packets are more than expected by 2-4 packets, more shocking is that the fragmented packets sent/received is more than that number by 4-7!!! For example the sender that supposed to send 40 is actually sending 42 and received as 43 packets, the one supposed to send 64 is sending 67 and received as 69, and the one that is supposed to send 100 is sending 97 but received as 102... When I change the UDP client attribute of sent packet to different numbers (still larger than the supposed ones) I also notice changes in the number of packets sent/received, I.g. when I change the number of sent packets from 100 to 200 for the sender that is supposed to send 100 packets, I get

 102 sent and 112 received, even though I didn't change any other attribute neither in the channel nor in the UDP client.

For the counting I do the following: I have specific output that include SRC, DST addresses and protocol # once a UDP packet is sent, and for the fragments I have a specific output comes out once a FRAG1 fragment is received that contains SRC, DST addresses and packets's 6LoWPAN tag that is associated with it (Datagram_Tag).

Can any one help me figure out what's the problem?

[Tommaso Pecorella]

Hi,

if you did modify the code, we can't help much more than saying "too bad".

How can we guess what you did if we can't reproduce it ?

For sure you did a mistake, but we can't know (because we're not clairvoyants) where the problem is. You could've added a bug in the model, you could have found a bug in the model, or you could even made a mistake in counting the packets !

Who knows...

T.

[Ahmed Raoof]

Instead of a vague reply that is only for sarcasm, you should've provided a way for debugging or to see where is the problem... So Thanks for nothing.

On my side, I returned the original "untouched" sixlowpan module. Just added "std::cout" lines to output when a fragment is out and when it is in, in addition to their Datagram_Tag and source/destination addresses. I did this for the sake of investigations... The results? Same as what happened in my experiment: More fragmented datagrams than the original UDP Datagrams!

So, I decided to go further: I used the UDP-Echo application (with small modifications: I removed the echo from the server, and set the filling to have a randomly generated number to make each datagram unique) to send custom-filled UDP datagrams. Then I added few lines to sixlowpan and udp modules to output the contents of the datagrams (for sixlowpan I copied the first fragment, removed all its headers/dispatches, then read the contents).

What I found know is the following:-

1) UDP module sends the exact number of datagrams, each one is unique... So no problems on UDP.

2) Sixlowpan start with sending datagrams as what it supposed to do, but then it goes to transmit one datagram many, many times, with different Datagram_Tag, then goes to the next datagram and continue the same pattern (resend with new Datagram_Tag(s)).

On the light of what I did, I believe that there is something wrong at sixlowpan module.... I'm going to investigate more, but if anyone could provide me with more help, I would highly appreciate it

[Tommaso Pecorella]

Hi,

ok, THAT is a good wrong behaviour report. If you're right, then you have found a serious bug.

Make sure that you're using the latest n-3 (3.25 at the moment of writing) and please attach the code showing the problem. I'll take a look at it as soon as possible.

Thanks,

T.

[Erwan Livolant]

Hi Ahmed,

Are you using acknowledgment in your model? If it is so, as you are in a contention situation, packets are retransmitted due to collisions.
So you have 100 packets sent at UDP level but more transmitted at the lower level due to retransmission and maybe less than 100 received.
This is not surrealist.
You should check sequence number of frames at the MAC layer in the receiver in order to suppress duplicate packets.

Best regards,
Erwan

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Ahmed Raoof]

Sorry for being late... I was busy doing more investigations and with adding some comments for you to know what parts I modified in the original NS3 files for the checking process (again, original NS3 codes, with modifications to show outputs).

So, attached are the files (sixlowpan model, udp model and udp echo application... Beside my simulation application)... Here are where each file is supposed to be:-

• mysixlowpanUDP.cc: Is my simulation app, should be in scratch folder.
  
• sixlowpan-net-device.h AND .cc: Sixlowpan model files, should be in ns-3.25\src\sixlowpan\model
  
• udp-echo-helper.h AND .cc: This is the UDP Echo app helper, and it should be in \ns-3.25\src\applications\helper
  
• udp-echo-server.h AND .cc PLUS udp-echo-client.h AND .cc: These are the UDP Echo app files, and they should be in \ns-3.25\src\applications\model
  
• udp-l4-protocol.h AND .cc: This is UDP protocol model, and it should be in \ns-3.25\src\internet\model
  

And to see what I added/modified in each file, just search for "From AhmedRaoof", without the quotation marks.

When you run the simulation, I always redirect the output to a text file, which I then search for these sentences in order to see what's going on:-

• "The contents of the UDP packet just sent are = A1 00:10" : This is to check UDP datagram's contents from my first node, which should send 100 datagrams.
  
• "The contents of the UDP packet just sent are = S1 00:30" : This is to check UDP datagram's contents from my second node, which should send 40 datagrams. 
  
• "The contents of the UDP packet just sent are = S2 00:40" : This is to check UDP datagram's contents from my third node, which should send 64 datagrams.
  
• "The contents of the FRAG1 will be sent (Before fragmentation) are = A1 00:10" : This is to check the contents of the first fragment of the current UDP datagram from first node.
  
• "The contents of the FRAG1 will be sent (Before fragmentation) are = S1 00:30" : This is to check the contents of the first fragment of the current UDP datagram from second node.
  
• "The contents of the FRAG1 will be sent (Before fragmentation) are = S2 00:40" : This is to check the contents of the first fragment of the current UDP datagram from third node.
  
• "The contents of the FRAG1 just received are = A1 00:10" : This is to check the contents of the first fragment that is just received from the first node.
  
• "The contents of the FRAG1 just received are = S1 00:30" : This is to check the contents of the first fragment that is just received from the second node.
  
• "The contents of the FRAG1 just received are = S2 00:40" : This is to check the contents of the first fragment that is just received from the third node.
  

I hope we find what's the problem... and thank you in advance

[Ahmed Raoof]

Hi Erwan

No, I'm not using ACK, I even stopped the echo from UDP-Echo application... And according to my knowledge UDP doesn't have any congestion control...

I used sequence numbers inside UDP datagrams and checked them before being sent and just as received... Also sixlowpan layer gives each datagram that is fragmented a "Datagram_Tag" which is similar to what IPv4 does

[Tommaso Pecorella]

Hi Ahmed, 

I'll take a look at everything as soon as I can, but I have some hard deadline in the next days, sorry.

About the ACKs, probably Erwan meant the 802.15.4 ACKs. They are on by default... check the LrWpanNetDevice "UseAcks" attribute. 
Note that if you do NOT use them you'll have less collisions, but you'll also have a very low packet delivery rate, especially for fragmented packets.

Cheers,

T.

[Tommaso Pecorella]

Hi again,

I checked the files you attached (as a side note, a zip is easier to download), and they're all identical to the normal ns-3 source files, with the exception of your script (of course) and the sixlowpan-net-device.[cc,h].

The problem is that in sixlowpan-net-device.[cc,h] you didn't just add some output lines, you changed how the fragments are handled by nodes.

So, the question is: are you asking about a problem in the model or in your modification of the model ?

Mind, I'm not against contributions to the model, and some of your additions are interesting. However, we need to understand if the behaviour you've noticed is something that you did introduce or something that was already there.

It's a basic rule of bugs. If you find a wrong behaviour, you need to bisect the code and find where in time it was introduced.

T.

[Ahmed Raoof]

Hi Tommaso

I really apologise: It is my bad, I submitted the wrong files for sixlowpan(.cc & .h)... I reattached those two again in here.

So, the problem is actually in the original files, not in my modifications... Also, my modification are mainly at ProcessFragments procedure (which are not included in the attached files) as they are related to handling fragment buffer.

Can I beg you patience and go through these files again? Thank you again for your time

(BTW, I tested TCP through ping application and the problem exists but on a smaller scale)

[Tommaso Pecorella]

Hi,

mind to try your code on the latest ns-3-dev (mind, sixlowpan-net-device had some minor modifications).

The result should be a horrible crash. Why ?

Suggestion... not every packet is UDP (or TCP), and you're printing them as they would all be UDP (or TCP).

Please fix, then if your problem persist (i.e., too many fragments) we'll check again.

T.

[Gonçalo Atanásio]

Hi Ahmed,

I'm trying to mod the dsdv to ipv6 to use over lr-wpan and 6lowpan, with UDP, so I'm very interested on you development with UDP over 6lowpan. Did you find your bug?

Best regards

[Ahmed Raoof]

Hi Tommaso

Excuse my slow mind :P : You want me to try my code (the simulation and the ll the files I put here) in the ns-3-dev?

My intention was to see if there are any packets that are not UDP (or TCP) so I could eliminate those from my count. But as my results showed: only my packets (UDP) were sent and by comparing there contents (which I setup) I found this problem (some packets are resent by sixlowpan many times, when it is not supposed to).

[Ahmed Raoof]

Hi Gonçalo

Sadly, till this moment no... I was also a bit busy with a side work for the few past days, and just today I returned back to my research and to investigate into this problem... Thanks to Tommaso for his help and followup :)

[Gonçalo Atanásio]

OK, thanks a lot. I'm going to follow.

Best regards.

[Gonçalo Atanásio]

Hi, just one more question. I'm trying to use lr-wpan (802.15.4) instead of csma, but I'm not receiving the UDP packets! You know what could be the problem?

[Ahmed Raoof]

Hi everyone

@Tommaso Pecorella, I downloaded the development branch, copied the files I sent you (I mean here in the post) then ran the simulation... It worked normally without a crash.

So, I went to check the numbers of packets and fragments.. This time everything looks good! No packet has been retransmitted, and the number of packets is actually consistent with all the estimations... I then returned to the stable branch and ran the same files again, I got the same problem of retransmission and wrong number of transmitted packets.

I'll try my own "heavily modified" versions of sixlowpan module, and will post my findings here.

So, Do you agree with me that this is a wrong behavior bug in the current stable branch?

@Gonçalo

Sadly, I didn't use lr-wpan (802.15.4), planning to do so after I get my results from my experiment. As I looking for other aspects regarding the lr-wpan.