Re: [6tsch] report flow contents

["Prof. Diego Dujovne" <[e-mail]>]

Qin,
        I agree with the MIB approach. It would provide more scalability
for future versions too. I think the implementation cost and the added
processing time is worth it.

Diego




2013/9/6 Qin Wang <[e-mail]>du>:
> Hi Xavi and Thomas,
>
> I agree Xavi's the list. I also agree that it is very important to have a
> generic mechanism whereby the PCE can turn fields on/off, or triggered
> independently. I guess "Option Flag" is used to turn on/off. Correct?
>
> Furthermore, I would like suggest to think the list as MIB, and leave Report
> Packet configurable. For example, in the following list
>
>  -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)*
>
> A specific PCE is not interested in Latest RSSI, then the PCE can use Action
> Flow to configure its own Report Packet without the field, and don't need
> the "Option Flag" in every report packet.
>
> What do you think?
>
> Qin
>
>
> On Fri, Sep 6, 2013 at 7:18 AM, Thomas Watteyne <[e-mail]>
> wrote:
>>
>> 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
>>>>
>>>
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125