Re: [6tsch] report flow contents

Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> Fri, 06 September 2013 17:43 UTC

Return-Path: <xvilajosana@berkeley.edu>
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 ED89F21F9B60 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 fg1TgWdju+7y for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:43:23 -0700 (PDT)
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8811E80F4 for <6tsch@ietf.org>; Fri, 6 Sep 2013 10:43:23 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id kq13so3619902pab.11 for <6tsch@ietf.org>; Fri, 06 Sep 2013 10:43:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DXwYRki9fWN6Br5H4XYpTFAB6vdNmKo+OQpmXVbQn54=; b=GwY8xEyLRQrYcsFtn3Y35oU9Kz3iYooGMRv5rQBO4fk5pPkkIcfDRe1IV9vEst76rV 0ZySvVZ+7hOMEijIyqydmzEv7BxKAqQ/hAKqzW5zvjQoUS1lv1aSmyNe4JO8Y6/43NSn FHU0egJ6W72MPkkicmamcw8RDC2bEIIQ5Ox0Z+ic670XInkH25RVbfMAEeYfpV+gxNdG IoJ2ij81TCPidfSWlMhAXxB3Rk7SKELM1YcmYc9aS+CphBeLL8GfX0r7wbigkhirqnQb s//4krQEs9PDPsnos1PFOkJYqzuDpk5vWIZgquNVlqXmiL2T0spUzqaqSSfhF3uGyAPx U0Vw==
X-Gm-Message-State: ALoCoQmxZLYOD3WhxzIukmecIoEbXAPbXgtICT21PRwXVGTXDwpQwBZKtiAfM2wttBobHMlofk3L
MIME-Version: 1.0
X-Received: by 10.66.240.67 with SMTP id vy3mr5174752pac.141.1378489403074; Fri, 06 Sep 2013 10:43:23 -0700 (PDT)
Received: by 10.70.34.44 with HTTP; Fri, 6 Sep 2013 10:43:22 -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>
Date: Fri, 6 Sep 2013 10:43:22 -0700
Message-ID: <CALEMV4a=azY5MU00jNmcoek022gS=pUeXK1xVnucG+Zy6NTBOA@mail.gmail.com>
From: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b15ab7f3276d304e5ba93dd
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: xvilajosana@eecs.berkeley.edu
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:43:28 -0000

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