Subject: [lp-wan] Implementation of SCHC

From: Rodrigo Muñoz Lara <[email-masked]>
Date: Mon, 16 Dec 2019 13:36:05 -0300

Dear Author,

I have three questions about the draft:

   1. The draft "draft-ietf-lpwan-ipv6-static-context-hc-22" indicates that
   in the profile of each technology the penultimate Tile size must be
   defined. On the other hand, in the draft
   "draft-ietf-lpwan-schc-over-lorawan-04" there is no definition in this
   regard. Can I consider that the penultimate tile size is the size of a
   regular tile?
   2. In section 8.4.3.1, the draft
   "draft-ietf-lpwan-ipv6-static-context-hc-22", indicates that: "A Rule MUST
   NOT be selected if the values of M and WINDOW_SIZE for that Rule are such
   that the SCHC Packet cannot be fragmented in (2 ^ M) * WINDOW_SIZE tiles or
   less. ". Does this mean that the SCHC packet cannot be fragmented?
   3. In section 5.6.2, the draft "draft-ietf-lpwan-schc-over-lorawan-04"
   indicates: "Retransmission and inactivity timers: LoRaWAN end-devices do
   not implement a" retransmission timer. "At the end of a window or a
   fragmentation session, corresponding ACK (s) is (are) transmitted by the
   network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot
   of end-device. the end of its RX windows, it sends an all-0 (or an all-1)
   fragment with no payload to request an SCHC ACK retransmission. and MAY be
   implements an "inactivity timer." The default RECOMMENDED duration of this
   timer is 12 hours. This value is mainly driven by application requirements
   and MAY be changed by the application. ". This indicates that the Receiver
   should send an ACK at the end of a window and if it does not, the
   transmitter will send a SCHC ACK retransmission. Is this operation not the
   same as ACK-Always (remember that we are in ACK-on-error mode)?

Thanks

--
*Rodrigo Muñoz Lara*

*Universidad de Chile*

---

From: <[email-masked]>
Date: Tue, 17 Dec 2019 08:38:50 +0000

Hello Rodrigo,

Thanks for your interest and for your questions, you're hitting totally relevant points.

As much as possible, please use  "draft-ietf-lpwan-ipv6-static-context-hc-24" as a reference for the generic SCHC draft.
If you have studied –22 in depth, you can quickly check for updates from –22 in the source code by looking at https://github.com/lp-wan/ip-compression/compare/draft-22...draft-24

Regarding the SCHC-over-LoRaWAN draft, as much as possible, please use the latest branch, which you can identify on https://github.com/Acklio/schc-over-lorawan/network
Currently, it's "05/comments", and you can read GitHub's rendition of the markdown source code at https://github.com/Acklio/schc-over-lorawan/blob/05/comments/draft-ietf-lpwan-schc-over-lorawan.md

Having said that, here are answers to two of your questions
>  1.The draft "draft-ietf-lpwan-ipv6-static-context-hc-22" indicates that in the profile of each technology the penultimate Tile size must be defined. On the other hand, in the draft "draft-ietf-lpwan-schc-over-lorawan-04" there is no definition in this regard. Can I consider that the penultimate tile size is the size of a regular tile?
[DB] Currently, https://github.com/Acklio/schc-over-lorawan/blob/05/comments/draft-ietf-lpwan-schc-over-lorawan.md says "Penultimate tile MUST be equal to the regular size."
I know this is being discussed between the authors of both drafts, at the time of this writing.
I guess we should have this discussion on the ML, so that you can take part to it.

> 2. In section 8.4.3.1, the draft "draft-ietf-lpwan-ipv6-static-context-hc-22", indicates that: "A Rule MUST NOT be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2 ^ M) * WINDOW_SIZE tiles or less.. ". Does this mean that the SCHC packet cannot be fragmented?
[DB] Indeed, if no fragmentation rule is found that has appropriate tile_size, M and WINDOW_SIZE values, the SCHC Packet cannot be fragmented, and therefore probably not sent. However, it probably means that an incorrect MTU was advertised.

> 3.
I'll leave this one to the SCHC-over-LoRaWAN authors.

Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Rodrigo Muñoz Lara <[email-masked]<mailto:[email-masked]>>
Date : Monday 16 December 2019 17:36
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sandra Cespedes <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Implementation of SCHC

Dear Author,

  1.  The draft "draft-ietf-lpwan-ipv6-static-context-hc-22" indicates that in the profile of each technology the penultimate Tile size must be defined. On the other hand, in the draft "draft-ietf-lpwan-schc-over-lorawan-04" there is no definition in this regard. Can I consider that the penultimate tile size is the size of a regular tile?
  2.  In section 8.4.3.1, the draft "draft-ietf-lpwan-ipv6-static-context-hc-22", indicates that: "A Rule MUST NOT be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2 ^ M) * WINDOW_SIZE tiles or less.. ". Does this mean that the SCHC packet cannot be fragmented?
  3.  In section 5.6.2, the draft "draft-ietf-lpwan-schc-over-lorawan-04" indicates: "Retransmission and inactivity timers: LoRaWAN end-devices do not implement a" retransmission timer. "At the end of a window or a fragmentation session, corresponding ACK (s) is (are) transmitted by the network gateway (LoRaWAN application server) in the RX1 or RX2 receive slot of end-device. the end of its RX windows, it sends an all-0 (or an all-1) fragment with no payload to request an SCHC ACK retransmission. and MAY be implements an "inactivity timer." The default RECOMMENDED duration of this timer is 12 hours. This value is mainly driven by application requirements and MAY be changed by the application. ". This indicates that the Receiver should send an ACK at the end of a window and if it does not, the transmitter will send a SCHC ACK retransmission. Is this operation not the same as ACK-Always (remember that we are in ACK-on-error mode)?

Thanks

--
Rodrigo Muñoz Lara
Universidad de Chile

_________________________________________________________________________________________________________________________

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: Olivier Gimenez <[email-masked]>
Date: Tue, 17 Dec 2019 08:49:47 +0000

Hi Rodrigo,

1.       The schc-over-lorawan-05 document will introduce “Penultimate tile must be equal to the regular size.”. I hope to publish it this week, until then you can find our working document here<https://github.com/Acklio/schc-over-lorawan/blob/draft-ietf-lpwan-schc-over-lorawan-05/draft-ietf-lpwan-schc-over-lorawan.md>

2.       Dominique answered while I was writing this email

3.       The profiles does specify that the device must wait for an ACK between each windows.  I think the idea of the author several month ago was to reduce memory required by the implementation, as the device only need to keep one window in RAM; but I am also wondering the relevance of it. Any thoughts ? In the mean time I will ask him

Best regards
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.

---

From: Rodrigo Muñoz Lara <[email-masked]>
Date: Tue, 17 Dec 2019 17:41:51 -0300

Thanks Olivier

My comments below

1.       The schc-over-lorawan-05 document will introduce “Penultimate tile
must be equal to the regular size.”. I hope to publish it this week, until
then you can find our working document here
<https://github.com/Acklio/schc-over-lorawan/blob/draft-ietf-lpwan-schc-over-lorawan-05/draft-ietf-lpwan-schc-over-lorawan.md>
 [Rodrigo] Thanks, I have considered it in my development

2.       Dominique answered while I was writing this email [Rodrigo] Thanks
again

3.       The profiles does specify that the device must wait for an ACK
between each windows.  I think the idea of the author several month ago was
to reduce memory required by the implementation, as the device only need to
keep one window in RAM; but I am also wondering the relevance of it. Any
thoughts ? In the mean time I will ask him [Rodrigo] I don't understand why
the authors call this mode ACK-On-Error if the behavior is similar to the
ACK-Always mode. In LoRaWAN you always have to wait for an ACK to finish a
window. This breaks the ACK-On-Error mode definition.

El mar., 17 dic. 2019 a las 5:49, Olivier Gimenez (<[email-masked]>)
escribió:

> Hi Rodrigo,
>
>
>
> 1.       The schc-over-lorawan-05 document will introduce “Penultimate
> tile must be equal to the regular size.”. I hope to publish it this week,
> until then you can find our working document here
> <https://github.com/Acklio/schc-over-lorawan/blob/draft-ietf-lpwan-schc-over-lorawan-05/draft-ietf-lpwan-schc-over-lorawan.md>
>
> 3.       The profiles does specify that the device must wait for an ACK
> between each windows.  I think the idea of the author several month ago was
> to reduce memory required by the implementation, as the device only need to
> keep one window in RAM; but I am also wondering the relevance of it. Any
> thoughts ? In the mean time I will ask him
>
>
>
> Best regards
>
> 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.
>

---

From: Rodrigo Muñoz Lara <[email-masked]>
Date: Tue, 17 Dec 2019 17:44:00 -0300

Hi Dominique

My answer below

El mar., 17 dic. 2019 a las 5:38, <[email-masked]> escribió:

> As much as possible, please use
>  "draft-ietf-lpwan-ipv6-static-context-hc-24" as a reference for the
> generic SCHC draft.
> If you have studied –22 in depth, you can quickly check for updates from
> –22 in the source code by looking at
> https://github.com/lp-wan/ip-compression/compare/draft-22...draft-24
>
> Regarding the SCHC-over-LoRaWAN draft, as much as possible, please use the
> latest branch, which you can identify on
> https://github.com/Acklio/schc-over-lorawan/network
> Currently, it's "05/comments", and you can read GitHub's rendition of the
> markdown source code at
> https://github.com/Acklio/schc-over-lorawan/blob/05/comments/draft-ietf-lpwan-schc-over-lorawan.md
>
> >  1.The draft "draft-ietf-lpwan-ipv6-static-context-hc-22" indicates that
> [DB] Currently,
> https://github.com/Acklio/schc-over-lorawan/blob/05/comments/draft-ietf-lpwan-schc-over-lorawan.md says
> "Penultimate tile MUST be equal to the regular size."
[Rodrigo] Thanks, I have considered it in my development. Can you make me
part of the discussion?

> less.. ". Does this mean that the SCHC packet cannot be fragmented?
> [DB] Indeed, if no fragmentation rule is found that has appropriate
> tile_size, M and WINDOW_SIZE values, the SCHC Packet cannot be fragmented,
> and therefore probably not sent. However, it probably means that an
> incorrect MTU was advertised.
>

> De : lp-wan <[email-masked]> on behalf of Rodrigo Muñoz Lara <
> [email-masked]>
> À : "[email-masked]" <[email-masked]>
> Cc : "[email-masked]" <[email-masked]>, Sandra Cespedes <
> [email-masked]>
>    1. The draft "draft-ietf-lpwan-ipv6-static-context-hc-22" indicates
>    that in the profile of each technology the penultimate Tile size must be
>    less.. ". Does this mean that the SCHC packet cannot be fragmented?
> *Universidad de Chile *

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 18 Dec 2019 08:02:37 +0100

Hi Rodrigo,

On Tue, Dec 17, 2019 at 9:43 PM Rodrigo Muñoz Lara <[email-masked]>
wrote:

> 2.       Dominique answered while I was writing this email [Rodrigo]
> Thanks again
>
> thoughts ? In the mean time I will ask him [Rodrigo] I don't understand
> why the authors call this mode ACK-On-Error if the behavior is similar to
> the ACK-Always mode. In LoRaWAN you always have to wait for an ACK to
> finish a window. This breaks the ACK-On-Error mode definition.
>

I don't know all the details of the  LoRa SCHC draft, but in SCHC Ack are
not synchronized with data and can be sent at any time. With LoRa two
behaviors are possible, one is to send all the fragments and wait for ack
only after the All-1 has been sent, the other is to wait for Ack after each
All-*, it does not mean that the sender will send something (ie if the
bitmap is full there is no ack) but it can be viewed as a rendez vous point
between the sender and the receiver.

Laurent

>> 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
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 18 Dec 2019 08:20:23 +0100

Hi,

> between the sender and the receiver.

I was going to write along similar terms.

In LoRaWAN (Class A) a sender device shall always listen after sending an
uplink frame anyway. However, the other side (i.e. the radio gateway) also
needs to be taken into account. In ACK-on-Error, except for the last
window, if a whole window is successfully delivered to the receiver, there
is no ACK in response. If ACKs are sent in the downlink, that means
alleviating downlink traffic, which might be a bottleneck in some cases.

Cheers,

Carles

---

From: Rodrigo Muñoz Lara <[email-masked]>
Date: Wed, 18 Dec 2019 08:54:41 -0300

Hi Carles

You say:

"...* In ACK-on-Error, except for the last window, if a whole window is
successfully delivered to the receiver, there is no ACK in response...*"

but in the draft say:

"*At the end of a window or a fragmentation session, corresponding ACK(s)
is (are) transmitted by the network gateway (LoRaWAN application server) in
the RX1 or RX2 receive slot of end-device.  If this ACK is not received by
the end-device at the end of its RX windows, it sends an all-0 (or an
all-1) fragment with no payload to request an SCHC ACK retransmission*."

This is where I have my confusion. Should the radio gateway always send an
ACK when a window ends?

Regards

---

From: Rodrigo Muñoz Lara <[email-masked]>
Date: Wed, 18 Dec 2019 08:57:51 -0300

Hi Laurent

You say:

"With LoRa two behaviors are possible, one is to send all the fragments and
wait for ack only after the All-1 has been sent, the other is to wait for
Ack after each All-*"

but the draft say:

Regards

El mié., 18 dic. 2019 a las 4:02, Laurent Toutain (<
[email-masked]>) escribió:

> Hi Rodrigo,
>
> On Tue, Dec 17, 2019 at 9:43 PM Rodrigo Muñoz Lara <
> [email-masked]> wrote:
>
>> Thanks Olivier
>>
>> My comments below
>>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 18 Dec 2019 16:39:00 +0100

Hi Rodrigo,

> This is where I have my confusion. Should the radio gateway always send an

I see your point.

Indeed, the text you highlight above sounds very much like ACK Always...

I will defer your question to the authors of the SCHC over LoRaWAN draft,
as they will be able to better motivate their text.

Cheers,

Carles

> Regards
>
> El miÃ©., 18 dic. 2019 a las 4:20, Carles Gomez Montenegro (<
> [email-masked]>) escribiÃ³:
>
>> Hi,
>>
>> >> between each windows.  I think the idea of the author several month
>> ago
>> >> was
>> >> to reduce memory required by the implementation, as the device only
>> need
>> >> to
>> >> why the authors call this mode ACK-On-Error if the behavior is
>> similar
>> >> to

---

From: Olivier Gimenez <[email-masked]>
Date: Thu, 19 Dec 2019 11:21:06 +0000

Hi,

This has been initially written to avoid having a device sending all its SCHC messages without a network, so the device would stop the transmission after the first window and not the last one, thus prevent battery draining for nothing. As it is a deviation from draft-ietf-lpwan-ipv6-static-context-hc protocol I changed it to a recommendation, please see this commit:
https://github.com/Acklio/schc-over-lorawan/commit/1d72e1384a608f4d449f91fca17ac0bbabdd8a16

Do you agree with it ?

Best regards
Olivier