Re: [6tsch] report flow contents
Thomas Watteyne <watteyne@eecs.berkeley.edu> Fri, 06 September 2013 17:09 UTC
Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F721E80FF for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCF4wqAI-VzD for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:09:12 -0700 (PDT)
Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1167B21E80FA for <6tsch@ietf.org>; Fri, 6 Sep 2013 10:09:11 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so3465327pbb.19 for <6tsch@ietf.org>; Fri, 06 Sep 2013 10:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=KZMkkbjL4OcEc3rp+98y/xebH9sOrlExVwAs7oBZCoc=; b=gIcbpIdQwrAfbqrKcMzCgITl0q2Wim/949m4axmeCU59kurdoZhv1dHLBs/kPPMYzN wEVTADzQFD0/wv2nNSkH4C1/+gx83jqS1A3ZlZmUMkj54hoz+9vT7DQel0kqdXFH+C9W 6Ik2rPQ3LLxhfn7A0zsgqiL250dg9JoE50iC6IHKM53hSU/DeKqSXjCa3Q3nwwtruEcY aqr70BjaDecX6VqtxCq7WykhOBlWGwVN07mW/pW8DjBs7TC31o36Ij8u9CcAhzEBU0SH 8jEQxKV6E8XYYzCd8dZobcaqPvmBEpMDT5Ho7+fQJUryRJQQA42uoLy19pePplv8lBlF mpoA==
X-Received: by 10.66.121.201 with SMTP id lm9mr5170011pab.80.1378487351772; Fri, 06 Sep 2013 10:09:11 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Fri, 6 Sep 2013 10:08:51 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com>
References: <CADJ9OA_XeC7Z5hFxyHhFGqD0aFMcBn=iHzDfRq34sL9qPi2P4A@mail.gmail.com> <CALEMV4YN3rA2OXeAV1akOZhdQrMOQvhN0A+t6vsL9RPVV=VMnQ@mail.gmail.com> <CADJ9OA8Cx3ingeiMdr60zUfMMENiay-Nftv0nMFOTD7=YcKgwg@mail.gmail.com> <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Fri, 06 Sep 2013 10:08:51 -0700
X-Google-Sender-Auth: H1ej6oq0tHAvp26TJY7BWmFXq8M
Message-ID: <CADJ9OA8xPozLTj4ZC8swWsyxCbX0dvZA-yrDJEg0EEtMUDMcYg@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b2e4ca4ee0ed204e5ba1824"
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 17:09:14 -0000
Xavi, Maybe if could be interesting to keep those idea in a temporary "scratchpad". I was thinking a page on the https://bitbucket.org/6tsch/meetings/wiki/Home wiki. Thomas 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**** > > ** ** >
- [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Pascal Thubert (pthubert)
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents P.Zand
- [6tsch] R: report flow contents Alfredo Grieco
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents P.Zand