Re: [6tsch] report flow contents

[Xavier Vilajosana Guillen <[e-mail]>]

agreed!
So the fields become:


For each known neighbor:
 -ID
 -AVG RSSI in a running window
 -Latest RSSI
 -AVG LQI in a running window [optional]
 -Latest LQI [optional]
 -Num TX packets (option in case there is communication with that neighbor)
 -Num ACK packets (option in case there is communication with that neighbor)
 -Num RX packets (option in case there is communication with that neighbor)
 -Last ASN when it heart about that neighbor
 -Bundle: Num links in the Schedule to that neighbor
      -PDR per link [Optional -- or maybe best and worst PDR only]

 -Option Flag (weather there are optional TLV fields on that category)
   +(TLV objects)*

 -For each Queue:
    - Avg Queue length in a running window
    - Max Queue length in a running window (peak)
    - Current Queue length (?)
    - ASN of the oldest packet in the QUEUE?
    -Option Flag (weather there are optional TLV fields on that category)
        +(TLV objects)*

-Time source parent
    -ID
    -Avg clock drift (correction done) in a running window
    -Latest clock correction
    -Parent changes (counter of how many times I changed my time source
parent)
    -Option Flag (weather there are optional TLV fields on that category)
    +(TLV objects)*

-Option Flag (weather there are optional TLV fields in other categories)
   +(TLV objects)*

as regards to this:

"Finally, do you envision a generic mechanism whereby the PCE can turn
fields on/off, or triggered independently?"

I see it as CoAP Options, where a set of bytes can be used as "clever
bitmap" to tell what options are there, the parsing will decode option by
option and will read the fields. In that way any combination of fields is
supported.

would that work?
X


On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne
<[e-mail]>wrote:

> Xavi,
>
> Fantastic!
>
> I believe PDR for each link might be too long to fit in a packet. While
> the mote will most likely keep that information, we could move that to the
> query flow, i.e. it is available to the PCE on-demand.
>
> Would you agree that the number of links in a bundle belongs to the
> neighbor? Of maybe we want a "bundle" category?
>
> In queuing, it might be interesting to see the age of the different
> packets, to be able to monitor latency.
>
> About LQI, there is no general consensus among vendors on what the
> definition is, or how exactly it is calculated. I would make it optional.
>
> Also, it might be good to be able to add arbitrary fields to each
> category: neighbor, queue, time source neighbor.
>
> Finally, do you envision a generic mechanism whereby the PCE can turn
> fields on/off, or triggered independently?
>
> Thomas
>
>
> On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen <
> [e-mail]> wrote:
>
>> Hi Thomas, Diego,
>>
>> I agree that LQI should be there as well. I update here the list with
>> Thomas suggestions.
>>
>> For each known neighbor:
>>  -ID
>>  -AVG RSSI in a running window
>>  -Latest RSSI
>>  -AVG LQI in a running window
>>  -Latest LQI
>>  -Num TX packets (option in case there is communication with that
>> neighbor)
>>  -Num ACK packets (option in case there is communication with that
>> neighbor)
>>  -Num RX packets (option in case there is communication with that
>> neighbor)
>>   -Last ASN when it heart about that neighbor
>>
>> Other fields
>>  -Num links in the Schedule to that neighbor
>>     -For each link PDR
>>  -For each Queue:
>>     - Avg Queue length in a running window
>>     - Max Queue length in a running window (peak)
>>     - Current Queue length (?)
>> -Time source parent
>>      -ID
>>     -Avg clock drift (correction done) in a running window
>>     -Latest clock correction
>>     -Parent changes (counter of how many times I changed my time source
>> parent)
>>
>>  -Option Flag (weather there are optional TLV fields)
>>    +(TLV objects)*
>>
>>
>> Hope this makes sense.
>> cheers!
>> Xavi
>>
>>
>> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <
>> [e-mail]> wrote:
>>
>>> *[renamed thread]*
>>>
>>> Xavi,
>>>
>>> A few thoughts:
>>> - the counters (numTx, etc) will only be present for neighbors the node
>>> has communicate with, so they should be optional in the packet.
>>> - you have focused on the topological information (which I think is the
>>> right one). It might be useful to gather other data related to
>>> synchronization or queuing.
>>> - I couldn't agree more with your suggestion to make it extensible. This
>>> does mean that we will need to state somewhere that a device need to ignore
>>> silently fields it does not understand.
>>>
>>> Thomas
>>>
>>> On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen <
>>> [e-mail]> wrote:
>>>
>>>> Hello, I guess that flows are getting defined and I started to think on
>>>> the contents of the messages on that flows. Not sure if this is the right
>>>> time or I am going way far..
>>>>
>>>> According to the previous discussion I assume that the five flows are:
>>>>
>>>> ME-6TOP - Query Flow
>>>> ME-6TOP - Action Flow
>>>>
>>>> 6TOP - ME - Report Flow
>>>> 6TOP - ME - Event Flow
>>>> 6TOP - ME - Request BW Flow
>>>>
>>>> I'd like to start defining the content of the messages in the Report
>>>> Flow:
>>>>
>>>> The Report Flow: has to deal with the information that a node knows and
>>>> has to be sent to the ME so the ME can compute the schedule among others.
>>>> Here I list  the information that we can know in a mote and can be used at
>>>> the ME to compute the schedule (complete please if I miss something)
>>>>
>>>> For each known neighbor:
>>>>  -ID
>>>>  -AVG RSSI in a running window
>>>>  -Latest RSSI
>>>>  -Num TX packets
>>>>  -Num ACK packets
>>>>  -Num RX packets
>>>>  -Last ASN when it heart about that neighbor
>>>>
>>>> Other fields
>>>>  -Num links in the Schedule to that neighbor
>>>>     -For each link PDR
>>>>
>>>>
>>>> Then we need to have some TLV like objects that can be used for
>>>> ad-hoc/naive/other extensions of the reporting process. In that way we
>>>> don't constraint the implementation of the scheduling alg. to that
>>>> information.
>>>>
>>>> what do you think?
>>>> X
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[e-mail]>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> In this thread, we will continue the discussion about Confirmation
>>>>> message. Here is some background information.
>>>>>
>>>>> Context: e.g.
>>>>>     - node sends a report and want to know if the report is accepted.,
>>>>>     - ME sends a action request and want to know if/when the action
>>>>> taken.
>>>>> Options:
>>>>>    (1) Nothing
>>>>>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)
>>>>>    (3) App-level ACK type
>>>>>    (4) Use different flow (i.e. action flow)
>>>>>
>>>>> IMHO, different control flow may have different requirement for
>>>>> confirmation message.
>>>>>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail
>>>>>     (2) Query Flow, automatically has the confirmation, i.e. the
>>>>> message packet corresponding to a specific query.
>>>>>      (3) Report Flow and Event Flow, option (1)-(3) are OK, but I
>>>>> prefer option (1) and (3), i.e. the confirmation message is an option, but
>>>>> if a confirmation message is needed, it should be App-level Ack, instead of
>>>>> transport layer confirmation, which will give 6top more flexibility.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks
>>>>>  Qin
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 6tsch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 6tsch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>