Subject: [6tsch] Bandwidth requirement, Explicit vs. Implicit

From: [email-masked]
Date: Mon, 11 Feb 2013 10:26:28 -0800

Hi all,

One of 6tech functions should be translating Bandwidth requirements into
Links (slot, channel) allocation, in another word, reserving Links to meet
BW requirements. The problem is who generates BW requirements, and how.
There may be two approaches.

(1) Explicit BW generation: upper layer, e.g. RSVP, generates BW
requirement and tell 6tsch, and then 6tsch reserves some Links to meet the
BW requirement.

(2) Implicit BW generation: upper layer just tells 6tsch to send data.
6tsch figures out the BW requirements by itself according to the traffic
load, and then reserve Links to meet the BW requirement.

How do you think?

Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 11 Feb 2013 10:36:04 -0800

Hi Qin,

I see your point, we need to consider that in 6tsch. Imagine that an 
applications or any RSVP layer decides to install certain BW on a link. 
The question is whether all the nodes in the path from that node to the 
sink have to be explicitly configured with the BW requirement or this 
can be implicit, as the nodes in the path will need to carry the 
required traffic.

For a centralized scheduling technique, this is feasible, i.e the 
central scheduler has a knowledge of the topology and can decide about 
BW along the path. Using a decentralized approaches, nodes need to 
"figure out" the incoming and outgoing BW so they can adjust their links 
to their parents. So would be good that 6tsch can support both approaches.

so I agree with you.
X.

On 11/02/13 10:26, [email-masked] wrote:
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 11 Feb 2013 21:48:49 -0800

All,

Let's assume for a moment we are done defining a technique for assigning
arbitrary amounts of bandwidth along some multi-hop path. Do we know of any
RFCs/work we could reuse which describe such a traffic monitor? I can think
about several ways of doing that, an as many argument describing why this
is hard, but it's always better to start off with something that exists.

Thomas

On Mon, Feb 11, 2013 at 10:36 AM, Xavier Vilajosana <
[email-masked]> wrote:

> applications or any RSVP layer decides to install certain BW on a link. The
> question is whether all the nodes in the path from that node to the sink
> have to be explicitly configured with the BW requirement or this can be
> implicit, as the nodes in the path will need to carry the required traffic.
>
> For a centralized scheduling technique, this is feasible, i.e the central
> scheduler has a knowledge of the topology and can decide about BW along the
> path. Using a decentralized approaches, nodes need to "figure out" the
> incoming and outgoing BW so they can adjust their links to their parents.
> So would be good that 6tsch can support both approaches.
>
> so I agree with you.
> X.
>
>
>> ______________________________**_________________
>> 6tsch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/6tsch<https://www.ietf.org/mailman/listinfo/6tsch>
>>
>
> ______________________________**_________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/6tsch<https://www.ietf.org/mailman/listinfo/6tsch>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 12 Feb 2013 11:31:37 -0800

Hi Thomas,

RSVP related RFCs (namely RFC 2205 (RSVP) and RFC 3209 (RSVP-TE)) define 
a mechanism to maintain and update route status. It is based on a 
refresh timeout that is sent through the path during the reservation 
process. When this timeout expires RSVP checks if something has changed 
and sends reservation or path messages to re-configure the path in case 
it is needed.

check section 2.3 of RFC2205

http://www.ietf.org/rfc/rfc2205.txt

X

On 11/02/13 21:48, Thomas Watteyne wrote:
> Do we know of any RFCs/work we could reuse which describe such a 
> traffic monitor?

---

From: [email-masked]
Date: Wed, 13 Feb 2013 10:53:38 -0800

Hi Alfredo,

You have very good point.

In TSCH, we have several parameters to play:
(1) multiple slotframes, with different frame length and priority.
(2) number of links
(3) link allocation (slot, channel)

So, definitely we can translate more about Qos to the schedules used by TSCH.

Do you have specific idea about what the interface between 6tsch and upper
layer should be?

Thanks
Qin

> Hi Qin, and all,
>
> Should we think also to traffic specifications other than bandwidth ?
>
> Depending on the application and on the scenario, the schedule could be
> built to enforce fault tolerance too (and/or other KPI) .
>
> In this case, 6TSCH should translate QoS (in general, including bandwidth
> of
> course) into Links (slot, channel) allocations.
>
> What do you think about ?
>
> Many thanks in advance for your thoughtful replies.
>
> Alfredo
>
>
> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto di
> [email-masked]
> Inviato: Monday, February 11, 2013 7:26 PM
> A: IETF 6TSCH
> Oggetto: [6tsch] Bandwidth requirement, Explicit vs. Implicit
>
> Hi all,
>
> requirement
> and tell 6tsch, and then 6tsch reserves some Links to meet the BW
> requirement.
>

---

From: "Alfredo Grieco" <[email-masked]>
Date: Wed, 13 Feb 2013 20:14:36 +0100

Hi Qin, Pascal, and all,

I would prefer to keep open mind at the present stage: the interface should
be the outcome of a deep thinking process.

As you said, TSCH is flexible enough to accommodate many different
requirements, having at least three parameters to throttle.

There is another requirement to point out: in industrial applications most
of nodes are fixed but some of them can move (at some time). Thus, whatever
the interface is, the schedule should account for some degree of node
mobility. This, probably, will require some portions of the slotframe to be
reserved to accommodate unpredictable (yet real time) traffic contributed by
mobile nodes.

Regarding Implicit vs. Explicit BW reservation/requirement/signaling,
probably it could be nice to use RSVP because it already exists and it is
the result of a very long research & standardization process: why should we
invent something that already exist ? We could just tailor RSVP to our
purposes (I am really ready to change my idea if needed).

Finally, to answer a Pascal's question regarding the chicken and egg problem
(routing and scheduling), I would like to remark that IMHO a baseline DODAG
should be made available (before) to handle all the signaling required to
build a sophisticated and cross-layer scheduling & routing optimization
(after). It remains open the problem of defining the number of
slots/channel/frames that could host such a first instance DODAG and how to
build it.

Sorry for my very long email.

Cheers

Alfredo

--

Luigi Alfredo Grieco, Ph. D.
Assistant Professor in Telecommunications 
DEE - Politecnico di Bari 
Via Orabona, 4 - 70125 - Bari - Italy
Phone: +39 080 5963 911
Fax: +39 080 5963 410
telematics.poliba.it/grieco 

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di
[email-masked]
Inviato: Wednesday, February 13, 2013 7:54 PM
A: Alfredo Grieco
Cc: 'IETF 6TSCH'
Oggetto: Re: [6tsch] R: Bandwidth requirement, Explicit vs. Implicit

Hi Alfredo,

So, definitely we can translate more about Qos to the schedules used by
TSCH.

Thanks
Qin

> Depending on the application and on the scenario, the schedule could 
> be built to enforce fault tolerance too (and/or other KPI) .
>
> In this case, 6TSCH should translate QoS (in general, including 
> bandwidth of
> Da: [email-masked] [mailto:[email-masked]] Per conto 
> di [email-masked]
> One of 6tech functions should be translating Bandwidth requirements 
> into Links (slot, channel) allocation, in another word, reserving 
> Links to meet BW requirements. The problem is who generates BW
requirements, and how.
> requirement and tell 6tsch, and then 6tsch reserves some Links to meet 
> the BW requirement.
>
> 6tsch figures out the BW requirements by itself according to the 
> traffic load, and then reserve Links to meet the BW requirement.
>
> How do you think?
>
> Qin
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Wed, 13 Feb 2013 13:25:41 -0800

>> IMHO a baseline DODAG should be made available (before) to handle 
all the signaling required to
 >> build a sophisticated and cross-layer scheduling & routing 
optimization (after).

Alfredo - I agree.  I'd vote for the simplest possible specification at 
L2.  DAG root picks a superframe length, schedules a single 
slotted-aloha link in that frame, and the network builds on that. For 
many applications this is all they need, but almost any network will 
benefit from optimization beyond this.

The benefit of this is that it is easy for non-TSCH people to 
understand, and relatively easy to implement.
The down side is that it isn't optimal for ... anything.

ksjp

---

From: Grieco <[email-masked]>
Date: Thu, 14 Feb 2013 01:53:04 +0100

Dear Kris, 

I fully agree with you. 

In fact, in my previous mail I wrote "It remains open the problem of defining the number of slots/channel/frames that could host such a first instance DODAG and how to build it." meaning that the baseline dodag I am talking about should be built (I still do not know how) in order to be optimal as you suggest.

Of course, a single slot for every frame could be too much or too less depending on the network we are considering and, as a consequence, optimality will be never reached with such a static and blind assignment.

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

On 13 Feb 2013, at 22:25, Kris Pister <[email-masked]> wrote:

> >> IMHO a baseline DODAG should be made available (before) to handle all the signaling required to
> >> build a sophisticated and cross-layer scheduling & routing optimization (after).
> 
> Alfredo - I agree.  I'd vote for the simplest possible specification at L2.  DAG root picks a superframe length, schedules a single slotted-aloha link in that frame, and the network builds on that. For many applications this is all they need, but almost any network will benefit from optimization beyond this.
> 
> The benefit of this is that it is easy for non-TSCH people to understand, and relatively easy to implement.

---

From: Kris Pister <[email-masked]>
Date: Wed, 13 Feb 2013 20:51:12 -0800

yes, I think that we're in violent agreement.  Now we just need to find 
someone who disagrees with the Bari-Berkeley Alliance :)

ksjp

On 2/13/2013 4:53 PM, Grieco wrote:
> Dear Kris,
>
> I fully agree with you.
>
> In fact, in my previous mail I wrote "It remains open the problem of 
> defining the number of slots/channel/frames that could host such a 
> first instance DODAG and how to build it." meaning that the baseline 
> dodag I am talking about should be built (I still do not know how) in 
> order to be optimal as you suggest.
>
> Of course, a single slot for every frame could be too much or too less 
> depending on the network we are considering and, as a consequence, 
> optimality will be never reached with such a static and blind assignment.
>
> Cheers
>
> Alfredo
>
> -- 
> telematics.poliba.it/grieco <http://telematics.poliba.it/grieco>
> On 13 Feb 2013, at 22:25, Kris Pister <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Alfredo - I agree.  I'd vote for the simplest possible specification 
>> at L2.  DAG root picks a superframe length, schedules a single 
>>> telematics.poliba.it/grieco <http://telematics.poliba.it/grieco>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Da: [email-masked] <mailto:[email-masked]> 
>>> [mailto:[email-masked]] Per conto di
>>> [email-masked] <mailto:[email-masked]>
>>>> Da: [email-masked] <mailto:[email-masked]> 
>>>> [mailto:[email-masked]] Per conto
>>>> di [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Pascal Thubert <[email-masked]>
Date: Thu, 14 Feb 2013 10:33:09 +0100

That will not be me : )

In fact the initial amount of space we allocate boils down to a virtual shared link speed that conditions the network formation time (together with trickle settings). Somehow those 2 appear to be linked together.

The rich version of Kris ´ proposal would probably allocate more slots for control than needed in steady state. 
Early in the init  the network would see fast links and grow rapidly.

As routes are established, some of those slots could be used for traffic (always lower prio than net control) as control demands recede.

And then traffic observation could lead to dedicated slot allocation freeing space for new flows. 

My reading of the list is that we agree to use virtual slot allocation for unicast, that will or will not be mapped in actual slots dependant on usage.

Thomas mentioned an analogy with Frame relay.  CIR is traditionally over committed by a factor like 10 in the FR core (that´s a lot more than your usual airline), because reservation wastes the benefits of statistical mux.

In a same fashion, all hops but even more the critical hop from/to the root must be optimized so as to effectively use the allocated unicast slots, so as to avoid idle listening and drain the battery. Using shared slots to absorb the bursts when thee is no control traffic looks like a good idea in rhat context.

If we take that path, the initial amount of shared slots is now tied to the capability to accept traffic bursts till more unicast slots are allocated to match the bursts.

What do you think?

Pascal

Le 14 févr. 2013 à 05:51, Kris Pister <[email-masked]> a écrit :

> yes, I think that we're in violent agreement.  Now we just need to find someone who disagrees with the Bari-Berkeley Alliance :)
> 
> ksjp
>

---

From: "Alfredo Grieco" <[email-masked]>
Date: Wed, 13 Feb 2013 19:08:36 +0100

Hi Qin, and all,

In this case, 6TSCH should translate QoS (in general, including bandwidth of
course) into Links (slot, channel) allocations.

Alfredo

-----Messaggio originale-----

Hi all,

(1) Explicit BW generation: upper layer, e.g. RSVP, generates BW requirement
and tell 6tsch, and then 6tsch reserves some Links to meet the BW
requirement.

How do you think?

Qin

---

From: Pascal Thubert <[email-masked]>
Date: Thu, 14 Feb 2013 15:24:22 +0100

Dear Kris;

I read this as "we have a RPL instance that is very basic and
autonomic, and that can be used as a backdoor to reach every node and
thus manage everything else" in a richer configuration, that is a
configuration with additional - constrained - instances. Do I have it
right?

This is the way I'd build any autonomic network - or at least this is
a constraint I'd impose on any network that builds itself, so as to
always have a way to get anywhere and fix it manually. And I'd agree
that since we can pass data on that instance, it can be enough for a
baseline, just like SMS already show that your network reaches out, or
a D-Channel can be used for data in ISDN.

For the richer configuration, we'd thus have to provide additional
instances, optimized for particular requirements, including eventually
a more reliable/optimized network control. A draft proposal of such
thing can be found in section 4.1.1.  RPL Instances of
draft-phinney-roll-rpl-industrial-applicability - look for "Management
Instance" till we fix the formatting

Cheers,

Pascal

2013/2/13 Kris Pister <[email-masked]>:
>>> (after).
> Alfredo - I agree.  I'd vote for the simplest possible specification at L2.
> DAG root picks a superframe length, schedules a single slotted-aloha link in
> that frame, and the network builds on that. For many applications this is
> all they need, but almost any network will benefit from optimization beyond
> this.
>

-- 
Pascal

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 14 Feb 2013 14:30:09 +0000

Alfredo, I agree with you.

The schedule should be built in order to fulfill the specific requirements of the considered application. The allocation of links within the slotframe will impact several performance metric. Thus, we should consider QoS metrics (e.g., latency, duty cyle, power consumption,  etc.)  rather than only bandwidth requirements.

Best,
Maria Rita

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alfredo Grieco [[email-masked]]
Sent: Wednesday, February 13, 2013 7:08 PM
To: [email-masked]; 'IETF 6TSCH'
Subject: [6tsch] R:  Bandwidth requirement, Explicit vs. Implicit

Hi Qin, and all,

Alfredo

-----Messaggio originale-----

Hi all,

How do you think?

Qin

---

From: Kris Pister <[email-masked]>
Date: Thu, 14 Feb 2013 16:16:46 -0800

Yes, we seem to be thinking about things the same way.
I may be a little less worried about source routes in the management 
instance than you seem to be in draft-phinney-*, but I have no problem 
with storing nodes either, so we'll just have to see how that plays out 
in practice.

ksjp