Re: [6tsch] report flow contents

Xavi,
Great, thanks!
Thomas

On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
xvilajosana@eecs.berkeley.edu> wrote:

> Hi,
> I created the scratchpad section in the wiki to keep ideas
> https://bitbucket.org/6tsch/meetings/wiki/Home
>
>
> and added the flow content information here.
>
> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents
>
> have a nice weekend!
> X
>
>
> On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen <
> xvilajosana@eecs.berkeley.edu> wrote:
>
>> Hi Pascal, it is a good idea!
>>
>> I will collect that information and as Thomas put it at the wiki so we do
>> not lose it.
>>
>> :-)
>> X
>>
>>
>> On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) <
>> pthubert@cisco.com> wrote:
>>
>>>  Hello Xavi:****
>>>
>>> ** **
>>>
>>> At the call I mentioned we could use info on tracks and cells as well,
>>> probably on demand from the PCE.****
>>>
>>> For instance, the PCE could observe energy levels over some cells for  a
>>> while to make sure they are clean.****
>>>
>>> ** **
>>>
>>> What do you think?****
>>>
>>> Pascal****
>>>
>>> ** **
>>>
>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>>> Behalf Of *Xavier Vilajosana Guillen
>>> *Sent:* vendredi 6 septembre 2013 01:17
>>> *To:* Thomas Watteyne
>>> *Cc:* 6tsch@ietf.org
>>> *Subject:* Re: [6tsch] report flow contents****
>>>
>>> ** **
>>>
>>> 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 <
>>> watteyne@eecs.berkeley.edu> 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 <
>>> xvilajosana@eecs.berkeley.edu> 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 <
>>> watteyne@eecs.berkeley.edu> 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 <
>>> xvilajosana@eecs.berkeley.edu> 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 <qinwang@berkeley.edu> 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
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ** **
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>
>>
>