Subject: [lp-wan] SCHC over LoRaWAN review

From: Laurent Toutain <[email-masked]>
Date: Wed, 5 Jun 2019 17:26:28 +0200

Dear Author,

As discussed during the interim, you will find some comments on the schc
over LoRAWAN draft. I like the approach, but I have some questions about
the way it is done.

- the draft should be more precise on the relation between FPort and
RuleID. The first time I read the draft I thought that the FPort was the
ruleID. What I understand after, tell me if it is true, the 3 FPort defined
in the document are telling that the LoRaWAN PDU is a SCHC message.
- the relation between compression and fragmentation is not clear. The
introduction describes a lot the compression and the rest of the document
gives only rules for fragmentation.
if I understand well FPort 20 is for an implicit fragmentation rule and
port 21 for any SCHC message starting with a ruleID. Why the document
limits it to fragmentation?

- I don't understand either the reason to have 3 byte long tiles, why a so
small value? Why for instance 6 cannot be used ?

The rest of the comments are in the world file with comments (sorry for
that, if it causes trouble I will translate it into ascii).

Laurent

---

From: <[email-masked]>
Date: Wed, 5 Jun 2019 15:56:39 +0000

Hello Laurent,

Having discussed it with the authors, I feel I can answer some of your questions.
The concatanation of the Fport byte and the few bits following constitute the Rule ID. The number of "few bits" is variable based on the first (Fport) byte, therefore we have a variable-length RuleID.
In order to be more in the spirit of the generic SCHC description draft, I suggest that the RuleID be described in the schc-over-LoRaWAN draft the following way

  *   The Rule ID is  of variable length
  *   The RuleID field spans the Fport byte and a few following bits of the LoRaWAN frame
  *   Only some values of the RuleID's most significant byte (=Fport) are allowed, namely  ...
  *   For each of these values, the RuleID is … bits long, the Rule is fragmentation or compression, etc …

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 5 June 2019 17:26
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] SCHC over LoRaWAN review

Dear Author,

As discussed during the interim, you will find some comments on the schc over LoRAWAN draft. I like the approach, but I have some questions about the way it is done.

- the draft should be more precise on the relation between FPort and RuleID. The first time I read the draft I thought that the FPort was the ruleID. What I understand after, tell me if it is true, the 3 FPort defined in the document are telling that the LoRaWAN PDU is a SCHC message.
- the relation between compression and fragmentation is not clear. The introduction describes a lot the compression and the rest of the document gives only rules for fragmentation.
if I understand well FPort 20 is for an implicit fragmentation rule and port 21 for any SCHC message starting with a ruleID. Why the document limits it to fragmentation?

- I don't understand either the reason to have 3 byte long tiles, why a so small value? Why for instance 6 cannot be used ?

The rest of the comments are in the world file with comments (sorry for that, if it causes trouble I will translate it into ascii).

Laurent

_________________________________________________________________________________________________________________________

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: ivaylo petrov <[email-masked]>
Date: Thu, 6 Jun 2019 10:16:41 +0200

Hello Laurent and Dominique,

Thank you for your comments! I think we can add or edit some text to make
those points clearer. My comments regarding your questions.

- On your point about *relation between FPort and RuleID*, I think that
Dominique's proposition could indeed make this part clearer.

- On your point about *relation between compression and fragmentation, *we
can add a bit more text about it, but our general idea was that compression
depends much more on the specific scenario, so we are only providing the
required parameters for it and we leave it to the <<*user>> * to figure out
the remaining details. This is why this part is much shorter and probably
less detailed. The fragmentation is the part that seemed the most likely
source of interoperability issues and that is why most of our efforts so
far have been concentrated on it.

- While tile size of 6 could be used, the idea to have it only 3 bytes long
is that mac commands in FOpts can be placed, without affecting too much the
fragmentation. In addition, different payload sizes seem to fit well with
this tile size. My guess is that only through observing real traffic we
will be able to select the best tile size for most cases. If you have
reasons to believe that other tile size will be more appropriate, please
let us know.

Best regards,

<https://ackl.io/>
*Ivaylo Petrov*

Chief Architect

+33 2 22 06 05 77

www.ackl.io

 <https://www.linkedin.com/company/acklio/> [image:
W3Schools] <https://twitter.com/acklio>

The content of this email is confidential and intended for the recipient
specified in message only.

It is strictly forbidden to share any part of this message with any third
party, without the written consent of the sender.

If you received this message by mistake, please reply to this message and
follow with its deletion, so that we can ensure

On Wed, Jun 5, 2019 at 5:56 PM <[email-masked]> wrote:

> The concatanation of the Fport byte and the few bits following constitute
> the Rule ID. The number of "few bits" is variable based on the first
> (Fport) byte, therefore we have a variable-length RuleID.
> In order to be more in the spirit of the generic SCHC description draft, I
> suggest that the RuleID be described in the schc-over-LoRaWAN draft the
> following way
>
>    - The Rule ID is  of variable length
>    - The RuleID field spans the Fport byte and a few following bits of
>    the LoRaWAN frame
>    - Only some values of the RuleID's most significant byte (=Fport) are
>    allowed, namely  ...
>    - For each of these values, the RuleID is … bits long, the Rule is
>    fragmentation or compression, etc …
>
>
> Dominique
>
> De : lp-wan <[email-masked]> on behalf of Laurent Toutain <
> [email-masked]>
> À : lp-wan <[email-masked]>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 6 Jun 2019 12:00:24 +0200

Hi Ivo,

> Dominique's proposition could indeed make this part clearer.

Something like

FPort:RuleID ?

20: for the small one
21:RuleID for uplink
and
22:RuleID for downlink

> required parameters for it and we leave it to the <<*user>> * to figure
> out the remaining details. This is why this part is much shorter and
> probably less detailed. The fragmentation is the part that seemed the most
> likely source of interoperability issues and that is why most of our
> efforts so far have been concentrated on it.
>
> ok

> No I was surprised by the value, but it is a good trade-off

Laurent

>> In order to be more in the spirit of the generic SCHC description draft,
>> I suggest that the RuleID be described in the schc-over-LoRaWAN draft the
>> following way
>>
>> - I don't understand either the reason to have 3 byte long tiles, why a
>> so small value? Why for instance 6 cannot be used ?
>>

---

From: <[email-masked]>
Date: Thu, 6 Jun 2019 13:38:05 +0000

Hello all,

Discussing it with Laurent yesterday night, we were wondering if it makes sense to specify in this document the number of Rules allowed for compression.
Application of SCHC to LoRaWN (or to any Layer 2) is mostly a fragmentation issue.
Compression is mostly about applying SCHC to upper-layer protocols, which is outside the scope of this document.
Therefore, why not reserve in this document the upper part of the compression Rule Ids and leave it open to the "upper-layer-over-SCHC" document to specify how many Rules are needed for compression?
Best regards

Dominique

De : ivaylo petrov <[email-masked]<mailto:[email-masked]>>
Date : Thursday 6 June 2019 10:16
À : Laurent Toutain <[email-masked]<mailto:[email-masked]>>, Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] SCHC over LoRaWAN review

Thank you for your comments! I think we can add or edit some text to make those points clearer. My comments regarding your questions.

- On your point about relation between FPort and RuleID, I think that Dominique's proposition could indeed make this part clearer.

- On your point about relation between compression and fragmentation, we can add a bit more text about it, but our general idea was that compression depends much more on the specific scenario, so we are only providing the required parameters for it and we leave it to the <<user>>  to figure out the remaining details. This is why this part is much shorter and probably less detailed. The fragmentation is the part that seemed the most likely source of interoperability issues and that is why most of our efforts so far have been concentrated on it.

- While tile size of 6 could be used, the idea to have it only 3 bytes long is that mac commands in FOpts can be placed, without affecting too much the fragmentation. In addition, different payload sizes seem to fit well with this tile size. My guess is that only through observing real traffic we will be able to select the best tile size for most cases. If you have reasons to believe that other tile size will be more appropriate, please let us know.

Best regards,

[https://uploads-ssl.webflow.com/5c4b130029e0ba2325776fc5/5cc98928d54687230176b9ae_Acklio_minilogo.jpg]<https://ackl.io/>
Ivaylo Petrov

Chief Architect

+33 2 22 06 05 77

www.ackl.io<http://www.ackl.io/>

[W3Schools]<https://www.linkedin.com/company/acklio/> [W3Schools] <https://twitter.com/acklio>

The content of this email is confidential and intended for the recipient specified in message only.

It is strictly forbidden to share any part of this message with any third party, without the written consent of the sender.

If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure

On Wed, Jun 5, 2019 at 5:56 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hello Laurent,

Dominique

Dear Author,

Laurent

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 14 Jun 2019 13:28:28 +0000

Thank you Laurent for your review.

Something like
FPort:RuleID ?
20: for the small one
21:RuleID for uplink
and
22:RuleID for downlink

No. 22:RuleID for all downlink is OK but not 20 and 21.
21:RuleID works for all uplinks, fragmented or not, add 2 bytes of overhead.
22: RuledID for fragmented uplinks where payload is less than 381 bytes, add 1 byte of overhead. I should add a comment that this one is not mandatory on device side, as using FPort 21 for a fragmented payload of 200 bytes will also work. It is only purpose is reduce the overhead for small fragmented payloads.

ok

It is the best one to have an efficient packing of tiles in all LoRaWAN MTU, taking into account that there can be FOpts. Using 2 would be even better but we would not comply with IPv6 MTU of 1280 bytes.

Regarding comments about compression not described: what should be described ? The rules are user specific, and user can use 62 rules. What else should we write in the document ?

I will think about not specifying ruleId in the document, and if it is not too difficult to implement.

Please find attached the Word document with answers to your comments.

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: Laurent Toutain <[email-masked]>
Date: Thu, 20 Jun 2019 16:24:02 +0200

Hi Olivier,

Thank you for your answers, and the explanation for a Tile of 3 Bytes,
that's a good way to fill the frame.
I still have questions on fPorts:

- rule 20 is fully specified by the draft and that's logicial, and is
designed for short uplinks, that's perfect.

for the other rules
- rule 21 is for any SCHC rule uplink
- rule 22 is for any SCHC rule downlink,

For these rules are less directive, I suppose an implementer may decide to
use then as he wants, even if he does not follow the draft representation.

In SCHC a compression rule is bidirectional you can with the same rule ID
use it differently up and downlink. How do you plan to map it in the
LoRaWAN case?
same rule ID but the fport is changing regarding it has been sent by the
device or the network?

In SCHC the fragmentation rules are in one direction, the other direction
is used for ack with the same ruleID.
how do you map it ? do you use the same fPort for the ack ? For instance if
I send the combination fPort:RuleID
21:1000 for a fragment, the ack will be 21:1000 or 22:1000 (personally I
prefer to use 21: for the Ack).

See you

Laurent

On Fri, Jun 14, 2019 at 3:28 PM Olivier Gimenez <[email-masked]>
wrote:

> No. *22:RuleID for all downlink* is OK but not 20 and 21.
>
> *21:RuleID works for all uplinks*, fragmented or not, add 2 bytes of
> overhead.
>
> *22: RuledID for fragmented uplinks* where payload is less than 381
> bytes, add 1 byte of overhead. I should add a comment that this one is not
> mandatory on device side, as using FPort 21 for a fragmented payload of 200
> bytes will also work. It is only purpose is reduce the overhead for small
> fragmented payloads.
>
>
>
>
>
>
>
>
>
> - While tile size of 6 could be used, the idea to have it only 3 bytes
> long is that mac commands in FOpts can be placed, without affecting too
> much the fragmentation. In addition, different payload sizes seem to fit
> well with this tile size. My guess is that only through observing real
> traffic we will be able to select the best tile size for most cases. If you
> have reasons to believe that other tile size will be more appropriate,
> please let us know.
>
>
>
> It is the best one to have an efficient packing of tiles in all LoRaWAN
> MTU, taking into account that there can be FOpts. Using 2 would be even
> better but we would not comply with IPv6 MTU of 1280 bytes.
>
>
>
>
>
> Regarding comments about compression not described: what should be
> described ? The rules are user specific, and user can use 62 rules. What
> else should we write in the document ?
>
>
>
>
>
> 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: Olivier Gimenez <[email-masked]>
Date: Fri, 21 Jun 2019 16:11:34 +0000

From: Laurent Toutain <[email-masked]>
For these rules are less directive, I suppose an implementer may decide to use then as he wants, even if he does not follow the draft representation.

FPorts are recommended values only as the implementer might already user them in his application, or have several SCHC sessions with several SCHC gateways.

In SCHC a compression rule is bidirectional you can with the same rule ID use it differently up and downlink. How do you plan to map it in the LoRaWAN case?
same rule ID but the fport is changing regarding it has been sent by the device or the network?

Yes

In SCHC the fragmentation rules are in one direction, the other direction is used for ack with the same ruleID.
how do you map it ? do you use the same fPort for the ack ? For instance if I send the combination fPort:RuleID
21:1000 for a fragment, the ack will be 21:1000 or 22:1000 (personally I prefer to use 21: for the Ack).

We use 21 for the fragment and the ACK, it is explained in “§5.1. LoRaWAN FPort”, but I see that I did not push a modification making it easier to understand:

A fragmentation session with application payload transferred from device to server, is called uplink fragmentation session. It uses FPortUpShort or FPortUpDefault for data uplink and its associated SCHC control downlinks.
The other way, a fragmentation session with application payload transferred from server to device, is called downlink fragmentation session. It uses FPortDown for data downlink and its associated SCHC control uplinks.
[…]
The only uplink messages using the FPortDown port are the fragmentation SCHC control messages of a downlink fragmentation session (ex ACKs). Similarly, the only downlink messages using the FPortUpShort or FPortUpDefaultports are the fragmentation SCHC control messages of an uplink fragmentation session.

Best regards
Olivier