Re: [6tsch] the 4th control flow

Thanks Qin and Pascal for your clarification.
Now I am synchronize with you! So, I will think again about specifications for the report and control flow.
Maria Rita

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Thursday, August 29, 2013 5:16 PM
To: Qin Wang; Maria Rita PALATTELLA
Cc: Thomas Watteyne; 6tsch@ietf.org; xvilajosana@eecs.berkeley.edu
Subject: RE: [6tsch] the 4th control flow

Hello Qin:

I'm with you that the reports and events are initiated by the device.

Then there is the flow that we discussed at the call last week and that triggered this thread. The use case is a new control loop for which a sensor device talks to the controller (the PCE) to request the establishment of a path between self and an actuator.

I imagined that this was considered an event. But maybe not?

Pascal

From: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org] On Behalf Of Qin Wang
Sent: jeudi 29 août 2013 16:41
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>; xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>
Subject: Re: [6tsch] the 4th control flow

Hi Maria Rita,

Thank you very much for the updated version.

Regarding to who triggers Report Flow and Event Flow, I have different understanding as follows. Being different from Query Flow, both Report Flow and Event Flow are triggered by nodes themselves, instead of a query from ME. In particular, the Report Flow will be triggered by a timer, because it corresponds to periodically reporting behavior; and the Event Flow will be triggered by some event specified by ME in advance, something like a alarm.

What do you think?

Qin

On Thu, Aug 29, 2013 at 5:00 PM, Maria Rita PALATTELLA <maria-rita.palattella@uni.lu<mailto:maria-rita.palattella@uni.lu>> wrote:
All, going back to the definition of the 4 control flows, I tried to fill some of the TODO rows of the tables that Qin created so far.

An updated version of these tables is attached. I left also some comments for discussing on.
Any comment is welcome.

Maria Rita

From: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org>] On Behalf Of Xavier Vilajosana Guillen
Sent: Thursday, August 29, 2013 12:27 AM
To: Qin Wang
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>

Subject: Re: [6tsch] the 4th control flow

Hi, I also agree with the 4 message flows.

as regards to Confirmation, this would introduce end-to-end confirmation at L2.5 - 3. I don't think we need that as a mandatory concept. Maybe an optional feature?

X

On Wed, Aug 28, 2013 at 1:48 PM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
Thomas,

I agree to the 4 control flows. One more question for the two node->ME flows: Is a Confirmation from ME to node needed?

Thanks
Qin

On Thu, Aug 29, 2013 at 2:15 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
All,

If possible, let's keep things simple and stick closely to the charter, certainly for now.

I would like to propose the following assumptions:

  *   let's assume signaling and data packets are independent.
IMO, signaling packets are either short and infrequent (events, commands), or periodic and large (statistics). Once we have run a number of networks, and can quantify the trade-offs, we can consider piggybacking.
  *   let's consider the steps highlighted in the charter, for now:

     *   draft-vilajosana-6tsch-basic gives us a network with minimal connectivity between all nodes in the network. Most of the schedule is empty, available ot some dynamic scheduler.
     *   the scheduler uses the minimal connectivity to communicate, either between neighbors (distributed), or between nodes and the PCE (centralized)
If we agree with this, I propose we go back to discussing the types of flows, per the name of this thread. I'd like to call on a rough consensus for the following 4 flows:

  *   ME->node

     *   action
     *   query

  *   node->ME

     *   report
     *   event
Thomas

On Wed, Aug 28, 2013 at 7:59 AM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
Thomas,

I agree to keep different alternatives, at lease as options.

Regarding to what kinds of cells should be used for conveying the report, shared cells or dedicated cells, I would like to leave them to configuration. What do you think?

Thanks
Qin

On Wed, Aug 28, 2013 at 6:39 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
Qin,

You bring up a good point: over what cells with the reports travel? Another questions could be: over what cells will the request to install cells travel? I believe that, whatever the policy in place in the network, there will always need to be some cells installed for infrequent signaling traffic. If the report rate is very slow, it might qualify as "infrequent signaling traffic". For sure, the request to change the schedule qualifies.

Isn't the answer draft-vilajosana-6tsch-basic? That is, the slotted Aloha schedule indicated in the draft can be used for the signaling traffic between the nodes and the ME. Of course, if the report rate is very high, some dedicate track might be installed, but I do not believe this is needed, certainly not this early on.

I agree with Diego that keeping the solution open to different alternative is key.

Thomas

On Tue, Aug 27, 2013 at 2:29 PM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>> wrote:
Qin, Thomas,
      Alternative (1) adds delay to define the slots to send the event
to the ME (propagate the new schedule),
while alternative (2)  keeps reserved slots waiting for the event to happen.
I think both alternatives should be included, and configured by the ME depending
on the network requirements.

More thoughts?

Diego Dujovne

2013/8/27 Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>>:
> Thomas,
>
> I agree with almost all. Only some comments on "Report Flow".
>
> As you mentioned, there are two kinds of report scenarios, one is
> periodically report, another one is burst report or called as event-driven
> report. I have no question on how periodically report works, which you
> described. But I'm not sure what the best way to handle event-driven report
> is. I think we don't want to assume 6top sublayer is very intelligent, in
> another word, the events and the trigger of events should be configured by
> ME, just like the interval of periodically report. Make sense?
>
> If you agree to it, the remained issue is  when and how the bandwidth for
> sending event-driven reports is reserved. Here are two ways I can see.
> (1) when a event is triggered, node sends a request to ME and ask some BW to
> send the report. I believe that is how the 4th control flow works.
> (2) when ME configure the events and their triggers, ME also provisions some
> BW for the node which allows the node to send the report triggered by some
> event.
>
> I have no strong opinion on which one is better. But, the bottom line is the
> configuration of the set of events and their triggers should be out of 6top
> scope. Thought?
>
> Thanks
> Qin
>
>
>
>
>
>
> On Wed, Aug 28, 2013 at 2:20 AM, Thomas Watteyne <twatteyne@linear.com<mailto:twatteyne@linear.com>>
> wrote:
>>
>> Qin,
>>
>> Please correct me if I'm wrong:
>> - Action Flow (ME->6top). ME asks 6top to execute some command. Typical
>> commands are add/delete cells.
>> - Query Flow (ME->6top). ME asks 6top for some information. Typical
>> queries are about current cells usage or statistics.
>> - Report Flow (6top->ME). 6top tell ME how it is doing. Typical reported
>> information covers cells usage or statistics.
>>
>> Questions:
>> - Looks like Query and Report flows contain the same information. In
>> normal operation, the Report flow should be enough, the Query flow only
>> being used in special cases, for example when the ME has lost state (just
>> booted, bug, etc). Agreed?
>> - The ME should be able to configure the report flow. Configuration could
>> be "send report every X seconds" or "send report when variable X larger than
>> Y". I imagine this could be done over the action flow? Agreed?
>> - A node will want to report an urgent event to the ME. One such events is
>> "the topology appears to have changed". There any many cases where this
>> information needs to be sent immediately, i.e. no time to wait for the next
>> report cycle. We can consider this to be an asynchronous report, or part of
>> a new "Event" flow.
>> - Same for the mote asking the ME for a schedule update.
>>
>> Thoughts?
>>
>> Thomas
>>
>>
>>
>> On Fri, Aug 23, 2013 at 11:00 AM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
>>>
>>> Xavi,
>>>
>>> Approach-(2) is more flexible and likely covers more situations. But, it
>>> may bring some complexity to 6top, because 6top has to make decision on the
>>> bandwidth request (add/delete), which needs some metrics, some intelligence.
>>>
>>> What do you think?
>>>
>>> Qin
>>>
>>>
>>>
>>> On Sat, Aug 24, 2013 at 1:47 AM, Xavier Vilajosana Guillen
>>> <xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>> wrote:
>>>>
>>>> Hi Qin, I like your (2).
>>>>
>>>> Note also that there are situations that might have some differences.
>>>>
>>>> 1-the track already exists.
>>>> 2-the track between the two entities does not exists
>>>>
>>>> in either case I think that the node that requires certain BW to another
>>>> node should talk to 6top, which processes that request and sends a request
>>>> to the ME, the ME installs that new track.
>>>>
>>>> does it make sense. Do you see any drawback on that approach?
>>>>
>>>> X
>>>>
>>>>
>>>> On Fri, Aug 23, 2013 at 10:36 AM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> During today's call, we presented three control flows between
>>>>> Management Entity (ME) and 6top, i.e. Action Flow, Query Flow, and Report
>>>>> Flow, and started to talk about the 4th control flow. The thread will
>>>>> continue the discussion about 4th flow.
>>>>>
>>>>> Here is the scenario: when a node finds that more cells are needed,
>>>>> e.g. nodes wants to send 10pkt/s report at some time, it should be able to
>>>>> ask ME to install more bandwidth.
>>>>>
>>>>> I can see two approaches:
>>>>> (1) Managed by ME, without 4th Control Flow. Assume BandwidthUsageRate
>>>>> is a attribute in 6top. Then, ME can get the information via Query Flow or
>>>>> Report Flow, and adjust the bandwidth of the node via Action Flow.
>>>>> (2) Managed by 6top, with 4th Control Flow. 6top sends Bandwidth
>>>>> Request to ME, and then ME install more bandwidth. This is the 4th control
>>>>> flow.
>>>>>
>>>>> What do you think? Which one makes more sense?
>>>>>
>>>>> 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
>>>
>>
>>
>>
>> --
>> Thomas Watteyne, Ph. D
>> Sr. Networking Design Engineer
>> Dust Networks / Linear Technology
>> 30695 Huntwood Ave
>> Hayward, CA 94544-7021
>> +1 (510) 400-2978<tel:%2B1%20%28510%29%20400-2978>
>> twatteyne@linear.com<mailto:twatteyne@linear.com>
>>
>> This e-mail transmission, and any documents, files or previous e-mail
>> messages attached to it may contain confidential information that is legally
>> privileged. If you are not the intended recipient, or a person responsible
>> for delivering it to the intended recipient, you are hereby notified that
>> any disclosure, copying, distribution or use of any of the information
>> contained in or attached to this transmission is STRICTLY PROHIBITED. If you
>> have received this transmission in error, please immediately notify me by
>> reply e-mail, or by telephone at (510) 400-2978<tel:%28510%29%20400-2978>, and destroy the original
>> transmission and its attachments without reading or saving in any manner.
>> Thank you.
>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org<mailto: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<http://www.ingenieria.udp.cl>
(56 2) 676 8125<tel:%2856%202%29%20676%208125>
_______________________________________________
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