Subject: [6tsch] green light analogy

From: Pascal Thubert <[email-masked]>
Date: Fri, 1 Feb 2013 08:53:21 +0100

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