Subject: Re: [6tsch] green light analogy

From: Kris Pister <[email-masked]>
Date: Fri, 01 Feb 2013 09:38:23 -0800

4e supports multiple superframes.  Priority between superframes was out 
of scope for the IEEE.  There will be battles over how to structure 
priority (based on superframe ID, based on packet priority, TX before 
RX, etc.).  All approaches have some problems, but most of them are 
quite useful.

ksjp

On 1/31/2013 11:53 PM, Pascal Thubert wrote:
> Hi:
>
> For what it's worth,  I've been using the analogy of a city and 
> green/red lights to describe 6TSCH outside. Considering the city as a 
> system of green lights:
>
> 1) The minimum coordination happens between the lights of intersecting 
> streets. That minimum coordination is often the best can do but yields 
> a low (car) throughput on crowded avenues. As Robert indicated, it 
> seems to make sense that the coordinator is the RPL parent.
>
> 2) When main avenues are clearly identified, cities have found ways to 
> arrange the schedules of the green lights so that cars running at an 
> expected speed do not need to stop for a number of lights in a row. 
> RPL optimizes for P2MP / MP2P, so as to  while preserving a controlled 
> latency. For instance we may be able to organize sequences of time 
> slots to / from the root, with a concentration as we reach the root in 
> order to address statistical multiplexingy.
>
> 3) And then there are (exceptional) police and firemen cars that take 
> over regardless of what the allocation is. In that dynamic case 
> (analogous to alarms and alerts), the police cars and firemen trucks 
> will pass even if they do not have the green lights. It's not only 
> QoS, but also the fact that the next hop for that priority packet must 
> be listening at a given time slot that was not necessarily for him in 
> normal conditions. ISA100 can achieve something like that with 
> multiple prioritized superframes. What exactly can we do with 4e?
>
> 4) And then there are (very exceptional) official cars that will never 
> need to stop. Analogous to the scheduled world of command and control, 
> some external grand master will arrange in advance that a an official 
> convoy will get all the green lights along its path. In a mostly 
> distributed world the Path Computing Engine can hardly have visibility 
> on all the real (and probably quite dynamic) channel allocations. So 
> how can we handle this? Black list some slots and let the PCE have 
> full control on that limited number of slots? Let the PCE play blindly 
> and make room for what it has computed? Or simply use some RSVP like 
> technique whereby the PCE computes the path but does not see the 
> channels any better than RPL does? In that case a source-routed 
> reservation message could allocate channels on its way in a still 
> distributed fashion.
>
> Thoughts?
>
> -- 
> Pascal
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 1 Feb 2013 15:13:16 -0800

I delved back into the published 15.4e standard, and priority rules between
slot frames are written out (thanks Jonathan for pointing that out). For
the standard-savvy, below is the section.
Thomas

5.1.1.5.4 Multiple slotframes

A given network using timeslot-based access may contain several concurrent
slotframes of different sizes.
Multiple slotframes may be used to define a different communication
schedule for various groups of nodes
or to run the entire network at different duty cycles by giving some
devices many active timeslots in a
slotframe, and others few or none.

A network device may participate in one or more slotframes simultaneously,
and not all devices need to
participate in all slotframes. By configuring a network device to
participate in multiple overlapping
slotframes of different sizes, it is possible to establish different
communication schedules and connectivity
matrices that all work at the same time.

Slotframes can be added, removed, and modified while the network is
running. Even though this is the case,
all slotframes are aligned to timeslot boundaries, and timeslot 0 of the
first repetition of every slotframe is
projected back to macASN = 0, which is determined by the PAN coordinator
(or other network device that
starts the network). Because of this, timeslots in different slotframes are
always aligned, even though the
beginning and end of a particular repetition of that slotframe may not be
as illustrated in Figure 11d. *When,*
*for any given timeslot, a device has links in multiple slotframes,
transmissions take precedence over*
*receives, and lower slotframeHandle slotframes takes precedence over
higher slotframeHandle slotframes*

On Fri, Feb 1, 2013 at 9:38 AM, Kris Pister <[email-masked]>wrote:

> priority (based on superframe ID, based on packet priority, TX before RX,
> etc.).  All approaches have some problems, but most of them are quite
> useful.
>
> ksjp
>
>
> For what it's worth,  I've been using the analogy of a city and green/red
> lights to describe 6TSCH outside. Considering the city as a system of green
> lights:
>
> streets. That minimum coordination is often the best can do but yields a
> low (car) throughput on crowded avenues. As Robert indicated, it seems to
> make sense that the coordinator is the RPL parent.
>
> expected speed do not need to stop for a number of lights in a row. RPL
> optimizes for P2MP / MP2P, so as to  while preserving a controlled latency.
> For instance we may be able to organize sequences of time slots to / from
> the root, with a concentration as we reach the root in order to address
> statistical multiplexingy.
>
> 3) And then there are (exceptional) police and firemen cars that take over
> regardless of what the allocation is. In that dynamic case (analogous to
> alarms and alerts), the police cars and firemen trucks will pass even if
> they do not have the green lights. It's not only QoS, but also the fact
> that the next hop for that priority packet must be listening at a given
> time slot that was not necessarily for him in normal conditions. ISA100 can
> achieve something like that with multiple prioritized superframes. What
> exactly can we do with 4e?
>
> need to stop. Analogous to the scheduled world of command and control, some
> external grand master will arrange in advance that a an official convoy
> will get all the green lights along its path. In a mostly distributed world
> the Path Computing Engine can hardly have visibility on all the real (and
> probably quite dynamic) channel allocations. So how can we handle this?
> Black list some slots and let the PCE have full control on that limited
> number of slots? Let the PCE play blindly and make room for what it has
> computed? Or simply use some RSVP like technique whereby the PCE computes
> the path but does not see the channels any better than RPL does? In that
> case a source-routed reservation message could allocate channels on its way
> in a still distributed fashion.
>
> Thoughts?
>
> --
> Pascal
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Feb 2013 21:10:24 -0500

>>>>> "Pascal" == Pascal Thubert <[email-masked]> writes:
    Pascal> For what it's worth, I've been using the analogy of a city
    Pascal> and green/red lights to describe 6TSCH outside. Considering
    Pascal> the city as a system of green lights:

    Pascal> 1) The minimum coordination happens between the lights of
    Pascal> intersecting streets. That minimum coordination is often the
    Pascal> best can do but yields a low (car) throughput on crowded
    Pascal> avenues. As Robert indicated, it seems to make sense that
    Pascal> the coordinator is the RPL parent.

It's a good analogy.

However, I think that we are looking for something more.
Given knowledge of the light cycles, one can often determine that using
the main boulevard is not always the best route at a a given time.

    Pascal> 2) When main avenues are clearly identified, cities have
    Pascal> found ways to arrange the schedules of the green lights so
    Pascal> that cars running at an expected speed do not need to stop
    Pascal> for a number of lights in a row. RPL optimizes for P2MP /

Yes, most particularly, they can organize running greens in one
direction only.  Some cities (mine for instance), in order to increase
capacity (bandwidth), have arranged alternating streets to flow in
opposite directions, with running green lights along each.  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Pascal Thubert <[email-masked]>
Date: Tue, 5 Feb 2013 10:47:09 +0100

Hello Michael:

Pascal

2013/2/5 Michael Richardson <[email-masked]>

> opposite directions, with running green lights along each.

They augment the capacity because start and stop is a slow process.
packets have less inertia, but what we probably care more for jitter and
then latency than throughput

Cheers,

Pascal

---

From: Robert Assimiti <[email-masked]>
Date: Wed, 6 Feb 2013 18:54:04 -0500

Pascal,

Excellent analogy. Support for prioritized data flows in crucial for the proper operation of the WLAN (for both inbound and outbound traffic). The only building blocks that currently come close to supporting prioritized media access is the differentiation between shared and dedicated (TX or RX) links.

Prioritized media access was one of the hot topics when 802.15.4e was drafted. Several ways of supporting prioritized traffic flows were discussed. These include prioritized slotframes, prioritized timeslots (guaranteed slots that are associated with a priority level) and even prioritized links. Several comments were submitted that requested MAC support for prioritized traffic flows and implicitly prioritized media access. Unfortunately the comments were not addressed.

But what we could do is augment the existing TSCH PIB attributes with a priority field, or create new TSCH PIB attributes that also include a priority field.

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert
Sent: Friday, February 01, 2013 2:53 AM
To: IETF 6TSCH
Subject: [6tsch] green light analogy

Hi:

For what it's worth,  I've been using the analogy of a city and green/red lights to describe 6TSCH outside. Considering the city as a system of green lights:

1) The minimum coordination happens between the lights of intersecting streets. That minimum coordination is often the best can do but yields a low (car) throughput on crowded avenues. As Robert indicated, it seems to make sense that the coordinator is the RPL parent.

2) When main avenues are clearly identified, cities have found ways to arrange the schedules of the green lights so that cars running at an expected speed do not need to stop for a number of lights in a row. RPL optimizes for P2MP / MP2P, so as to  while preserving a controlled latency. For instance we may be able to organize sequences of time slots to / from the root, with a concentration as we reach the root in order to address statistical multiplexingy.

3) And then there are (exceptional) police and firemen cars that take over regardless of what the allocation is. In that dynamic case (analogous to alarms and alerts), the police cars and firemen trucks will pass even if they do not have the green lights. It's not only QoS, but also the fact that the next hop for that priority packet must be listening at a given time slot that was not necessarily for him in normal conditions. ISA100 can achieve something like that with multiple prioritized superframes. What exactly can we do with 4e?

4) And then there are (very exceptional) official cars that will never need to stop. Analogous to the scheduled world of command and control, some external grand master will arrange in advance that a an official convoy will get all the green lights along its path. In a mostly distributed world the Path Computing Engine can hardly have visibility on all the real (and probably quite dynamic) channel allocations. So how can we handle this? Black list some slots and let the PCE have full control on that limited number of slots? Let the PCE play blindly and make room for what it has computed? Or simply use some RSVP like technique whereby the PCE computes the path but does not see the channels any better than RPL does? In that case a source-routed reservation message could allocate channels on its way in a still distributed fashion.

Thoughts?

--
Pascal