Re: [lp-wan] An SCHC implementation and evaluation paper

[<[e-mail]>]

Great, thanks !
Comments inlined.
Happy to carry on this thread if you feel so inclined.

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Bart Moons <[e-mail]<mailto:[e-mail]>>
Date : Monday 29 April 2019 17:00
À : Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] An SCHC implementation and evaluation paper

Dear Dominique,

If we take a packet of 128 bytes and the underlying technology provides a MTU of 51 bytes and we use the following configuration:

FCN_SIZE                = 3;
W_SIZE                  = 1;
DTAG_SIZE               = 0;
MIC_SIZE                = 32;
RULE_SIZE               = 8;
HEADER_RESIDUE          = 0;

So each fragment has a 12 bit overhead. The last one 44 bit overhead. This gives 68 bit header overhead in total. To fill the remaining bits, 4 bits of padding are added to the end. This results in a total of 9 bytes overhead.
[DB] Makes perfect sense, thanks!
3 fragments are required in downlink in response to the SCHC compressed CoAP request. Also an SCHC ACK is required. This gives a total of 5 packet exchanges.


The compression header in figure 3 is used to represent the rule id and is indeed a bit misleading. The compression header is used to represent the rule id, while the first fragment will carry the compression residue (which is 0 in this case) as well as the remaining payload bytes.
[DB] OK, thanks. I understand now. SCHC C should read "RuleID" and SCHC F is W + FCN.
But we actually remove the rule id from the compression header when a packet is fragmented and restore this on the receiving side when all fragments are received.
[DB] do you mean you assume you have only one compression Rule and it always matches?

We are still exploring the proposed LSCHC (Layered SCHC,  proposed by K. Abdelfadeel), and that is also what I implemented. However, since these fields can be added together in one IPv6+UDP rule, the result of the calculation will remain the same.
Hence, when using 3 UDP rules and 2 IPv6 rules, the layered form will be more efficient..
{DB] I guess you mean "efficient" in Rule table size. In terms of bits transmitted over the air, the unlayered form is more efficient, I think.
I think it also makes sense to split IPv6 and UDP rules, as the CoAP spec implies this behavior.
[DB] can you elaborate on this? Do you mean the actual CoAP spec (RFC7252) or the draft-ietf-lpwan-coap-static-context-hc draft?
[DB] the cases where multiple compression is required is for encrypted layers (such as OSCORE).  I can imagine that for large numbers of protocol variants or flows, it would also save device memory (rule table) as stated in the LSCHC paper.
This will also make it easier to compress multiple layer 4 protocols (like TCP).

Hopefully this makes this a bit more clear.

Kind regards,
Bart


Bart Moons
Ghent University - imec
IDLab

iGent Tower - Department of Information Technology
Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium<https://maps.google..com/?q=Technologiepark-Zwijnaarde%2015%2C%20B-9052%20Ghent%2C%20Belgium>
[e-mail]<mailto:[e-mail]> [phone]<tel:%20+32%20472%2042%2023%2091>
http://IDLab.UGent.be
http://idlab.technology

On Apr 29 2019, at 2:43 pm, [e-mail]<mailto:[e-mail]> wrote:

Hello Bart,

Thanks for bringing this paper to our attention. This is very relevant and timely work.
Needless to say, I'm delighted with the conclusions!
I must say I was unable to recompute by myself the numbers that appear in Table 1, in relation with Fig 3. Would you care explaining them further (for the SCHC column)?
A few other points :

  *
in Fig 3, you have a Fragment drawing for SCHC showing SCHC C | SCHC F | Payload. Would you care explaining it? I would expect the Compression header to be inside (to the right of) the Fragmentation header, and only for the first fragment.
  *
In Section IV.B, you mention 2 rules for UDP and 2 rules for IPv6. Do you mean you do successive SCHC compression of the various layer headers? I would expect to have rules that do UDP+IPv6 in one go, as a flat compound header. This is the way the SCHC draft describes them (in Appendix)

Thanks again for this great work

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Bart Moons <[e-mail]<mailto:[e-mail]>>
Date : Monday 29 April 2019 12:35
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : [lp-wan] An SCHC implementation and evaluation paper

Dear all,

Here (https://biblio.ugent.be/publication/8613162) you can find a new paper conforming an SCHC evaluation and implementation which was presented two weeks ago during the WF-IoT conference.
We did an evaluation of our embedded C implementation and justify the existence of this new protocol.
We are still planning to continue our work and provide a more in detail evaluation of the implementation, which I will certainly share in the near future with this mailing list.

Feedback and questions are much appreciated!

Kind regards,

Bart


Bart Moons
Ghent University - imec
IDLab

iGent Tower - Department of Information Technology
Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium<https://maps.google.com/?q=Technologiepark-Zwijnaarde%2015%2C%20B-9052%20Ghent%2C%20Belgium>
[e-mail]<mailto:[e-mail]> [phone]<tel:%20+32%20472%2042%2023%2091>
http://IDLab.UGent.be
http://idlab.technology



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.