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

From: ana minaburo <[email-masked]>
Date: Tue, 22 May 2018 14:53:43 +0200

Hello,

I've closed this ticket, I've made modifications, I will publish a new
version of the draft after, see details

https://trac.ietf.org/trac/lpwan/ticket/18

Ana

On Wed, May 16, 2018 at 2:27 PM, Ana Minaburo <[email-masked]> wrote:

> 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:
>
>> 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]> on behalf of Ana Minaburo <
>> [email-masked]>
>> Répondre à : "[email-masked]" <[email-masked]>
>> Date : Tuesday 27 March 2018 17:38
>> À : lp-wan <[email-masked]>
>> Cc : "[email-masked]" <[email-masked]>
>> Objet : Re: [lp-wan] Ticket 18: MSB/LSB argument
>>
>>
>>
>> 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..
>>
>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>