Re: [6tsch] report flow contents

[Thomas Watteyne <[e-mail]>]

Fantastic. I guess something like that could work.
Thomas


On Thu, Sep 5, 2013 at 4:17 PM, Xavier Vilajosana Guillen <
[e-mail]> wrote:

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