[6tsch] priority and priority

[Thomas Watteyne <[e-mail]>]

All,

I believe that we have been discussing two different notions of priority:
- *Packet Priority*: Assuming an existing data flow in a network, some
packets are marked as "high priority", the rest as "low priority". All
packets are part of the same flow, but high priority packets are treated
with more urgency that low priority packets. This translates into a set
of queuing rules. This is the notion illustrated by Pascal in his "traffic
lights in a city" analogy (where high priority packets are police cars
passing other vehicles) and used in Qin's mux/i-mux.
- *Flow Priority*, which is slightly different. In a network, multiple
classes of traffic co-exist. This results in multiple data flows. Different
data flows have a different combination of destination, priority, bandwidth
and latency. A network-wide policy defines whether data flows are entirely
independent, or if some over-flowing is allowed. In TSCH, a flow translated
into a slotframe. In case of contention (e.g. at a given slot a mote can
send a packet from each flow), flow priority arbitrates which packet goes
first. Note that this is entirely within the TSCH spec.

These two definitions are complementary: different flows can exist in a
network, but inside a flow, some high priority packets can "pass" other
packets. The network policy defines how those two interact; e.g. a
highest-priority packet can be allowed to "jump" into another flow, if
needed.

We need to define how this materializes in a network. Here is a proposal:

Each data flow turns into a TSCH slotframe. The scheduling entity populates
the slots in the slotframe in such as way that the slots "point to" some
destination. In a typical case, slots in a slotframe are equivalent: to end
up at mote A, take any slot in slotframe 1. This allows us to use
label-switching approach, which I'm sure will pop up in some future draft.
We can end up with different slotframes for different destinations, or for
different types of traffic to the same destination.

Optionally, packets can contain some priority field (probably DSCP, as per
http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-00?)
which serves as the "high priority" marker. A policy then regulates how
this translates to queuing and flow equivalence rules.

DSCP can also be used by the higher layer to indicate to which flow this
packet pertains, and with what (optional) priority. Upon receiving a packet
from a higher layer, the 6tsch layer could inspect the DSCP and some set of
rules would tell him which flow to send it on. Once it is in a flow, the
full DSCP is not needed, and there is lots of opportunity to elide some
information while the packet is on the LLN. I'm hoping that Shitanshu a.o.
can help decide on the applicability of this.

Thomas