Subject: [lp-wan] Field Length in schc

From: Arun <[email-masked]>
Date: Sun, 3 Sep 2017 22:00:03 +0200

Hello All, 

We need a column/field in the context to represent the length of the field.
For the fixed length field the actual length in bits shall be used and
'0' shall be used to indicate variable length fields with the length
being sent on wire.

Ref:
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05,
Section:6

"The receiver must be able to find the size of each compressed field which can be given by the
   rule or may be sent with the compressed header

thanks,

-- 
Arunprabhu Kandasamy
arun at ackl.io

2 bis rue de la Châtaigneraie
35510 Cesson-Sévigné 
France 
Phone: +33 (0)2.99.12.24.14

---

From: Arun <[email-masked]>
Date: Tue, 12 Sep 2017 18:09:09 +0200

Hello All,
 Sending again to restart the discussion in the ML after today's interim
meeting.

somethings which arose during the call:

 -  We need some sensible way to represent the variable length. 0
doesn't seem good as Pascal pointed out that there can be fields of 0
length.
 -  Do we need  to define the type for the length , so that we can
represent it in json or some other format.  
 -  As type int and -1 value could be also used, as suggested by Alex.

any thoughts?

thanks,

On 03/09/2017 22:00, Arun wrote:
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

-- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: Abdul Saboor Malik <[email-masked]>
Date: Tue, 12 Sep 2017 17:45:02 +0000 (UTC)

Hi everyone,
Today was my first meeting at any IETF workgroup. It was good experience to actually see live work and discussion on a new standards. 
I would like to continue with this group and to be part of ongoing work, which I believe would be helpful for me to understand in-depth about work which would become a standard one day.
To get my self more familiar with all the history of the work under discussion, its scope(different inter relatd WG team) and domain in a bigger picture , Can I get some mentor ship that would assist me in my learning path so that I can catch up with latest proceedings happening and understand its future impact.  Regards,Abdul Saboor Malik 

    On Tuesday, September 12, 2017 9:09 PM, Arun <[email-masked]> wrote:

   Hello All, 
  Sending again to restart the discussion in the ML after today's interim meeting. 
  somethings which arose during the call:
   -  We need some sensible way to represent the variable length. 0 doesn't seem good as Pascal pointed out that there can be fields of 0 length. 
  -  Do we need  to define the type for the length , so that we can represent it in json or some other format.   
  -  As type int and -1 value could be also used, as suggested by Alex. any thoughts?
  
  thanks,

 Hello All,  We need a column/field in the context to represent the length of the field. 
 For the fixed length field the actual length in bits shall be used and '0' shall be used to indicate variable length fields with the length being sent on wire.
 
  Ref: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05, Section:6 
  "The receiver must be able to find the size of each compressed field which can be given by the
   rule or may be sent with the compressed header

thanks,
 -- 
Arunprabhu Kandasamy
arun at ackl.io

 -- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 13 Sep 2017 10:38:01 +0200

Hi,

thanks Arun,

That's a good idea to  add an entry in the rule for length, especially for
CoAP compression.

In my views the description of the entry can be:

*The Field Length entry contains either the size in bit of the field or a
keyword indicating the way the length is defined:*

*- variable: indicates that the field length is variable and is coded as
described in section 2.5*

*- static : indicates that the compressor and the decompressor learn the
length by another means.*
The static is useful for the Token field. The size is variable, but there
is no need to send it since the Token Length field indicates this length.

Laurent

On Tue, Sep 12, 2017 at 6:09 PM, Arun <[email-masked]> wrote:

>  -  We need some sensible way to represent the variable length. 0 doesn't
> seem good as Pascal pointed out that there can be fields of 0 length.
> For the fixed length field the actual length in bits shall be used and '0'
> shall be used to indicate variable length fields with the length being sent
> on wire.
>
> Phone: +33 (0)2.99.12.24.14 <02%2099%2012%2024%2014>
>
>
>
> lp-wan mailing [email-masked]://www.ietf.org/mailman/listinfo/lp-wan
>
>
> --
> Arunprabhu Kandasamy
> arun at ackl.io
>
> Phone: +33 (0)2.99.12.24.14 <02%2099%2012%2024%2014>
>
>

---

From: Ana Minaburo <[email-masked]>
Date: Fri, 15 Sep 2017 10:22:58 +0200

Hello LPWANers,

I understand why you need the length column, but I’m not sure that adding a column is the best way to solve this problem. Correct me if I’m wrong you need the length in order to get the size of the variable fields of the CoAP header as path, but this length is used only for this variable fields the rest of the header fields are known, with the idea of creating a column with the length values you will repeat this known values as much times as rules you have and it will use memory. 

I propose the following: if we need to have the length of this variable fields, we create a Matching Operator that gives this information, for example MO called check-length(x) so when you need to read your field you know that you need to read x bits.

rule id 1
+-------------------+------+-------+----------------+-----------------------+----------------+
|         Field        | dir   | TV    |MO               |CDF                     |  Sent           |
+===========+===+====+=========+=============+==========+
|CoAP version  | bi     |    01  |    equal         | not-sent              |                   |
|CoAP Type      | bi    |          |   ignore         | value-sent           |TT              |
|CoAP TKL       | bi    |  0       |   equal          | not-sent              |                    |
|CoAP Code     | bi    | ML1  | match-map   | matching-sent      | CC CCC    |
|CoAP MID       | bi    |  0000  |  MSB(7 )      | LSB(9)                |        M-ID   |
|CoAP Uri-Path | dn  |           | check_length(24)  | value-sent |      XXX        |
+-------------------+-----+--------+-----------------+-----------------------+----------------+

Ana

Ana Minaburo

Research Division

ana at ackl.io

www.acklio.com

> On 13 Sep 2017, at 10:38, Laurent Toutain <[email-masked]> wrote:
> 
> Hi,
> 
> thanks Arun, 
> 
> That's a good idea to  add an entry in the rule for length, especially for CoAP compression. 
> 
> The Field Length entry contains either the size in bit of the field or a keyword indicating the way the length is defined:
> - variable: indicates that the field length is variable and is coded as described in section 2.5
> - static : indicates that the compressor and the decompressor learn the length by another means.
> 
> The static is useful for the Token field. The size is variable, but there is no need to send it since the Token Length field indicates this length.
> 
> Laurent
> 
> On Tue, Sep 12, 2017 at 6:09 PM, Arun <[email-masked] <mailto:[email-masked]>> wrote:
> Hello All, 
>> Ref: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05>, Section:6 
>> arun at ackl.io <http://ackl.io/>
>> 
>> Phone: +33 (0)2.99.12.24.14 <tel:02%2099%2012%2024%2014>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
> -- 
> Arunprabhu Kandasamy
> arun at ackl.io <http://ackl.io/>
> 
> Phone: +33 (0)2.99.12.24.14 <tel:02%2099%2012%2024%2014>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
>

---

From: Arun <[email-masked]>
Date: Mon, 25 Sep 2017 09:55:45 +0200

Hi Ana,
 It becomes trickier when we use LSB without argument. In that case,
check_length overloads the MSB MO with additional argument specifying
the msb bits?

thanks,
arun

On 15/09/2017 10:22, Ana Minaburo wrote:
> Hello LPWANers,
>
> I understand why you need the length column, but I’m not sure that
> adding a column is the best way to solve this problem. Correct me if
> I’m wrong you need the length in order to get the size of the variable
> fields of the CoAP header as path, but this length is used only for
> this variable fields the rest of the header fields are known, with the
> idea of creating a column with the length values you will repeat this
> known values as much times as rules you have and it will use memory. 
>
> I propose the following: if we need to have the length of this
> variable fields, we create a Matching Operator that gives this
> information, for example MO called check-length(x) so when you need to
> read your field you know that you need to read x bits.
>
> rule id 1
> ana at ackl.io <http://ackl.io>
>
> www.acklio.com <http://www.acklio.com>
>
>
>> On 13 Sep 2017, at 10:38, Laurent Toutain
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> thanks Arun,
>>
>> /The Field Length entry contains either the size in bit of the field
>> or a keyword indicating the way the length is defined:
>> /
>> /- variable: indicates that the field length is variable and is coded
>> as described in section 2.5
>> /
>> /- static : indicates that the compressor and the decompressor learn
>> the length by another means.
>> /
>> The static is useful for the Token field. The size is variable, but
>> there is no need to send it since the Token Length field indicates
>> this length.
>>
>> Laurent
>>
>>     doesn't seem good as Pascal pointed out that there can be fields
>>     of 0 length.
>>      -  Do we need  to define the type for the length , so that we
>>     can represent it in json or some other format.  
>>>     For the fixed length field the actual length in bits shall be
>>>     used and '0' shall be used to indicate variable length fields
>>>     with the length being sent on wire.
>>>
>>>     Ref:
>>>     https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05
>>>     <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05>,
>>>     Section:6
>>>
>>>     <https://www.ietf.org/mailman/listinfo/lp-wan>
>>
>>     -- 
>>     Arunprabhu Kandasamy
>>     <https://www.ietf.org/mailman/listinfo/lp-wan>
>>
>>

-- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: Arun <[email-masked]>
Date: Tue, 26 Sep 2017 21:00:40 +0200

Hello all,
following are some proposals which you can vote to choose one, or can
propose a better one :)

"Proposal 1:
add a length column:
    - actual length to represent static fields.
    -  -1 to represent variable length fields."

"Proposal 2:
add a length column:
      - ""variable"" to represent variable length fields
      - ""static"" to represent static fields, length here is obtained
with the help from parser."

"Proposal 3:
 no extra column:
      - use check_len(x) as MO, where x is the length of the variable field
      - static fields, length here is obtained with the help from parser.
      - there is a limitation to use LSB with MSB as MO for variable
length field since we don't know the msb_val."

"Proposal 4:
 no extra column:
     - static fields, length here is obtained with the help from parser.
     - check_len(x),for variable length fields.
     - msb_check(x,y) for variable length fields to use LSB. x can be
length, and y be msb_val."

thanks,

-- 
Arunprabhu Kandasamy
arun at ackl.io

On 25/09/2017 09:55, Arun wrote:
>> I’m wrong you need the length in order to get the size of the
>> variable fields of the CoAP header as path, but this length is used
>> only for this variable fields the rest of the header fields are
>> known, with the idea of creating a column with the length values you
>> will repeat this known values as much times as rules you have and it
>> will use memory. 
>>
>> information, for example MO called check-length(x) so when you need
>> to read your field you know that you need to read x bits.
>>
>> rule id 1
>>> /- variable: indicates that the field length is variable and is
>>> coded as described in section 2.5
>>> /
>>>      -  We need some sensible way to represent the variable length.
>>>     0 doesn't seem good as Pascal pointed out that there can be
>>>     fields of 0 length.

-- 
Arunprabhu Kandasamy
arun at ackl.io

---

From: Ana Minaburo <[email-masked]>
Date: Fri, 29 Sep 2017 12:17:07 +0200

Hello,

I think that the best solution is the one that sends less bits

Proposal 1: use more memory in the devices but sends the actual bits: length bits plus LSB value

Proposal 2: is similar to the first one, you are not change the actual number of bits 

Proposal 3: instead of LSB bits you are sending the complete value, for instance you are not sending the length bits (4, or 8, or 16)

Proposal 4: you are eliminating the length bits you send and you are sending the LSB bits. 

So for me the best for the transmission view if the proposal 4

Ana

> On 26 Sep 2017, at 21:00, Arun <[email-masked]> wrote:
> 
> Hello all, 
> following are some proposals which you can vote to choose one, or can propose a better one :)
> 
> "Proposal 1:
> add a length column:
>       - ""static"" to represent static fields, length here is obtained with the help from parser." 
> 
> "Proposal 3:
>  no extra column:
>       - there is a limitation to use LSB with MSB as MO for variable length field since we don't know the msb_val." 
> 
> "Proposal 4:
>  no extra column:
>      - msb_check(x,y) for variable length fields to use LSB. x can be length, and y be msb_val." 
> 
> 
> 
> thanks,
> 
> -- 
> Arunprabhu Kandasamy
>>  It becomes trickier when we use LSB without argument. In that case, check_length overloads the MSB MO with additional argument specifying the msb bits?
>>  
>> 
>> thanks,
>> arun
>> 
>> 
>>> ana at ackl.io <http://ackl.io/>
>>> 
>>> www.acklio.com <http://www.acklio.com/>
>>>> On 13 Sep 2017, at 10:38, Laurent Toutain <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> thanks Arun, 
>>>>