Re: [6tsch] report flow contents

Qin Wang <qinwang@berkeley.edu> Fri, 06 September 2013 13:40 UTC

Return-Path: <qinwang@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 C936F11E818B for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 06:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.887
X-Spam-Level:
X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.089, 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 NsyY48zwxIy8 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 06:40:52 -0700 (PDT)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 38DD211E8128 for <6tsch@ietf.org>; Fri, 6 Sep 2013 06:40:52 -0700 (PDT)
Received: by mail-vb0-f53.google.com with SMTP id i3so2136392vbh.40 for <6tsch@ietf.org>; Fri, 06 Sep 2013 06:40:51 -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; bh=kRL21KmuShR5XfTzR2UyKsv643NJh652Ovzc31mtMGU=; b=ewb8vYGspScsn/DOHuDeY68dkrKXzP1CFDsWnZ0bhgWXl2ttjaPXXPghMcoWHyY+ai pVoOG78wVb2/DNi1yDx7NYNKq+pG9mui9ugG24MrIYuI+8oMBz6jH2A8zcglyxuLbCtq Ly/i/FVvRC9mqKq6gtXIt0/AggPwqpC3IVh4RXmOKzgisfxLN3qa35oqrCgtvuhfKeKj SXzD3zuEc6oflCq4yv7Kj1ak8GaQGkPzSfrJKSEVJGEvmSShs6y2iCEyURl1jxmbZIfp eS4649ptk8nRT1RlfV0R4QZOY9w5GbGi0HW6MVxVZfLMnckWTz8E6WSMX0npiIIcMQsp H3cw==
X-Gm-Message-State: ALoCoQmy8i0D9Np1lA1EV4WnaJpxNa0UeMsdmxBo3QYyXGgBsitJsoKGk6xLUYWEg/fzKWBabRmd
MIME-Version: 1.0
X-Received: by 10.58.118.130 with SMTP id km2mr2396473veb.0.1378474851552; Fri, 06 Sep 2013 06:40:51 -0700 (PDT)
Received: by 10.220.116.135 with HTTP; Fri, 6 Sep 2013 06:40:51 -0700 (PDT)
In-Reply-To: <CADJ9OA8Fy1iNNsukShN_jYnBVY6LsbEP5j+P_bvuOvCxX8O2vw@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>
Date: Fri, 6 Sep 2013 21:40:51 +0800
Message-ID: <CAAzoce6DChK8WqwhiXZymL=y4-MtM-JLCvVNBBDHAPvb6=z5SA@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=089e013a05acdbe41404e5b72f4f
Cc: "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 13:40:56 -0000

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