Subject: Re: [lp-wan] SCHC - To pad or not to pad

From: <[email-masked]>
Date: Thu, 22 Jun 2017 07:11:23 +0000

Hi Juan Carlos,

Good point. I think your understanding is correct, and I see your point.
It seems to me that we don't have to mandate the padding behaviour in the generic SCHC document.
Each SCHC-over-foo derivation could make its own decision regarding padding or not and impose it on the implementors.
Or this could even be a flag in the SCHC compressor/decompressor state, leaving the decision to pad or not to the integrator.
Comments ?
Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Wednesday 21 June 2017 18:42
À : Laurent Toutain <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] SCHC - To pad or not to pad

Hi Laurent,

In the call you proposed padding in-between SCHC header and Payload Data. However, seems to me that this would limit the (already small) amount of bits available for Data.

For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving only 48 available bits for data instead of 53.

Is my understanding correct?

Best,

Juan Carlos

_________________________________________________________________________________________________________________________

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: Laurent Toutain <[email-masked]>
Date: Thu, 22 Jun 2017 10:48:35 +0200

Hi Juan Carlos

Yes this is good point.

In fact putting padding between header and data is not a so good idea if
the data are not themselves aligned on a byte boundary. For instance if the
header is 12 bit long and the data 4 bit long. If we introduce padding
between header and data the result will be 2 bytes. If we stick the data to
the header only one byte is needed.

The risk if the padding is added after the data is to include it into the
data (as Ethernet) and since the length is elided  by compression it can be
more tricky to solve the problem. In fact we can state that when the
payload is an IETF payload it is always bytes that are send, therefore it
is easy to solve the padding problem. When the payload is not IETF
compatible, then the payload must have a way to avoid confusion (strict
data format, length included,...)

My feeling is that LoRa is may be more byte oriented than Sigfox, but I
don't think it is necessary to complexify the standard and the
implementation by two different behaviors. I will propose to state on the
draft § 4.3

  ----

o  sending: The Rule ID is sent to the other end followed by
      information resulting from the compression of header fields
*, directly followed      by the payload.*  This *The result of field
compression is*
      information is sent in the order expressed in the Rule for the
      matching fields.  The way the Rule ID is sent depends on the
      specific LPWAN layer two technology and will be specified in a
      specific document, and is out of the scope of this document.  For
      example, it can be either included in a Layer 2 header or sent in
      the first byte of the L2 payload. (cf.  Figure 4).

 o  decompression: In both directions, The receiver identifies the
      sender through its device-id (e.g.  MAC address) and selects the
      appropriate Rule through the Rule ID.  This Rule gives the
      compressed header format and associates these values to header
      fields.  It applies the CDA action to reconstruct the original
      header fields.  The CDA application order can be different of the
      order given by the Rule.  For instance Compute-* may be applied at
      end, after the other CDAs.

*  Payload is always a multiple of 8 bits, so the last bit of a L2 payload*

*      must be ignored.  *

   +--- ... ---+-------------- ... --------------+*-------------+*--+
   |  Rule ID  |Compressed Hdr Fields information|  * payload   |//|*
   +--- ... ---+-------------- ... --------------+*-------------+--+*

On Thu, Jun 22, 2017 at 9:11 AM, <[email-masked]> wrote:

> Each SCHC-over-foo derivation could make its own decision regarding
> padding or not and impose it on the implementors.
> Or this could even be a flag in the SCHC compressor/decompressor state,
> leaving the decision to pad or not to the integrator.
> Comments ?
> Best regards
>
> Dominique
>
> De : lp-wan <[email-masked]> on behalf of Juan Carlos Zuniga <
> [email-masked]>
> À : Laurent Toutain <[email-masked]>
> Cc : lp-wan <[email-masked]>
> In the call you proposed padding in-between SCHC header and Payload Data.
> However, seems to me that this would limit the (already small) amount of
> bits available for Data.
>
>
>
> For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11
> bits would be padded up to 16, leaving only 48 available bits for data
> instead of 53.
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: Ana Minaburo <[email-masked]>
Date: Fri, 23 Jun 2017 11:13:30 +0200

Hello,

One question about your second modification in decompression

If we put that ‘payload is always a multiple of 8 bits’ we force the application to complete its payload to be multiple of 8 bits before compression, so after compression we have the same problem, isn’t it?

I suggest instead: IF after using SCHC compression and adding the payload to the L2 frame the datagram is not multiple of 8 bits, padding may be used.

What do you think?

Ana

> On 22 Jun 2017, at 10:48, Laurent Toutain <[email-masked]> wrote:
> 
> Hi Juan Carlos
> 
> Yes this is good point.
> 
> In fact putting padding between header and data is not a so good idea if the data are not themselves aligned on a byte boundary. For instance if the header is 12 bit long and the data 4 bit long. If we introduce padding between header and data the result will be 2 bytes. If we stick the data to the header only one byte is needed. 
> 
> The risk if the padding is added after the data is to include it into the data (as Ethernet) and since the length is elided  by compression it can be more tricky to solve the problem. In fact we can state that when the payload is an IETF payload it is always bytes that are send, therefore it is easy to solve the padding problem. When the payload is not IETF compatible, then the payload must have a way to avoid confusion (strict data format, length included,...)
> 
> My feeling is that LoRa is may be more byte oriented than Sigfox, but I don't think it is necessary to complexify the standard and the implementation by two different behaviors. I will propose to state on the draft § 4.3
> 
>   ----
>       information resulting from the compression of header fields, directly followed
>       by the payload.  This The result of field compression is
>       Payload is always a multiple of 8 bits, so the last bit of a L2 payload
>       must be ignored.  
> 
> 
> 
>    +--- ... ---+-------------- ... --------------+-------------+--+
>    |  Rule ID  |Compressed Hdr Fields information|   payload   |//|
>    +--- ... ---+-------------- ... --------------+-------------+--+
> 
> On Thu, Jun 22, 2017 at 9:11 AM, <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Juan Carlos,
> 
> De : lp-wan <[email-masked] <mailto:[email-masked]>> on behalf of Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>>
> À : Laurent Toutain <[email-masked] <mailto:[email-masked]>>
> Cc : lp-wan <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
>

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 23 Jun 2017 14:08:17 +0200

All the IETF protocol I know are aligned on byte boundary, it is not
possible to send a UDP payload with only 12 bits. Therefore we don't have
the problem. The case Juan Carlos raised is at the margin of what we are
doing but I think it is a good to take it into account, but not to
explicitly :-)

Laurent

On Fri, Jun 23, 2017 at 11:13 AM, Ana Minaburo <[email-masked]> wrote:

> If we put that ‘payload is always a multiple of 8 bits’ we force the
> application to complete its payload to be multiple of 8 bits before
> compression, so after compression we have the same problem, isn’t it?
>
> I suggest instead: IF after using SCHC compression and adding the payload
> to the L2 frame the datagram is not multiple of 8 bits, padding may be used.
>
> What do you think?
>
> Ana
>
>
>
> *, directly followed      by the payload.*  This *The result of field compression is*

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Fri, 23 Jun 2017 17:11:27 +0000

Hi Laurent, Ana,

From: Laurent Toutain [mailto:[email-masked]]
Sent: June 23, 2017 8:08 AM
To: Ana Minaburo <[email-masked]>
Cc: BARTHEL Dominique IMT/OLPS <[email-masked]>; lp-wan <[email-masked]>; Juan Carlos Zuniga <[email-masked]>
Subject: Re: [lp-wan] SCHC - To pad or not to pad

All the IETF protocol I know are aligned on byte boundary, it is not possible to send a UDP payload with only 12 bits.
[JCZ] You mean: “not yet” ;)
Therefore we don't have the problem. The case Juan Carlos raised is at the margin of what we are doing but I think it is a good to take it into account, but not to explicitly :-)
[JCZ] I agree. However, I think that the text Ana is proposing is a good compromise.
Best,
Juan Carlos
Laurent

On Fri, Jun 23, 2017 at 11:13 AM, Ana Minaburo <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

What do you think?

Ana

On 22 Jun 2017, at 10:48, Laurent Toutain <[email-masked]<mailto:[email-masked]>> wrote:

Hi Juan Carlos

Yes this is good point.

  ----

      must be ignored.

On Thu, Jun 22, 2017 at 9:11 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Juan Carlos,

Dominique

Hi Laurent,

Best,

Juan Carlos

Thank you.

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

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