Re: [6tsch] report flow contents

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 September 2013 15:51 UTC

Return-Path: <pthubert@cisco.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 E804711E8122 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 08:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.498
X-Spam-Level:
X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 kS42UC0X+dHK for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 08:51:17 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB6811E81B2 for <6tsch@ietf.org>; Fri, 6 Sep 2013 08:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39586; q=dns/txt; s=iport; t=1378482676; x=1379692276; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=asT0nxwPRnSS8Ssuc/NByuazkq2OQFdtDT7s9msobKM=; b=b813i/riJcmlK9dIItrcQpMw48+Im7odv+pAMox6G+ZGYjfd8Ob8tqQG +tk23Z9iNtyhXOIV7yPA1UiHRZYO7ZLlaW6Aqeo5W42fjNKrl1OYShz0y ukhF8J1D1Vudwo4WLu4tsqerCtD+hmZFnOaSJTvVbGR8M4ai/e4vCdNXd E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAMX5KVKtJV2Z/2dsb2JhbABbDoI1RDVRwVWBJBZ0giQBAQEEAQEBKkELEAIBCBEEAQELFgEGBycLFAkIAgQBDQUIh3oMvX4Ej0stBAYBBoMXgQADhUukEIJhP4Iq
X-IronPort-AV: E=Sophos; i="4.90,855,1371081600"; d="scan'208,217"; a="256502104"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 06 Sep 2013 15:51:09 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r86Fp8g6027483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 15:51:08 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 10:51:08 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "xvilajosana@eecs.berkeley.edu" <xvilajosana@eecs.berkeley.edu>, "Thomas Watteyne" <watteyne@eecs.berkeley.edu>
Thread-Topic: [6tsch] report flow contents
Thread-Index: AQHOqmeXwGSOL2GQs06/pxHNNYU8RZm34IwAgAA2pACAAAP0gIAAwPaA
Date: Fri, 6 Sep 2013 15:51:08 +0000
Deferred-Delivery: Fri, 6 Sep 2013 15:51:00 +0000
Message-ID: <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>
In-Reply-To: <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.64.110]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84145CB61xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "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
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 15:51:22 -0000

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch