Re: [6tsch] report flow contents

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

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 <
[e-mail]> 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) <
> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>> Behalf Of *Xavier Vilajosana Guillen
>> *Sent:* vendredi 6 septembre 2013 01:17
>> *To:* Thomas Watteyne
>> *Cc:* [e-mail]
>> *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 <
>> [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****
>>
>> ** **
>>
>
>