HC1 & IPHC header compression in 6LoWPAN

[Ruchi Garg]

Hi

   no ---- r ---- n1
 I want to transmit packets from node n0 to n1 through forwarder r. Need to perform this on three cases and compare results on various parameters.
Case1: without compressing IPv6 header
Case2: compressing IPv6 header using HC1 technique (RFC 4944)
Case 3: compressing IPv6 header using IPHC technique (RFC 6282)

Do I need to code HC1 & IPHC (compression & decompression routines) on my own or may I use some precoded module 6LoWPAN of ns3 like sixlowpan-hc1-test.cc, sixlowpan-iphc-test.cc

suggest and guide.

Thx
R.G.

[Tommaso Pecorella]

Hi,

I'd be happy to be able to answer with my usual sarcasm, but recently some people have not took it so well, so I promised to refrain from using it too much.

Moreover, I'm not that sure if sarcasm is really appropriate in your case... your question is ironic enough.

As a consequence, I'll use logic instead of sarcasm.

You know that the "sixlowpan" ns-3 module implements both HC1 and IPHC.

You should know that without IPv6 you can't transmit packets over a WSN, so I guess that your 1st point should be read as "RFC 4944 with no IPv6 header compression".

You could have known (if you'd have read the manual) that you can choose the compression kind (IPHC or HC1).

Hence, the question could have been (at most) how you could use the no IPv6 header "compression". Still, reading the code could have clarified this point.

Now, since you did ask for a completely different thing, there are two options:

1) You're horrible at explaining your questions.

2) You didn't bother to even open the manual.

Since you seems to be quite good with English, I'd rather exclude option 1.

Hence.... read the manual. Feel free to ask anything that is not covered or poorly explained in the manual, but since I did write that part, I know what's there and what's not.

Mind: this is just logic.

T.

[Ruchi Garg]

Dear Tommaso

Thanks a ton for your kind reply!!
You have all the rights to be sarcastic as undoubtedly you are a domain expert and problem solver for thousands of users. I will not be wavered by sarcasm as my focus is achieve the results.

I have studied the examples given in 6Lowpan module very carefully and executed them. Traced the results on tracemetrics(by changing values as well) and also modified it to see results on network animator NetAnim. Read sixlowpan-header.h and .cc files. Read src/sixlowpan/doc/sixlowpan.rst. I am able to relate the codes written for fragmentation, HC1 compression, IPHC etc as I have studied RFC 4944 & 6282 very clearly.

I may not be very good in framing my query.
I wants to transmit data (packets) from source to destination using compressed IPv6 header and without compression.
I wanted to know how to use the codes?

It seems reading the codes of above mentioned points is not enough and I will follow as you suggested to read the manual.
Should I read the manual given on following link!!
https://www.nsnam.org/docs/release/3.24/manual/ns-3-manual.pdf

I am afraid as I am not able to search a dedicated manual for 6Lowpan. Favor me to share the link of manual which you suggested me to read.

thx again!!
R.G.

[Tommaso Pecorella]

Mmm... perhaps the manual *is* missing this point (at least explicitly).

The SixLowPanNetDevice has an Attribute: "Rfc6282". If you set it to true (the default) headers will use IPHC. If set to false they'll use HC1. You can set it for all the devices by using the usual ConfigStore methods (SetDefault).

About the uncompressed IPv6 header, I think I'll have to triple check the code. Right now it's based on an Attribute named "CompressionThreshold" (Default is zero). If a packet is shorter than the threshold, the uncompressed version is used.

However, the code logic is a bit dangerous because there's no check that m_compressionThreshold is less than the NetDevice MTU *and* the packet is sent uncompressed only if it's not fragmented.

In other words: packets could be truncated (if the Threshold is set in a bad way) and only one packet will be sent (no fragmentation). This limitation is logical, as it's a no-brainer that you should send uncompressed packets only if they fit in a datagram. However, it's not rated explicitly that you should *not* fragment a non-compressed header.

I'll update the code, just use ns-3-dev and wait 'til you see the changelog about this discussion. The Attribute is the threshold. If you set it high enough, no compression will be made.

Cheers,

T.

[Ruchi Garg]

Thxx for guidence

R.G.

[Tommaso Pecorella]

Hi,

it should be fixed in ns-3-dev (and 3.25, when it will be released). Now you should be able to set the compression threshold to (say) 1500 bytes and have a nice uncompressed packets - with about a dozen fragments.

For the records (and who's reading this, beside me and Ruchi), sending uncompressed packets seems to be an idiotic idea at first, but it isn't.

1) Uncompressed packets requires much less computational overhead.

2) The compression ratio (i.e., the number of elided bytes Vs the total packet size) is lower with longer packets.

3) Longer packets are fragmented with and without compression: the loss probability is going to be bad in both cases.

4) In some cases you don't want to compress packets, even for small packets.

The 4th case seems totally crazy, but there are some MAC protocols that need a minimum datagram size. Pity that the maximum compressed packet is lower than that, but the IPv6 header alone would be an ok length. Hence, one should be ready to send an uncompressed packet if the packet size is too short. Crazy, isn't it ?

Cheers,

T.

On Tuesday, January 19, 2016 at 8:06:15 AM UTC+1, Ruchi Garg wrote:

Thxx for guidence

R.G.