Re: [lp-wan] ACK compression

[<[e-mail]>]

By " and it costs a bit more to compress out 0's." , I meant " and it costs somewhat more to compress out 0's.", not literally one bit.

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Date : Tuesday 20 August 2019 14:29
À : Olivier Gimenez <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc : Pascal Thubert <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] ACK compression

Hello Olivier,

Thanks for reviving this thread, and thanks for proposing a contribution.
I agree with Pascal, your algorithm needs further improvement.
For example, if I use your proposed algorithm to compress the following two bitmaps, they both result in the same compressed bitmap. How is the receiver going to decide which one was the orignal one?
Pascal's proposed step 3.5 is one way of solving this issue. However, it adds one bit to the  compressed bitmap (before padding). Maybe this is not a big deal. Another way is to create an exception in the encoding, so that is does not cost more than the current algorithm to compress out 1's, and it costs a bit more to compress out 0's.
Also, beware of the SCHC Receiver -Abort which is already an exception in the SCHC ACK encoding. Whatever you propose must be distinguishable from a SCHC Receiver-Abort, or the SCHC Receiver-Abort must be changed as well.
Best regards

Dominique




   |---- SCHC ACK Header ----|--------      Bitmap     --------|

             |-- T --|-M-| 1 |

   +--- ... -+- ... -+---+---+---------------------------------+

   | Rule ID |  DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|

   +--- ... -+- ... -+---+---+---------------------------------+

           next L2 Word boundary ->|




   |---- SCHC ACK Header ----|--------      Bitmap     --------|

             |-- T --|-M-| 1 |

   +--- ... -+- ... -+---+---+---------------------------------+

   | Rule ID |  DTag | W |C=0|1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0|

   +--- ... -+- ... -+---+---+---------------------------------+

           next L2 Word boundary ->|


Both result in the same compressed bitmap:


   |---- SCHC ACK Header ----|CpBmp|

             |-- T --|-M-| 1 |

   +--- ... -+- ... -+---+---+-----+

   | Rule ID |  DTag | W |C=0|1 0 1|

   +--- ... -+- ... -+---+---+-----+

           next L2 Word boundary ->|




De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Pascal Thubert <[e-mail]<mailto:[e-mail]>>
Date : Monday 19 August 2019 11:35
À : Olivier Gimenez <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] ACK compression

Maybe that’s me, Olivier.

Say you receive  1 0 1 0 1 0 1 0 and there are 5 elided bits. Is the original  1 0 1 0 1 0 1 0 - 1 1 1 1 1  or  1 0 1 0 1 0 1 0 - 0 0 0 0 0 ?

I inferred that the proposed algo to uncompress is (quit simply) to fill the missing bitmap with the last bits in the compressed form, which is OK if you re-added some of the removed bits in the second loop or in my step 3.5.

I guess you were smarter than that, I need to see the full decompression algorithm.

All the best,

Pascal

From: Olivier Gimenez <[e-mail]<mailto:[e-mail]>>
Sent: lundi 19 août 2019 10:49
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: ACK compression


From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
All I can say is that in order to work, you need the last bit of the compressed form to be the same as the elided bits.
So your “While the scissors are not on an L2 Word” in step 4 will not give the appropriate result if the scissor is already on the word boundary. In that case you need to go to the next boundary.
I suggest a step 3.5 which is to move the scissors right after the first while series.

Hi,

I do not understand why it does not work; in the following SCHC ACK example the Bitmap is on 10 bits, L2 words are 8 bits
|  3   bits |   1 bit | 1 bit | 1 bit |      10 bits             |
| Rule ID |  DTag |   W   |C=0   |1 1 0 0 0 0 0 0 0 0|

Compressed SCHC ACK would be
|  3   bits |   1 bit | 1 bit | 1 bit | 2 bits |
| Rule ID |  DTag |   W   |C=0   |1 1       |

This SCHC ACK is aligned to L2 word. The scissor has been put on the word boundary and I do not understand why it does not work: the sender is able to know that last 8 tiles are missing as it knows that the 2 first are OK and it send 10 tiles.

Sorry for the mistake on examples, here is the correction with 17 tiles in the bitmap


   Figure 20 shows an example where L2 Words are actually bytes and where the original Bitmap contains 17 bits, the last 6 of which are all set to 0 due to missing tiles.

   |---- SCHC ACK Header ----|--------      Bitmap     --------|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+---------------------------------+
   | Rule ID |  DTag | W |C=0|1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0|
   +--- ... -+- ... -+---+---+---------------------------------+
           next L2 Word boundary ->|

            Figure 20: SCHC ACK Header plus uncompressed Bitmap – Trailing 0 compression

   Figure 21 shows that the last 6 bits are not sent.

   |---- SCHC ACK Header ----|CpBmp|
             |-- T --|-M-| 1 |
   +--- ... -+- ... -+---+---+-----+
   | Rule ID |  DTag | W |C=0|1 1 1 1 1 1 1 1 1 1 1 |
   +--- ... -+- ... -+---+---+-----+
           next L2 Word boundary ->|

       Figure 21: Resulting SCHC ACK message with Compressed Bitmap – Trailing 0 compression

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<http://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.


_________________________________________________________________________________________________________________________

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.