Subject: Re: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

From: <[email-masked]>
Date: Thu, 2 May 2019 15:06:30 +0000

Hello Olivier,

I just went through the new text. Great work!

I have the following comments (in order of appearance in the text). They are mostly editorial, except for one: suggestion to use a 5-bit RuleID for Fragmentation (but still 6-bit RuleID for compression), see below:
- Section 3, Fig 1. We have produced a better figure, we believe, that you could reuse. It's Fig 5 in I-D.ietf-lpwan-ipv6-static-context-hc. The source code is available at https://github.com/lp-wan/ip-compression
- Section 5.2. You don't have to have the same RuleID length for Fragmentation and Compression. Using only 5 bits for Fragmentation Rule ID might save you one byte on the ACK, see below.
- Section 5.5.1: FPortUpShort. I guess you mean "Used when fragmentation is required …"
- Section 5.5.1: There is a formatting problem in the FportUpDefault bullet point (at least in my rendition). "Both rules …" should appear un-indented, I suppose.
- Section 5.5.1: Retransmission and inactivity timer. "At the end of a window the ACK corresponding to this window is transmitted by the network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot of end-device if tiles are missing. If this ACK is not received the end-device sends an all-0 (or an all-1) fragment with no payload to request an ACK retransmission.". It seems to me that you are forcing an ACK-Always behaviour, is this intended? Are you sure you do not want to save on the downlink and use the roll-back possibility of the 4 windows?
- Section 5.5.1.1: "In order to minimize ACK, windows size is set to 0." Do you mean minimizing the size of the ACK or the frequency of occurrence of the ACK? I think this sentence could just be left out.
- Section 5.5.1.1, Fig 6: regarding padding, I think it is "either 7 or 0 bits". If the bitmap gets truncated, then there are 0 bits of padding, by the truncation algorithm. If the bitmap is not truncated, then 1+1+127=129 bits, which requires 7 bits of padding.
- Section 5.5.1.2: "62 available for user". The notion of "user" is very vague. I suggest you write "available for compression".
- Section 5.5.1.2, Fig 8.: "Remaining tile, if any". There can be only one tile in the All-1 fragment.
- Section 5.5.1.2, Fig 9. and 10. Should be merged in one. The -18 version of the SCHC draft does not distinguish All-0 ACK and All-1 ACK anymore. The C bit is always present. Given the other field sizes, padding is "either 7 or 0 bits". You could make it "always 0 bits" by having Rule ID be 5 bits for fragmentation (0b'00000), which would leave 31*2 combinations for SCHC C/D (including one reserved for no matching compression rule), therefore 61 rules available for the "user"/compression.
- Section 5.5.2, RuleID: I guess you mean 62 for the user.
- Section 5.5.2, Fig 14. Padding will always be 0 bits, given the other field sizes.
- Section 5.5.2, Fig 15 and 16. Should be merged in one. C bit always present. A good reason to use RuleID on 5 bits for downlink fragmentation.
- Section 5.5.2.1 and 5.5.2.2: our draft has moved away from the term "ACK Fragment", which was confusing, to "ACK message". Sorry for the moving target!
Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Olivier Gimenez <[email-masked]<mailto:[email-masked]>>
Date : Thursday 2 May 2019 11:16
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

Dear,

We created an new version 04 of draft-ietf-lpwan-schc-over-lorawan where we defined all required parameters to implement a profile, which is now:

·         Uplink (device->SCHC gateway) uses Ack-on-Error

o   SCHC header can be 1 or 2 bytes

·         Downlink (SCHC gateway->device) uses Ack-Always

o   SCHC header is 1 byte

You can find the document at https://github.com/Acklio/schc-over-lorawan/tree/draft-version-04 and see the commit since April, 04 for a full list of changes.

We plan to update the document to revision 04 by May, the 17th if you agree.

Best regard
Olivier

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 2 May 2019 15:12:30 +0000

I forgot one more comment:
- Appendix A: the examples seem to be outdated compared to the text, but I guess you knew that.

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Thursday 2 May 2019 17:06
À : Olivier Gimenez <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] Update draft-ietf-lpwan-schc-over-lorawan to draft-04

Hello Olivier,

Dominique

Dear,

o   SCHC header is 1 byte

Best regard
Olivier

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 6 May 2019 08:58:24 +0000

Thank you Dominique for all your comments, I updated the document including all of them but the “5 bit rule id in compression”, which I will send you a separate email.
I will update the examples when this will be solved.

https://github.com/Acklio/schc-over-lorawan/tree/draft-version-04

Olivier