Subject: Re: [lp-wan] Ticket 18: MSB/LSB argument

From: <[email-masked]>
Date: Tue, 15 May 2018 15:46:00 +0000

Hello all,

Regarding Ticket #18, I think we concluded at IETF101 that the y argument will disappear from the LSB CDA.
This is what I read from the meeting notes
> Laurent: currently we don't put the argument, we just put LSB. It's better to remove the argument. I.e. don't put "y" anymore. Just put LSB. In the CDA we just have LSB, and no argument.
> Dominique notes that this is what is already discribed at the bottom of the slide, under "if y is absent". Just make it the only one behaviour
Looking at version –11 of the draft, I still see LSB(y).
What is the status on this Ticket? Did I miss something?
Thanks

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Ana Minaburo <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 27 March 2018 17:38
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] Ticket 18: MSB/LSB argument

On Mon, Feb 26, 2018 at 9:40 PM, Ana Minaburo <[email-masked]<mailto:[email-masked]>> wrote:

<DB> Why MSB/LSB argument is used?If the TV can be of any type, such as structured data, why can't the MSB operator compare a number of bits of the TV equal to the TV length? After all, the MO compares the field value with all the TV values without needing the length of the list as a parameter

<SCHC authors> The MSB/LSB argument is very interesting for compression, if we always compare the complete TV with the Field value we will need a huge list of values in the Rule, if we have approximative values where only part of the field value needs to be sent because the MSB corresponds to the field value but the TV does not have the correct value, the Rule will be used and the compression of the field will be reduced by two or more, depending on the number of bits in the argument we want to compare.

Instead of naming the argument length, we have changed the name by MSB(x) bits and LSB (y) bits, so the X and Y are the numbers of bits that we need to compare.

----------
IETF 101

MSB and LSB are used for fixed and variable lengths field headers, in each case, the behavior is different based on the Field Description definition, the MO, and the TV defined in the Rule.

MSB/LSB arguments are used to choose the number of bits to be sent. 'x' and 'y' are a number of bits, 'y' is optional. If absent y=size(Field) - x So when I used this MO I'm sending y as a Residue in the fixed length fields.
But this MO where created for variable length fields as the CoAP URIs, the definition of MO/CDA for this kind of fields could be :

+---------------------+-------------------+
|            MO         |         CDA        |
+---------------------+-------------------+
|      Ignore           |   Value-Sent   |
+---------------------+-------------------+
|       MSB(x)        |       LSB(y)      |
+---------------------+-------------------+   In these both cases I need to send the length in bytes and the residue

But I can also define the MO and the CDA as follow:
+---------------------+-------------------+
| Match-mapping | Mapping Sent |
+---------------------+-------------------+, In this case, I have a list of possible values
                                                         so I do not send the length and I send the index of the list as residue.

Discussion

  *   Dominique: MSB and LSB, what does it mean, etc. MSB and LSB are not necessary to be used together, but it makes a lot of sense. The draft currently does not explain what happens in the corner cases - when x + y is more than the bytes available.

  *   Ana: It is possible "y" to be omitted if x and the length is known (it is fixed), than y could be the remaining bits.

  *   Dominique: What happens if "x" and "y" do not equal the field size. You just don't send them and those bits will be replaced on the other hand

  *   Dominique: does anybody have strong objections to this behavior?

  *   Pascal (from the floor): do you have a particular case why you use it? In some cases it might be good to be filled with 0s, but do you think there might be cases where this is not the case.

  *   Laurent: we are in a very strange case, I see no cases where you can apply this. If remaining bits are known, extend X size.

  *   Dominique: Do we simplify the draft by just saying y = len - x?

  *   Alexander Pelov (floor): it's good to be able to specify LSB. No strong opinion on this. It's good to have it as it is. Minimum changes to the draft.

  *   Ivaylo: wants to see written in the draft "fill with 0"

  *   Dominique: the way it's written is clear. We just always take it from the target value.

  *   Laurent: currently we don't put the argument, we just put LSB. It's better to remove the argument. I.e. don't put "y" anymore. Just put LSB. In the CDA we just have LSB, and no argument.

  *   Dominique notes that this is what is already discribed at the bottom of the slide, under "if y is absent". Just make it the only one behaviour

  *

  *   #18: Variable length fields

  *   Variable length fields were created in SCHC to accomodate CoAP URIs.

  *   CoAP has variable length field (URIs). Except for that, the protocols considered have fixed-length fields, known from the specification the protocol.

  *   1st typical use: MO: Ignored + CDA: Value-sent.  This situation is when we get some random URI in the CoAP message, that we have no way of anticipating. Since the URI string is of variable length, we have to send the field length along with the field value. Length is expressed in bytes (not bits), because URIs are byte-aligned. All other field lengths in SCHC are expressed in bits. This is disturbing when you read the spec. But saves 3 bits on the wire.

  *   How to encode the length? too many bits, you are wasting bits. Too few, you are constraining the field size. Idea: Use variable length (!). Like CBOR, but not CBOR. So the draft talks about the length and also about the length of the length. Trying to make the draft easier to read, more explicit. How to name the"length of the length" field in the draft?

  *   Laurent: Right now in the rule if the field is of variable length, you put "VAR" in the table. The units of the length is in bytes. If we later discover that we have a need for variable-length fields that are not byte-aligned, we can add a new keyword and have length in bits.

  *   Suresh: Why is this encoding different from that of CBOR ? Why does it have to be?

  *   Laurent: We want to encode as many small values as possible. Then we extend to the next size when we reach the limit..

_________________________________________________________________________________________________________________________

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: Ana Minaburo <[email-masked]>
Date: Wed, 16 May 2018 14:27:35 +0200

Hello,

No, I think is me that has lost something, I will do the modification and
send a new draft version

Ana

On Tue, May 15, 2018 at 5:46 PM, <[email-masked]> wrote:

> > Laurent: currently we don't put the argument, we just put LSB. It's
> better to remove the argument. I.e. don't put "y" anymore. Just put LSB. In
> the CDA we just have LSB, and no argument.
> > Dominique notes that this is what is already discribed at the bottom of
> the slide, under "if y is absent". Just make it the only one behaviour
> De : lp-wan <[email-masked]> on behalf of Ana Minaburo <
> [email-masked]>
> Répondre à : "[email-masked]" <[email-masked]>
> À : lp-wan <[email-masked]>
> Cc : "[email-masked]" <[email-masked]>
> On Mon, Feb 26, 2018 at 9:40 PM, Ana Minaburo <[email-masked]> wrote:
>
>> <DB> Why MSB/LSB argument is used?If the TV can be of any type, such as
>> structured data, why can't the MSB operator compare a number of bits of the
>> TV equal to the TV length? After all, the MO compares the field value with
>> all the TV values without needing the length of the list as a parameter
>>
>> <SCHC authors> The MSB/LSB argument is very interesting for compression,
>> if we always compare the complete TV with the Field value we will need a
>> huge list of values in the Rule, if we have approximative values where only
>> part of the field value needs to be sent because the MSB corresponds to the
>> field value but the TV does not have the correct value, the Rule will be
>> used and the compression of the field will be reduced by two or more,
>> depending on the number of bits in the argument we want to compare.
>>
>> Instead of naming the argument length, we have changed the name by MSB(x)
>> bits and LSB (y) bits, so the X and Y are the numbers of bits that we need
>> to compare.
>>
>> ----------
> IETF 101
>
> MSB and LSB are used for fixed and variable lengths field headers, in each
> case, the behavior is different based on the Field Description definition,
> the MO, and the TV defined in the Rule.
>
> MSB/LSB arguments are used to choose the number of bits to be sent. 'x'
> and 'y' are a number of bits, 'y' is optional. If absent y=size(Field) - x
> So when I used this MO I'm sending y as a Residue in the fixed length
> fields.
> But this MO where created for variable length fields as the CoAP URIs, the
> definition of MO/CDA for this kind of fields could be :
>
> +---------------------+-------------------+   In these both cases I need
> to send the length in bytes and the residue
>
>                                                          so I do not send
> the length and I send the index of the list as residue.
>
>
>
> Discussion
>
>    - Dominique: MSB and LSB, what does it mean, etc. MSB and LSB are not
>    necessary to be used together, but it makes a lot of sense. The draft
>    currently does not explain what happens in the corner cases - when x + y is
>    more than the bytes available.
>
>
>    - Ana: It is possible "y" to be omitted if x and the length is known
>    (it is fixed), than y could be the remaining bits.
>
>
>    - Dominique: What happens if "x" and "y" do not equal the field size.
>    You just don't send them and those bits will be replaced on the other hand
>
>
>    - Dominique: does anybody have strong objections to this behavior?
>
>
>    - Pascal (from the floor): do you have a particular case why you use
>    it? In some cases it might be good to be filled with 0s, but do you
>    think there might be cases where this is not the case.
>
>
>    - Laurent: we are in a very strange case, I see no cases where you can
>    apply this. If remaining bits are known, extend X size.
>
>
>    - Dominique: Do we simplify the draft by just saying y = len - x?
>
>
>    - Alexander Pelov (floor): it's good to be able to specify LSB. No
>    strong opinion on this. It's good to have it as it is. Minimum changes to
>    the draft.
>
>
>    - Ivaylo: wants to see written in the draft "fill with 0"
>
>
>    - Dominique: the way it's written is clear. We just always take it
>    from the target value.
>
>
>    - Laurent: currently we don't put the argument, we just put LSB. It's
>    better to remove the argument. I.e. don't put "y" anymore. Just put LSB. In
>    the CDA we just have LSB, and no argument.
>
>
>    - Dominique notes that this is what is already discribed at the bottom
>    of the slide, under "if y is absent". Just make it the only one
>    behaviour
>
>
>    -
>
>
>    - #18: Variable length fields
>
>
>    - Variable length fields were created in SCHC to accomodate CoAP URIs.
>
>
>    - CoAP has variable length field (URIs). Except for that, the
>    protocols considered have fixed-length fields, known from the specification
>    the protocol.
>
>
>    - 1st typical use: MO: Ignored + CDA: Value-sent.  This situation is
>    when we get some random URI in the CoAP message, that we have no way of
>    anticipating. Since the URI string is of variable length, we have to
>    send the field length along with the field value. Length is expressed
>    in bytes (not bits), because URIs are byte-aligned. All other field
>    lengths in SCHC are expressed in bits. This is disturbing when you
>    read the spec. But saves 3 bits on the wire.
>
>
>    - How to encode the length? too many bits, you are wasting bits. Too
>    few, you are constraining the field size. Idea: Use variable length
>    (!). Like CBOR, but not CBOR. So the draft talks about the length and
>    also about the length of the length. Trying to make the draft easier to
>    read, more explicit. How to name the"length of the length" field in
>    the draft?
>
>
>    - Laurent: Right now in the rule if the field is of variable length,
>    you put "VAR" in the table. The units of the length is in bytes. If we
>    later discover that we have a need for variable-length fields that are not
>    byte-aligned, we can add a new keyword and have length in bits.
>
>
>    - Suresh: Why is this encoding different from that of CBOR ? Why does it
>    have to be?
>
>
>    - Laurent: We want to encode as many small values as possible. Then we
>    extend to the next size when we reach the limit..
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>