Subject: [6tsch] On exploiting time synchronisation and deadlines in 6tus

From: Grieco <[email-masked]>
Date: Fri, 24 May 2013 18:00:47 +0200

Hi all,

During the today call, it emerged the possibility to stamp packets with deadlines to be updated during their trips thanks to the unique feature offered by TSCH to have a tightly synchronized LLN.

In this way, it could be possible to control the trip of each packet while it proceed towards the destination. In some hard real time applications, a packet that passes the deadline could be discarded thus saving energy.

It is true that we are installing tracks that should remain stable for a long time, but it is also true that wireless links (in any case) can come and go also for short transients.

Any thoughts about this point is warmly welcome and could lead to improvements to the 6tus layer.

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

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 May 2013 19:10:47 -0700

Alfredo,

This is indeed a neat idea, which feeds upon a nice feature of our little
TSCH networks.

IIRC, the points that were raised during the call around this issue were:
pros:
- we could throttle a packet's priority based on the remaining lifetime it
has.
- we could drop a packet that has already expired
cons:
- reserving extra bytes for this TS will add an extra energy cost, and in
some cases might simply not be possible

Did I miss something?

Thomas

On Fri, May 24, 2013 at 9:00 AM, Grieco <[email-masked]> wrote:

> Hi all,
>
> During the today call, it emerged the possibility to stamp packets with
> deadlines to be updated during their trips thanks to the unique feature
> offered by TSCH to have a tightly synchronized LLN.
>
> In this way, it could be possible to control the trip of each packet while
> it proceed towards the destination. In some hard real time applications, a
> packet that passes the deadline could be discarded thus saving energy.
>
> It is true that we are installing tracks that should remain stable for a
> long time, but it is also true that wireless links (in any case) can come
> and go also for short transients.
>
> _______________________________________________
> 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: Fri, 24 May 2013 19:39:16 -0700

My little point on that. I like the idea of "not" having a header if we 
do switching, i.e not having a header makes things so simple and it 
becomes a very transparent mechanism, no parsing, no processing at each 
hop, just in and out until it reaches the end of the label switched track.

I agree that having these feature would be also good, however this might 
require looking the header at each hop, so there is a trade-off between 
energy consumption, need for that and simplicity. We need to keep this 
in mind too, maybe an optional feature would work?

X

Al 24/05/13 19:10, En/na Thomas Watteyne ha escrit:
> Alfredo,
>
> This is indeed a neat idea, which feeds upon a nice feature of our 
> little TSCH networks.
>
> - we could throttle a packet's priority based on the remaining 
> lifetime it has.
> - reserving extra bytes for this TS will add an extra energy cost, and 
> in some cases might simply not be possible
>
> Did I miss something?
>
> Thomas
>
>
>
> On Fri, May 24, 2013 at 9:00 AM, Grieco <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     During the today call, it emerged the possibility to stamp packets
>     with deadlines to be updated during their trips thanks to the
>     unique feature offered by TSCH to have a tightly synchronized LLN.
>
>     In this way, it could be possible to control the trip of each
>     packet while it proceed towards the destination. In some hard real
>     time applications, a packet that passes the deadline could be
>     discarded thus saving energy.
>
>     It is true that we are installing tracks that should remain stable
>     for a long time, but it is also true that wireless links (in any
>     case) can come and go also for short transients.
>
>     +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>     telematics.poliba.it/grieco <http://telematics.poliba.it/grieco>
>     Mobile: +39 3346715672 <tel:%2B39%203346715672>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Pascal Thubert <[email-masked]>
Date: Sat, 25 May 2013 07:35:43 +0200

Same here,

I think the info could indeed be very useful on shared slots but along a dedicated track there is no choice but continue along schedule...

Cheers,

Pascal

Le 25 mai 2013 à 04:39, Xavier Vilajosana <[email-masked]> a écrit :

> 
> My little point on that. I like the idea of "not" having a header if we do switching, i.e not having a header makes things so simple and it becomes a very transparent mechanism, no parsing, no processing at each hop, just in and out until it reaches the end of the label switched track.
> 
> I agree that having these feature would be also good, however this might require looking the header at each hop, so there is a trade-off between energy consumption, need for that and simplicity. We need to keep this in mind too, maybe an optional feature would work?
> 
> X
> 
>> This is indeed a neat idea, which feeds upon a nice feature of our little TSCH networks.
>> 
>> - we could throttle a packet's priority based on the remaining lifetime it has.
>> - reserving extra bytes for this TS will add an extra energy cost, and in some cases might simply not be possible
>> 
>> Did I miss something?
>> 
>> Thomas
>> 
>> 
>>

---

From: Grieco <[email-masked]>
Date: Sat, 25 May 2013 09:34:05 +0200

Hi all, (and Pascal, Thomas, Xavier)

I agree that this feature could be more useful on shared slots.

At the same time, it does not require extra bits if we look at the entire stack. I think that at the application layer timestamps are needed in industrial applications to allow the sink to temporally align the signals coming from different lln nodes. This timestamp could be moved from the application layer to the 6tus layer, thus solving the problem of extra bits.

Of course, looking at this timestamp at each hop would inflate energy consumptions.

We could propose it as an optional feature to be used when the context we are facing requires it.

 If you need I could help describing this feature in one section or subsection of the 6tus draft.

Cheers

Alfredo

---

From: Tom Phinney <[email-masked]>
Date: Sat, 25 May 2013 09:57:02 -0700

Higher-layer data can be examined when it and any intervening-layer
headers are present in the lower-layer fragment that is being
forwarded. In my opinion it is always possible to descrive such
examiniation in a way that honors the compartmentalization and
informtion-hiding principles of layering.

However, the desired information may not always be present for
examination. This is particularly likely with such low-byte-count
fragments as are conveyable by IEEE 802.15.4. On the other hand, the
timestamp that is being discussed in the e-mail exchange quoted
below is information that is required within the communication
layers for cryptographic nonces and for replay rejection. Hence it
will be in the transport layer header (e.g., ISA100.11a) or below
(e.g., WirelessHART), so may well lie within most initial fragments.

Note that such timestamps are based on origination time of the
messaging, or perhaps the slightly-earlier measurement time of the
conveyed measurement. Thus they do not provide direct information on
delivery deadlines. Also note that such deadlines are not
necessarily hard, and that historians may be interested in delivery
of information even after expiration of a hard deadline for use of
the information in closed-loop control, or when the conveyed
information has been superseded by a later sample in a monitoring
application.

So, in summary,

- 1) It may be possible to extract a source timestamp from a
higher-layer header within the intiial fragment of a conveyed
message, but probably not if the conveyed bytes are not the initial
fragment.

- 2) It may be possible to annotate the label-switching information
in a node (mote), for a given track that is used for a flow that has
hard deadlines, so that individual deadlines can be computed
relative to any timestamp in the conveyed PDU. When such information
is lacking, no discard is possible.

- 3) It may be possible to use a lookaside cache in the forwarding
node (mote) to correlate successor fragments with the fragments to
which 2) applies, thereby enabling discard of the successor
fragments of the same higher-layer PDU when the one containing the
timestamp was earlier discarded. In all other cases of a fragment
not containing a timetamp, no deadline-based discard is possible.

-Tom

====

I agree that this feature could be more useful on shared
slots.

At the same time, it does not require extra bits if we look
at the entire stack. I think that at the application layer
timestamps are needed in industrial applications to allow the
sink to temporally align the signals coming from different lln
nodes. This timestamp could be moved from the application layer
to the 6tus layer, thus solving the problem of extra bits.

Of course, looking at this timestamp at each hop would
inflate energy consumptions.

We could propose it as an optional feature to be used when
the context we are facing requires it.

If you need I could help describing this feature in one
section or subsection of the 6tus draft.

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

Skype
id: l.alfredo.grieco

Mobile:
+39 3346715672

On 25 May 2013, at 07:35, Pascal Thubert <[email-masked]>
wrote:

Same here,

I think the info could indeed be very useful on shared
slots but along a dedicated track there is no choice but
continue along schedule...

Cheers,

Pascal

Le 25 mai 2013 à 04:39, Xavier Vilajosana <[email-masked]>
a écrit :

My little point on that. I like the idea of "not" having
a header if we do switching, i.e not having a header
makes things so simple and it becomes a very transparent
mechanism, no parsing, no processing at each hop, just
in and out until it reaches the end of the label
switched track.

I agree that having these feature would be also good,
however this might require looking the header at each
hop, so there is a trade-off between energy consumption,
need for that and simplicity. We need to keep this in
mind too, maybe an optional feature would work?

X

Alfredo,

This is indeed a neat idea, which feeds upon a
nice feature of our little TSCH networks.

IIRC, the points that were raised during the call
around this issue were:

pros:

- we could throttle a packet's priority based on
the remaining lifetime it has.

cons:

- reserving extra bytes for this TS will add an
extra energy cost, and in some cases might simply
not be possible

Did I miss something?

Thomas

On Fri, May 24, 2013 at
9:00 AM, Grieco <[email-masked]>
wrote:

Hi all,

During the today call, it emerged the
possibility to stamp packets with deadlines
to be updated during their trips thanks to
the unique feature offered by TSCH to have a
tightly synchronized LLN.

In this way, it could be possible to
control the trip of each packet while it
proceed towards the destination. In some
hard real time applications, a packet that
passes the deadline could be discarded thus
saving energy.

It is true that we are installing tracks
that should remain stable for a long time,
but it is also true that wireless links (in
any case) can come and go also for short
transients.

Any thoughts about this point is warmly
welcome and could lead to improvements to
the 6tus layer.

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

Skype id:
l.alfredo.grieco

Mobile: +39

3346715672

6tsch mailing list

[email-masked]

6tsch mailing list

[email-masked]

6tsch mailing list

[email-masked]

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 28 May 2013 10:08:43 +0000

Pascal, I do agree with you and  Xavi about keeping things as simple as possible…

But about the dedicated track, I have a different thought. Knowing that the timelife of a packet is expired can be STILL useful along a dedicated track. In fact, we can discard the packet instead of keeping in forwarding it along the successive cells of the track, thus saving energy.

Of course, it is even more useful in shared cells, because in presence of collision, we will avoid to re-transmit expired packets,  giving to those with TTL >0 more chance to be transmitted with success.
In this way, we save energy and also reduce latency-delay.

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert
Sent: Saturday, May 25, 2013 7:36 AM
To: Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus

Same here,

Cheers,

Pascal

Le 25 mai 2013 à 04:39, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> a écrit :

X

Did I miss something?

Thomas

On Fri, May 24, 2013 at 9:00 AM, Grieco <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

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<tel:%2B39%20080%205963%20911>
telematics.poliba.it/grieco<http://telematics.poliba.it/grieco>
Skype id: l.alfredo.grieco
Mobile: +39 3346715672<tel:%2B39%203346715672>

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

6tsch mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 28 May 2013 06:48:48 -0700

Hi Maria Rita,

I agree that the feature is really interesting and might be very useful 
in some cases, specially for time sensitive applications, however, 
including a header will require the parsing at each hop which would be 
very convenient to avoid. As I said, I vote for having this feature as 
an optional header and in case we define more options that we consider 
important then we can discuss if a permanent header is needed.

Note also that when label switching is not used the Hop Limit field is 
used to count the number of hops and detect loops, however in that case 
there is no timestamp to discard expired packets. I'm wondering if we 
want to add that information despite of having label switching at L2.5 
or not.

regards,
Xavi

Al 28/05/13 03:08, En/na Maria Rita PALATTELLA ha escrit:
> But about the dedicated track, I have a different thought. Knowing 
> that the timelife of a packet is expired can be STILL useful along a 
> dedicated track. In fact, we can discard the packet instead of keeping 
> in forwarding it along the successive cells of the track, thus saving 
> energy.
>
> Of course, it is even more useful in shared cells, because in presence 
> of collision, we will avoid to re-transmit expired packets,  giving to 
> those with TTL >0 more chance to be transmitted with success.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Pascal Thubert
> *Sent:* Saturday, May 25, 2013 7:36 AM
> *To:* Xavier Vilajosana
> *Cc:* [email-masked]
> *Subject:* Re: [6tsch] On exploiting time synchronisation and 
> deadlines in 6tus
>
> Same here,
>
> I think the info could indeed be very useful on shared slots but along 
> a dedicated track there is no choice but continue along schedule...
>
> Cheers,
>
> Pascal
>
>
> Le 25 mai 2013 à 04:39, Xavier Vilajosana 
> <[email-masked] <mailto:[email-masked]>> 
> a écrit :
>
>
>     My little point on that. I like the idea of "not" having a header
>     if we do switching, i.e not having a header makes things so simple
>     and it becomes a very transparent mechanism, no parsing, no
>     processing at each hop, just in and out until it reaches the end
>     of the label switched track.
>
>     I agree that having these feature would be also good, however this
>     might require looking the header at each hop, so there is a
>     trade-off between energy consumption, need for that and
>     simplicity. We need to keep this in mind too, maybe an optional
>     feature would work?
>
>     X
>
>         - reserving extra bytes for this TS will add an extra energy
>         cost, and in some cases might simply not be possible
>
>         Did I miss something?
>
>         Thomas
>
>         On Fri, May 24, 2013 at 9:00 AM, Grieco
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>         Hi all,
>
>         During the today call, it emerged the possibility to stamp
>         packets with deadlines to be updated during their trips thanks
>         to the unique feature offered by TSCH to have a tightly
>         synchronized LLN.
>
>         packet while it proceed towards the destination. In some hard
>         real time applications, a packet that passes the deadline
>         could be discarded thus saving energy.
>
>         It is true that we are installing tracks that should remain
>         stable for a long time, but it is also true that wireless
>         links (in any case) can come and go also for short transients.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2013 16:20:43 +0000

Dear all:

A track has an exact schedule, so we know how long since the emission at every hop.
OTOH, in the case of best effort forwarding, knowing the age of a packet and how that sit within a desired schedule can become very interesting.

Do I miss something?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 28 mai 2013 15:49
To: Maria Rita PALATTELLA
Cc: Pascal Thubert; [email-masked]
Subject: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus

Hi Maria Rita,

I agree that the feature is really interesting and might be very useful in some cases, specially for time sensitive applications, however, including a header will require the parsing at each hop which would be very convenient to avoid. As I said, I vote for having this feature as an optional header and in case we define more options that we consider important then we can discuss if a permanent header is needed.

Note also that when label switching is not used the Hop Limit field is used to count the number of hops and detect loops, however in that case there is no timestamp to discard expired packets. I'm wondering if we want to add that information despite of having label switching at L2.5 or not.

regards,
Xavi

Maria Rita

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Pascal Thubert
Sent: Saturday, May 25, 2013 7:36 AM
To: Xavier Vilajosana
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus

Same here,

Cheers,

Pascal

X

Did I miss something?

Thomas

Cheers

Alfredo

6tsch mailing list

---

From: "Alfredo Grieco" <[email-masked]>
Date: Tue, 28 May 2013 18:35:24 +0200

Dear all, Pascal,
 
I am glad everybody consider this proposal interesting and is providing very precious comments.
 
A track has an exact schedule: I am ok, but let’s consider the case a scheduled cell is faulty and the packet that cannot be transmitted on that cell has to be delivered using (let’s say) a best effort service towards the sink.
 
This is a hybrid condition (the faulty cell can be referred to a mote in the middle of the path) that could happen in reality and for which knowing the age of the packet is important too.
 
Am I missing something ?
 
Cheers
 
Alfredo

Da: [email-masked] [mailto:[email-masked]] Per conto di Pascal Thubert (pthubert)
Inviato: Tuesday, May 28, 2013 6:21 PM
A: Xavier Vilajosana; Maria Rita PALATTELLA
Cc: Pascal Thubert; [email-masked]
Oggetto: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus
 
Dear all:

Do I miss something?
 
Pascal

Hi Maria Rita, 

regards,
Xavi

 
 
Maria Rita

Same here,

Cheers,

Pascal

X

 
 
Did I miss something?
 
Thomas

 

Cheers
 
Alfredo

---

From: Kris Pister <[email-masked]>
Date: Tue, 28 May 2013 10:01:35 -0700

Alfredo brings up an important point.  Latency along a track is only 
known if the PDR for all links is 100%.  In reality, it's a Poisson 
distribution that depends on the schedule&PDR at each hop.

ksjp

On 5/28/2013 9:35 AM, Alfredo Grieco wrote:
> A track has an exact schedule: I am ok, but let's consider the case a 
> scheduled cell is faulty and the packet that cannot be transmitted on 
> that cell has to be delivered using (let's say) a best effort service 
> towards the sink.
>
> This is a hybrid condition (the faulty cell can be referred to a mote 
> in the middle of the path) that could happen in reality and for which 
> knowing the age of the packet is important too.
>
> Am I missing something ?
>
> Cheers
>
> Alfredo
>
> *Da**:[email-masked] [mailto:[email-masked]] *Per 
> conto di *Pascal Thubert (pthubert)
> *Inviato**:* Tuesday, May 28, 2013 6:21 PM
> *A:* Xavier Vilajosana; Maria Rita PALATTELLA
> *Cc:* Pascal Thubert; [email-masked]
> *Oggetto**:* Re: [6tsch] On exploiting time synchronisation and 
> deadlines in 6tus
>
> Dear all:
>
> OTOH, in the case of best effort forwarding, knowing the age of a 
> packet and how that sit within a desired schedule can become very 
> interesting.
>
> Do I miss something?
>
> Pascal
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Xavier Vilajosana
> *Sent:* mardi 28 mai 2013 15:49
> *To:* Maria Rita PALATTELLA
> *Cc:* Pascal Thubert; [email-masked] <mailto:[email-masked]>
> I agree that the feature is really interesting and might be very 
> useful in some cases, specially for time sensitive applications, 
> however, including a header will require the parsing at each hop which 
> would be very convenient to avoid. As I said, I vote for having this 
> feature as an optional header and in case we define more options that 
> we consider important then we can discuss if a permanent header is 
> needed.
>
> used to count the number of hops and detect loops, however in that 
> case there is no timestamp to discard expired packets. I'm wondering 
> if we want to add that information despite of having label switching 
> at L2.5 or not.
>
> regards,
> Xavi
>
>     Pascal, I do agree with you and  Xavi about keeping things as
>     simple as possible...
>
>     that the timelife of a packet is expired can be STILL useful along
>     a dedicated track. In fact, we can discard the packet instead of
>     keeping in forwarding it along the successive cells of the track,
>     thus saving energy.
>
>     Of course, it is even more useful in shared cells, because in
>     presence of collision, we will avoid to re-transmit expired
>     packets,  giving to those with TTL >0 more chance to be
>     transmitted with success.
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Pascal Thubert
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     I think the info could indeed be very useful on shared slots but
>     along a dedicated track there is no choice but continue along
>     schedule...
>
>     Cheers,
>
>     Pascal
>
>
>     <[email-masked]
>     <mailto:[email-masked]>> a écrit :
>
>
>         My little point on that. I like the idea of "not" having a
>         header if we do switching, i.e not having a header makes
>         things so simple and it becomes a very transparent mechanism,
>         no parsing, no processing at each hop, just in and out until
>         it reaches the end of the label switched track.
>
>         I agree that having these feature would be also good, however
>         this might require looking the header at each hop, so there is
>         a trade-off between energy consumption, need for that and
>         simplicity. We need to keep this in mind too, maybe an
>         optional feature would work?
>
>         X
>
>             - reserving extra bytes for this TS will add an extra
>             energy cost, and in some cases might simply not be possible
>
>             Did I miss something?
>
>             Thomas
>
>             <[email-masked]
>             packets with deadlines to be updated during their trips
>             thanks to the unique feature offered by TSCH to have a
>             In this way, it could be possible to control the trip of
>             each packet while it proceed towards the destination. In
>             some hard real time applications, a packet that passes the
>             deadline could be discarded thus saving energy.
>
>             It is true that we are installing tracks that should
>             remain stable for a long time, but it is also true that
>             wireless links (in any case) can come and go also for
>             short transients.
>
>             <http://telematics.poliba.it/grieco>
>

---

From: Kris Pister <[email-masked]>
Date: Tue, 28 May 2013 10:07:42 -0700

It seems to me that this is an important feature for some class of 
applications, but that it has nothing directly to do with the 4E MAC 
layer.  There are many ways to provide time synchronization in a 
multi-hop network, and many ways to track the total wall-clock time that 
a packet has been in transit.

So...shouldn't the deadline information be in an IPv6 hop-by-hop option 
header?

ksjp

On 5/28/2013 6:48 AM, Xavier Vilajosana wrote:
>> Pascal, I do agree with you and  Xavi about keeping things as simple 
>> as possible...
>>
>> dedicated track. In fact, we can discard the packet instead of 
>> presence of collision, we will avoid to re-transmit expired packets, 
>>  giving to those with TTL >0 more chance to be transmitted with success.
>>
>> along a dedicated track there is no choice but continue along schedule...
>>
>> Cheers,
>>
>> Pascal
>>
>>
>>     if we do switching, i.e not having a header makes things so
>>     simple and it becomes a very transparent mechanism, no parsing,
>>     no processing at each hop, just in and out until it reaches the
>>     end of the label switched track.
>>
>>     this might require looking the header at each hop, so there is a

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 28 May 2013 10:43:02 -0700

Hi Kris,

the thing is that we want to skip going up to L3 when using forwarding 
based on labels, so L3 header is not parsed at each hop. Alfredo 
suggestion was to use a little "header" including a timestamp so we can 
discard packets in case their deadline cannot be meet. This will happen 
at L2.5 and i.e inside the "tunnel".

An alternative is to use L3 option header but then the packet will be 
discarded outside of the "tunnel" maybe having hop more than needed.

X

Al 28/05/13 10:07, En/na Kris Pister ha escrit:
> multi-hop network, and many ways to track the total wall-clock time 
> that a packet has been in transit.
>
> So...shouldn't the deadline information be in an IPv6 hop-by-hop 
> option header?
>
> ksjp
>
>> however, including a header will require the parsing at each hop 
>> which would be very convenient to avoid. As I said, I vote for having 
>> this feature as an optional header and in case we define more options 
>> that we consider important then we can discuss if a permanent header 
>> is needed.
>>
>> Note also that when label switching is not used the Hop Limit field 
>> is used to count the number of hops and detect loops, however in that 
>>>     header if we do switching, i.e not having a header makes things
>>>     so simple and it becomes a very transparent mechanism, no
>>>     parsing, no processing at each hop, just in and out until it
>>>     reaches the end of the label switched track.
>>>

---

From: Kris Pister <[email-masked]>
Date: Tue, 28 May 2013 12:51:34 -0700

Interesting.  So we're proposing to ignore all hop-by-hop options?
Do MPLS routers/switches ignore hop-by-hop options when they encounter a 
level 2.5 label?

ksjp

On 5/28/2013 10:43 AM, Xavier Vilajosana wrote:
> suggestion was to use a little "header" including a timestamp so we 
> can discard packets in case their deadline cannot be meet. This will 
> happen at L2.5 and i.e inside the "tunnel".
>
>>> which would be very convenient to avoid. As I said, I vote for 
>>> having this feature as an optional header and in case we define more 
>>> options that we consider important then we can discuss if a 
>>> permanent header is needed.
>>>
>>> is used to count the number of hops and detect loops, however in 
>>> that case there is no timestamp to discard expired packets. I'm 
>>> wondering if we want to add that information despite of having label 
>>> switching at L2.5 or not.
>>>
>>> regards,
>>> Xavi
>>>
>>>> packets,  giving to those with TTL >0 more chance to be transmitted 
>>>> with success.
>>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 28 May 2013 13:05:35 -0700

great question... not sure.. but I think so, from L3 point of view, a 
pkt crossing a tunnel is the same as crossing 1 hop at L3. Internally 
might be crossing several hops but from L3 we cannot see it so the hop 
by hop header would only apply to the hop as seen at L3 (even if 
internally there are multiple hops).

I will check RFCs for MPLS/GMPLS to see if there is some information 
about that.
X

Al 28/05/13 12:51, En/na Kris Pister ha escrit:
> Do MPLS routers/switches ignore hop-by-hop options when they encounter 
> a level 2.5 label?
>
> ksjp
>
>> the thing is that we want to skip going up to L3 when using 
>> forwarding based on labels, so L3 header is not parsed at each hop. 
>> Alfredo suggestion was to use a little "header" including a timestamp 
>> so we can discard packets in case their deadline cannot be meet. This 
>> will happen at L2.5 and i.e inside the "tunnel".
>>
>>>> having this feature as an optional header and in case we define 
>>>> more options that we consider important then we can discuss if a 
>>>> wondering if we want to add that information despite of having 
>>>> label switching at L2.5 or not.
>>>>
>>>> regards,
>>>> Xavi
>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 29 May 2013 22:49:37 -0700

I looks like we have encountered 2 instances where an explicit L2.5 label
could be used: hlim and ttl. I'd hate to have the purely G-MPLS mode go
away, so I propose that, if we add in this header, we make it optional.

If we do, one can imagine having packets flow along a track with and
without this header. Xavi, do you have some ideas about how we could
distinguish those two?

Thomas

On Tue, May 28, 2013 at 1:05 PM, Xavier Vilajosana <
[email-masked]> wrote:

> pkt crossing a tunnel is the same as crossing 1 hop at L3. Internally might
> be crossing several hops but from L3 we cannot see it so the hop by hop
> header would only apply to the hop as seen at L3 (even if internally there
> are multiple hops).
>
> I will check RFCs for MPLS/GMPLS to see if there is some information about
> that.
> X
>
>
> based on labels, so L3 header is not parsed at each hop. Alfredo suggestion
> was to use a little "header" including a timestamp so we can discard
> packets in case their deadline cannot be meet. This will happen at L2.5 and
> i.e inside the "tunnel".
>
> layer.  There are many ways to provide time synchronization in a multi-hop
> network, and many ways to track the total wall-clock time that a packet has
> been in transit.
>
> I agree that the feature is really interesting and might be very useful in
> some cases, specially for time sensitive applications, however, including a
> header will require the parsing at each hop which would be very convenient
> to avoid. As I said, I vote for having this feature as an optional header
> and in case we define more options that we consider important then we can
> discuss if a permanent header is needed.
>
> there is no timestamp to discard expired packets. I'm wondering if we want
> to add that information despite of having label switching at L2.5 or not.
>
> regards,
> Xavi
>
>  Pascal, I do agree with you and  Xavi about keeping things as simple as
> possible…****
>
> ** **
>
> But about the dedicated track, I have a different thought. Knowing that
> the timelife of a packet is expired can be STILL useful along a dedicated
> track. In fact, we can discard the packet instead of keeping in forwarding
> it along the successive cells of the track, thus saving energy.****
>
> ** **
>
> Of course, it is even more useful in shared cells, because in presence of
> collision, we will avoid to re-transmit expired packets,  giving to those
> with TTL >0 more chance to be transmitted with success.****
>
> In this way, we save energy and also reduce latency-delay.****
>
> ** **
>
> Maria Rita****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Pascal Thubert
> *Subject:* Re: [6tsch] On exploiting time synchronisation and deadlines
> in 6tus****
>
> ** **
>
> Same here,****
>
> ** **
>
> I think the info could indeed be very useful on shared slots but along a
> dedicated track there is no choice but continue along schedule...****
>
> ** **
>
> Cheers,
>
> Pascal****
>
>
> a écrit :****
> My little point on that. I like the idea of "not" having a header if we do
> switching, i.e not having a header makes things so simple and it becomes a
> very transparent mechanism, no parsing, no processing at each hop, just in
> and out until it reaches the end of the label switched track.
>
> energy consumption, need for that and simplicity. We need to keep this in
> Al 24/05/13 19:10, En/na Thomas Watteyne ha escrit:****
>
>  Alfredo, ****
>
> ** **
>
> TSCH networks.****
> ** **
> IIRC, the points that were raised during the call around this issue were:*
> ***
>
> pros:****
>
> has.****
> - we could drop a packet that has already expired****
>
> cons:****
>
> some cases might simply not be possible****
>
> ** **
>
> Did I miss something?****
>
> ** **
>
> Thomas****
>
> ** **
>
> ** **
>
> On Fri, May 24, 2013 at 9:00 AM, Grieco <[email-masked]> wrote:*
> ***
>
> Hi all,****
>
> ** **
>
> offered by TSCH to have a tightly synchronized LLN.****
>
> ** **
>
> packet that passes the deadline could be discarded thus saving energy.****
>
> ** **
>
> and go also for short transients.****
>
> ** **
>
> Any thoughts about this point is warmly welcome and could lead to
> improvements to the 6tus layer.****
>
> ** **
>
> ** **
>
> 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 <%2B39%20080%205963%20911>****
>
> telematics.poliba.it/grieco****
>
> Skype id: l.alfredo.grieco****
>
> Mobile: +39 3346715672****
>
> ** **
>
>
> 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****
>
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 30 May 2013 16:48:10 -0700

inline

> I looks like we have encountered 2 instances where an explicit L2.5 
> label could be used: hlim and ttl. I'd hate to have the purely G-MPLS 
> mode go away, so I propose that, if we add in this header, we make it 
> optional.
>

That's not easy as we don't have any means to tell L2.5 to look at the 
header or just forward the packet. In upper layers we have the next 
header field that helps us to see what's the next layer and hence notify 
the right component. The only option that comes to my mind is to use 
some flag at L2 header (if there is any available -- reserved) and see 
if  header-less Label Switching is enabled or not. If it is not enabled 
then parse the header which might be IPHC and then this packet is not 
being label switched, if it is the optional header then check if the 
packet has to be discarded according to the ttl.

My vote is still to try it without any header, as simple as possible, 
note that this networks use to have very regular traffic so delays might 
be closely related to bad links which the PCE might try to minimize. So 
maybe the mechanism actuate for a little, discarding a packet too old, 
but the PCE will be trying to solve that too so I am not sure if in 
overall there is a big advantage.

X
> Thomas
>
> On Tue, May 28, 2013 at 1:05 PM, Xavier Vilajosana 
>     great question... not sure.. but I think so, from L3 point of
>     view, a pkt crossing a tunnel is the same as crossing 1 hop at L3.
>     Internally might be crossing several hops but from L3 we cannot
>     see it so the hop by hop header would only apply to the hop as
>     seen at L3 (even if internally there are multiple hops).
>
>     I will check RFCs for MPLS/GMPLS to see if there is some
>     information about that.
>     X
>
>
>>     Do MPLS routers/switches ignore hop-by-hop options when they
>>     encounter a level 2.5 label?
>>
>>     ksjp
>>
>>>     forwarding based on labels, so L3 header is not parsed at each
>>>     hop. Alfredo suggestion was to use a little "header" including a
>>>     timestamp so we can discard packets in case their deadline
>>>     cannot be meet. This will happen at L2.5 and i.e inside the
>>>     "tunnel".
>>>
>>>     An alternative is to use L3 option header but then the packet
>>>     will be discarded outside of the "tunnel" maybe having hop more
>>>     than needed.
>>>
>>>     X
>>>
>>>>     It seems to me that this is an important feature for some class
>>>>     of applications, but that it has nothing directly to do with
>>>>     the 4E MAC layer.  There are many ways to provide time
>>>>     synchronization in a multi-hop network, and many ways to track
>>>>     the total wall-clock time that a packet has been in transit.
>>>>
>>>>     So...shouldn't the deadline information be in an IPv6
>>>>     hop-by-hop option header?
>>>>
>>>>     ksjp
>>>>
>>>>>     I agree that the feature is really interesting and might be
>>>>>     very useful in some cases, specially for time sensitive
>>>>>     applications, however, including a header will require the
>>>>>     parsing at each hop which would be very convenient to avoid.
>>>>>     As I said, I vote for having this feature as an optional
>>>>>     header and in case we define more options that we consider
>>>>>     Note also that when label switching is not used the Hop Limit
>>>>>     field is used to count the number of hops and detect loops,
>>>>>     however in that case there is no timestamp to discard expired
>>>>>     packets. I'm wondering if we want to add that information
>>>>>     despite of having label switching at L2.5 or not.
>>>>>
>>>>>     regards,
>>>>>     Xavi
>>>>>
>>>>>>     But about the dedicated track, I have a different thought.
>>>>>>     Knowing that the timelife of a packet is expired can be STILL
>>>>>>     useful along a dedicated track. In fact, we can discard the
>>>>>>     packet instead of keeping in forwarding it along the
>>>>>>     successive cells of the track, thus saving energy.
>>>>>>
>>>>>>     I think the info could indeed be very useful on shared slots
>>>>>>     but along a dedicated track there is no choice but continue
>>>>>>     along schedule...
>>>>>>
>>>>>>     Cheers,
>>>>>>
>>>>>>     Pascal
>>>>>>
>>>>>>
>>>>>>         mechanism, no parsing, no processing at each hop, just in
>>>>>>             During the today call, it emerged the possibility to
>>>>>>             stamp packets with deadlines to be updated during
>>>>>>             their trips thanks to the unique feature offered by
>>>>>>             TSCH to have a tightly synchronized LLN.
>>>>>>
>>>>>>             In this way, it could be possible to control the trip
>>>>>>             of each packet while it proceed towards the
>>>>>>             destination. In some hard real time applications, a
>>>>>>             remain stable for a long time, but it is also true
>>>>>>             that wireless links (in any case) can come and go
>>>>>>             also for short transients.
>>>>>>
>>>>>>             Any thoughts about this point is warmly welcome and
>>>>>>             could lead to improvements to the 6tus layer.
>>>>>>
>>>>>>             Cheers
>>>>>>
>>>>>>             Alfredo
>>>>>>
>>>>>>             -- 
>>>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 May 2013 02:03:43 +0000

Dear Kris and Alfredo:

This is where we hit the limits of determinism, mostly if we talk about the ISM band.

I went longer on that discussion in an earlier mail, but yes, I suspect the user will want in some cases to increase the capacity of the track to accommodate ETX, in which case we are in the distribution you mention. For traffic that falls in the 'buffered' category, it seems logical to me that the retry can only happen before the next frame shows up.

There are other more extreme behaviours that we might revert to: we might either drop the packet (eg there is a parallel track for bicasting aka duocasting aka live live) or the retry goes through traditional routing / best effort. And the latter will not work for fragments.

Let's put that discussion on the table at the call Friday?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mardi 28 mai 2013 19:02
To: [email-masked]
Subject: Re: [6tsch] R: On exploiting time synchronisation and deadlines in 6tus

Alfredo brings up an important point.  Latency along a track is only known if the PDR for all links is 100%.  In reality, it's a Poisson distribution that depends on the schedule&PDR at each hop.

ksjp

A track has an exact schedule: I am ok, but let's consider the case a scheduled cell is faulty and the packet that cannot be transmitted on that cell has to be delivered using (let's say) a best effort service towards the sink.

Am I missing something ?

Cheers

Alfredo

Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Pascal Thubert (pthubert)
Inviato: Tuesday, May 28, 2013 6:21 PM
A: Xavier Vilajosana; Maria Rita PALATTELLA
Cc: Pascal Thubert; [email-masked]<mailto:[email-masked]>
Oggetto: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus

Dear all:

Do I miss something?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 28 mai 2013 15:49
To: Maria Rita PALATTELLA
Cc: Pascal Thubert; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] On exploiting time synchronisation and deadlines in 6tus

Hi Maria Rita,

regards,
Xavi

Al 28/05/13 03:08, En/na Maria Rita PALATTELLA ha escrit:
Pascal, I do agree with you and  Xavi about keeping things as simple as possible...

Maria Rita

Same here,

Cheers,

Pascal

X

Did I miss something?

Thomas

Cheers

Alfredo

6tsch mailing list

6tsch mailing list

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 30 May 2013 22:30:33 -0700

Pascal,

I agree that, with the unreliable nature of wireless, we need to pull in
statistics when talking about determinism.

Some frames exchanged between these low-power wireless devices will simply
get lost. We have the advantage - with TSCH - of using channel hopping, so
the effect of a "bad" channel is averaged out by the other "good" channels.
This has the hugely beneficial side-effect that a wireless link in more
stable, i.e. it's a PDR=85% link for quite a bit of time. Certainly enough
time to make the approach of tuning the number of cells in a bundle to that
ETX a valid one. From a connectivity point of view, the advantage channel
hopping gives us is that links don't suddenly "disappear" when someone
opens a door.

I will argue that the effect of multi-path fading is more dramatic even
than that of interference (I assume that's what you were referring to by
"ISM band"?). That is, you can have two motes happily chatting (on a single
frequency), move one by a handful of cm, and have the link disappear. No
need to talk louder, the multi-path interference just kills the signal. In
essence, that pair of motes is "at wrong place at the wrong frequency".
This effects is especially true is a very "3-D" environment, i.e. indoors,
in a building, in a city, etc.

But I think that we can simply let wireless be wireless, and deal with it
in the way we schedule things. That is, match the number of cells in a
bundle to a desired bandwidth/latency, times the ETX. This does require
statistics to be collected per bundle (or better, per pair of motes), and
have that information continuously stream to the scheduling entity. This
might be the PCE in the centralized case, or just 6tus in the distributed
case. 6tus is already collecting those statistics, it's just a matter of
getting those to the right place.

In my mind, what this means is that we need to take determinism with a
grain of salt. And that grain of salt is statistics. E.g. "if you want to
pay that much energy, I will guarantee that 99.9% of the packet will reach
their destination within this deadline, but for some more energy, I can
make that 99.99%". Or something similar.

This is truly interesting stuff, very much looking forward to discussing
this during the call on Friday. I'll prepare a handful of slides, in case
this comes up.

Thomas

On Thu, May 30, 2013 at 7:03 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear Kris and Alfredo:****
>
> ** **
>
> This is where we hit the limits of determinism, mostly if we talk about
> the ISM band.****
>
> ** **
>
> I went longer on that discussion in an earlier mail, but yes, I suspect
> the user will want in some cases to increase the capacity of the track to
> accommodate ETX, in which case we are in the distribution you mention. For
> traffic that falls in the ‘buffered’ category, it seems logical to me that
> the retry can only happen before the next frame shows up. ****
>
> ** **
>
> There are other more extreme behaviours that we might revert to: we might
> either drop the packet (eg there is a parallel track for bicasting aka
> duocasting aka live live) or the retry goes through traditional routing /
> best effort. And the latter will not work for fragments. ****
>
> ** **
>
> Let’s put that discussion on the table at the call Friday?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Kris Pister
> *Sent:* mardi 28 mai 2013 19:02
> *To:* [email-masked]
> *Subject:* Re: [6tsch] R: On exploiting time synchronisation and
> deadlines in 6tus****
>
> ** **
>
> Alfredo brings up an important point.  Latency along a track is only known
> if the PDR for all links is 100%.  In reality, it's a Poisson distribution
> that depends on the schedule&PDR at each hop.
>
> ksjp****
>
> On 5/28/2013 9:35 AM, Alfredo Grieco wrote:****
>
> Dear all, Pascal,****
>
>  ****
>
> I am glad everybody consider this proposal interesting and is providing
> very precious comments.****
>
>  ****
>
> A track has an exact schedule: I am ok, but let’s consider the case a
> scheduled cell is faulty and the packet that cannot be transmitted on that
> cell has to be delivered using (let’s say) a best effort service towards
> the sink.****
>
>  ****
>
> This is a hybrid condition (the faulty cell can be referred to a mote in
> the middle of the path) that could happen in reality and for which knowing
> the age of the packet is important too.****
>
>  ****
>
> Am I missing something ?****
>
>  ****
>
> Cheers****
>
>  ****
>
> Alfredo****
>
>  ****
>
>  ****
>
> *Da:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *Per conto di *Pascal Thubert (pthubert)
> *Inviato:* Tuesday, May 28, 2013 6:21 PM
> *Oggetto:* Re: [6tsch] On exploiting time synchronisation and deadlines
> in 6tus****
>
>  ****
>
> Dear all:****
>
>  ****
>
> A track has an exact schedule, so we know how long since the emission at
> every hop.****
>
> OTOH, in the case of best effort forwarding, knowing the age of a packet
> and how that sit within a desired schedule can become very interesting.***
> *
>
>  ****
>
> Do I miss something?****
>
>  ****
>
> Pascal****
>
>  ****
>
> *On Behalf Of *Xavier Vilajosana
> Al 28/05/13 03:08, En/na Maria Rita PALATTELLA ha escrit:****
>
> +39 080 5963 911****

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 31 May 2013 08:30:25 +0200

Hi all,

Very thoughtful this exchange of mails.

Just a further point: Thomas and Pascal are proposing  to statically
overprovision the tracks using the ETX.

I do not know if frame losses with TSCH happen as they are evenly
distributed over the time or  they are bursty as in all wireless systems. I
am carefully checking this point with experiments.

In case they would be  bursty, a static overprovisioning would surely
increase the duty cycle and hence energy consumptions without making
possible an effective recovery of lost frames.

Are we sure that keeping things simpler surely helps decreasing the energy
drainage and surely fits the requirements of deterministic services ?

My two cents

Cheers

Al

On Friday, May 31, 2013, Thomas Watteyne wrote:

> <

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 31 May 2013 00:18:26 -0700

Alfredo,

Here is my side of things. In a TSCH network, the quality of a link between
two motes does vary, but over the course of multiple hours, or days, or
weeks. You might be interested in the dataset at
http://wsn.eecs.berkeley.edu/connectivity/download.php?dataset=dust. It
shows how the PDR of links evolves in a 44-mote TSCH network deployed in an
industrial setting. The data covers a month of operation, and shows the PDR
of all used links in the network, and for all of the 16 frequencies used,
in 15 minute intervals. If you plot the data, you can see that the PDR
varies more during the day than during the night, or during the week days
than during the week-ends. Interesting little things, but the most
important message is that, while it's common place to have 1-2 frequencies
be bad, never are all of them bad.

I agree with you that, as the environment changes, packet losses are
bursty. But that's at one frequency. Luckily, the motes channel hop, and
while at one frequency hardly any packet gets through, communication is
probably just fine on most of the others. So your link ends up being fine.
That is, let's say that you are hopping on 16 channels. As the environment
changes, sometimes channels 11 and 16 are bad, sometimes it's 17 and 13,
but on average you have 14/16 good channels, which is close to the PDR of
your link.

This is one of the main reasons why TSCH networks has been so successful at
delivering ultra high reliability.

Allow me to put some measurement data in some slides, if we want to talk
about it tomorrow.

Thomas

On Thu, May 30, 2013 at 11:30 PM, Alfredo Grieco
<[email-masked]>wrote:

>> Some frames exchanged between these low-power wireless devices will
>> simply get lost. We have the advantage - with TSCH - of using channel
>> hopping, so the effect of a "bad" channel is averaged out by the other
>> "good" channels. This has the hugely beneficial side-effect that a wireless
>> link in more stable, i.e. it's a PDR=85% link for quite a bit of time.
>> Certainly enough time to make the approach of tuning the number of cells in
>> a bundle to that ETX a valid one. From a connectivity point of view, the
>> advantage channel hopping gives us is that links don't suddenly "disappear"
>> when someone opens a door.
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Kris Pister

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 31 May 2013 09:42:29 +0200

Thomas,

I get your point but I have a new issue.

We have multiple channels and this is great, but in one cell we can only
use one channel. If that cell is faulty you have to retransmit your frame,
of course in another cell (hopefully on a different channel).

Now we can choose to overprovision the track so that, in case a frame is
lost, we can use another recovery cell. This inflates the duty cycle. In
fact,  If frames are not lost, recovery cells are not used: we are wasting
resources.

Another possibility, is to use shared cells to handle retranmissions to
take advantage of statistical multiplexing and reduce the duty cycle. A
shared recovery cell would  remain unused with a lower probability.

I am very looking forward to discuss About this point this afternoon.

Cheers

Alfredo

P.s. We were discussing about deadlines ... Isnt't ? :-)

On Friday, May 31, 2013, Thomas Watteyne wrote:

> Alfredo,
>
> Here is my side of things. In a TSCH network, the quality of a link
> between two motes does vary, but over the course of multiple hours, or
> days, or weeks. You might be interested in the dataset at
> This is one of the main reasons why TSCH networks has been so successful
> at delivering ultra high reliability.
>
> On Thu, May 30, 2013 at 11:30 PM, Alfredo Grieco <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> Hi all,
>>
>> Are we sure that keeping things simpler surely helps decreasing the
>> energy drainage and surely fits the requirements of deterministic services ?
>>
>> My two cents
>>
>> Cheers
>>
>> Al
>>
>>
>>
>> accommodate ETX, in which case
>>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 31 May 2013 00:55:22 -0700

Well, you know, deadlines, channel hopping, same stuff :)

I believe there is a trick in channel hopping which might address the
issues you raise. Assume node A has a *single* cell scheduled to node B,
say on channelOffset 5. Each time that cell shows up, the actual
*frequency*the transmission happens on is different each time. That is
because both
the channelOffset *and the ASN* are used to calculate this frequency. The
channelOffset can stay the same, but the ASN constantly changes, and so the
frequency is always different.

In my mind, this technique is the difference between an multi-channel and a
channel hopping solution. This is what we tried to explain in
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-02#appendix-A.7,
but maybe not clear?

The consequence is that you don't need multiple cells to channel hop, a
single one is enough. The number of cells in your bundle just determines
how many opportunities you get to communicate, but has no impact of how
much "channel hopping" is going on. Another nice thing is that you don't
have to carefully pick the channelOffset, since all are equivalent (i.e.
all provide the same amount of channel diversity).

Does that answer your concerns, or did I miss your point?

Thomas

On Fri, May 31, 2013 at 12:42 AM, Alfredo Grieco
<[email-masked]>wrote:

>> On Thu, May 30, 2013 at 11:30 PM, Alfredo Grieco <
>> [email-masked]> wrote:
>>
>>> Hi all,
>>>
>>> But I think that we can simply let wireless be wireless, and deal with
>>> it in the way we schedule things. That is, match the number of cells in a

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 31 May 2013 10:13:03 +0200

I agree on channel hopping, but the number of cells in my bundle affects
the duty cycle, and many of these cells could remain not used when we do
not need retransmissions.

If a parent node P has three sons, i could imagine a very small bundle
reservend to each son and a shared link to handle the aggregated traffic
arising from retransmissions of all sons toghether.

Thanks for your answers

Cheers

Alfredo

On Friday, May 31, 2013, Thomas Watteyne wrote:

> say on channelOffset 5. Each time that cell shows up, the actual *
> frequency* the transmission happens on is different each time. That is
> because both the channelOffset *and the ASN* are used to calculate this
> frequency. The channelOffset can stay the same, but the ASN constantly
> changes, and so the frequency is always different.
>
> In my mind, this technique is the difference between an multi-channel and
> a channel hopping solution. This is what we tried to explain in
> On Fri, May 31, 2013 at 12:42 AM, Alfredo Grieco <[email-masked]
> > wrote:
>
>
> Thomas,
>
> On Thu, May 30, 2013 at 11:30 PM, Alfredo Grieco <[email-masked]
> > wrote:
>
> Hi all,
>

---

From: Pascal Thubert <[email-masked]>
Date: Fri, 31 May 2013 07:27:03 -0700

Hello Alfredo

This is a bit different, yes.

So what you are up to is allow routing to use a track cell for 1 hop, and then the pak would be extracted from the track and punted to l3?

This could be done and only requires 1 bit to mean that this is an opportunistic reuse of the slot to be punted as opposed to mpls switched

Doable i expect...

Pascal

Le 31 mai 2013 à 01:13, Alfredo Grieco <[email-masked]> a écrit :

> I agree on channel hopping, but the number of cells in my bundle affects the duty cycle, and many of these cells could remain not used when we do not need retransmissions.
> 
> If a parent node P has three sons, i could imagine a very small bundle reservend to each son and a shared link to handle the aggregated traffic arising from retransmissions of all sons toghether.
> 
> Thanks for your answers
> 
> Cheers
> 
> 
> Alfredo
> 
>> I believe there is a trick in channel hopping which might address the issues you raise. Assume node A has a *single* cell scheduled to node B, say on channelOffset 5. Each time that cell shows up, the actual frequency the transmission happens on is different each time. That is because both the channelOffset and the ASN are used to calculate this frequency. The channelOffset can stay the same, but the ASN constantly changes, and so the frequency is always different.
>> 
>> In my mind, this technique is the difference between an multi-channel and a channel hopping solution. This is what we tried to explain in http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-02#appendix-A.7, but maybe not clear? 
>> 
>> The consequence is that you don't need multiple cells to channel hop, a single one is enough. The number of cells in your bundle just determines how many opportunities you get to communicate, but has no impact of how much "channel hopping" is going on. Another nice thing is that you don't have to carefully pick the channelOffset, since all are equivalent (i.e. all provide the same amount of channel diversity).
>> 
>> On Fri, May 31, 2013 at 12:42 AM, Alfredo Grieco <[email-masked]> wrote:
>> 
>> Thomas,
>> 
>> We have multiple channels and this is great, but in one cell we can only use one channel. If that cell is faulty you have to retransmit your frame, of course in another cell (hopefully on a different channel).
>> 
>> Now we can choose to overprovision the track so that, in case a frame is lost, we can use another recovery cell. This inflates the duty cycle. In fact,  If frames are not lost, recovery cells are not used: we are wasting resources.
>> 
>> Another possibility, is to use shared cells to handle retranmissions to take advantage of statistical multiplexing and reduce the duty cycle. A shared recovery cell would  remain unused with a lower probability. 
>> 
>> Here is my side of things. In a TSCH network, the quality of a link between two motes does vary, but over the course of multiple hours, or days, or weeks. You might be interested in the dataset at http://wsn.eecs.berkeley.edu/connectivity/download.php?dataset=dust. It shows how the PDR of links evolves in a 44-mote TSCH network deployed in an industrial setting. The data covers a month of operation, and shows the PDR of all used links in the network, and for all of the 16 frequencies used, in 15 minute intervals. If you plot the data, you can see that the PDR varies more during the day than during the night, or during the week days than during the week-ends. Interesting little things, but the most important message is that, while it's common place to have 1-2 frequencies be bad, never are all of them bad.
>> 
>> I agree with you that, as the environment changes, packet losses are bursty. But that's at one frequency. Luckily, the motes channel hop, and while at one frequency hardly any packet gets through, communication is probably just fine on most of the others. So your link ends up being fine. That is, let's say that you are hopping on 16 channels. As the environment changes, sometimes channels 11 and 16 are bad, sometimes it's 17 and 13, but on average you have 14/16 good channels, which is close to the PDR of your link.
>> 
>> This is one of the main reasons why TSCH networks has been so successful at delivering ultra high reliability.
>> 
>> Allow me to put some measurement data in some slides, if we want to talk about it tomorrow. 
>> 
>> Thomas
>> 
>> 
>> On Thu, May 30, 2013 at 11:30 PM, Alfredo Grieco <[email-masked]> wrote:
>> Hi all,
>> 
>> Just a further point: Thomas and Pascal are proposing  to statically overprovision the tracks using the ETX. 
>> 
>> I do not know if frame losses with TSCH happen as they are evenly distributed over the time or  they are bursty as in all wireless systems. I am carefully checking this point with experiments.
>> 
>> In case they would be  bursty, a static overprovisioning would surely increase the duty cycle and hence energy consumptions without making possible an effective recovery of lost frames. 
>>