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

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 17:38:34 +0200

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 :

+---------------------+-------------------+
|            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.