Re: [6tsch] report flow contents
"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Fri, 06 September 2013 14:50 UTC
Return-Path: <diego.dujovne@mail.udp.cl>
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 C211111E8196 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 07:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LYnhprGiEDf9 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 07:50:06 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 837DC11E81A0 for <6tsch@ietf.org>; Fri, 6 Sep 2013 07:50:05 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hm2so995111wib.10 for <6tsch@ietf.org>; Fri, 06 Sep 2013 07:50:04 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l4QxYC3bgbcBeRpMqYN0CFEkJhamo3i/ynYQZEPY8k8=; b=EeHB8hf5u+vosPxLOq08y7LORoVDY+Y78kQ45rf17MiOkQYzyFNeMa7TB9U0uq99t5 98maxJiUI/n2T0C4DngtUzQVNARge/RF0sgJzmqD+vy7B2ddLVVe1YEltADJ4SoKedN3 FDG3nFbZ9CkLn4urC1Z/xKV8fTyG03Rh0oWS/isKn1WzzEEa+pIwMLugjdZVM6kL+mrq C6UJaA9Y3/XF7By5S7lC38n2N2YnHpgyJQ7OAk50RjNvE3NGiv7jE5eFz5twauS7U4kK O1NlZJhtv6R7ovv4Rt6lBqGfqsqLDMq2GFF6FE5iC12dvyxIReItypAcwxvZ43ekgu0g UuAQ==
X-Gm-Message-State: ALoCoQmmwq45sWt5Aqf6umn5TE7zuv8atd5R1OJ9DRaF4SqGOggrYVyQjUA6qHNP9wjpI34gzvOS
MIME-Version: 1.0
X-Received: by 10.194.79.33 with SMTP id g1mr34204wjx.79.1378479004350; Fri, 06 Sep 2013 07:50:04 -0700 (PDT)
Received: by 10.194.122.103 with HTTP; Fri, 6 Sep 2013 07:50:04 -0700 (PDT)
In-Reply-To: <CAAzoce6DChK8WqwhiXZymL=y4-MtM-JLCvVNBBDHAPvb6=z5SA@mail.gmail.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> <CADJ9OA8Fy1iNNsukShN_jYnBVY6LsbEP5j+P_bvuOvCxX8O2vw@mail.gmail.com> <CAAzoce6DChK8WqwhiXZymL=y4-MtM-JLCvVNBBDHAPvb6=z5SA@mail.gmail.com>
Date: Fri, 06 Sep 2013 10:50:04 -0400
Message-ID: <CAH7SZV-du-A_N4Kg2_q=3LxxP40V5W-Kf44x2cbVefv-0X_uqg@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: Qin Wang <qinwang@berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, "6tsch@ietf.org" <6tsch@ietf.org>, Xavi Vilajosana <xvilajosana@eecs.berkeley.edu>
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 14:50:10 -0000
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 <qinwang@berkeley.edu>: > 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 <watteyne@eecs.berkeley.edu> > wrote: >> >> Fantastic. I guess something like that could work. >> Thomas >> >> >> On Thu, Sep 5, 2013 at 4:17 PM, Xavier Vilajosana Guillen >> <xvilajosana@eecs.berkeley.edu> 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 >>> <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 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 > -- 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
- [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