Subject: [6tisch] On draft-thubert-6tisch-4detnet-01 : Packet replication and elimination

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 09 Oct 2015 15:14:35 +0530

Hi Pascal,

Thanks a lot for the excellent draft-thubert-6tisch-4detnet-01.txt draft.
It was a thoroughly enjoyable read!

In this rather lengthy mail, I tried to put together some of the thoughts
related to the Packet Replication and Elimination part of the draft.
Hope you will find the below text interesting. Read on.

------------------------------------------------------------------------

PRP is a very promising concept that is nice and simple, but 
nevertheless needs
special attention in its implementation when we have to ensure the stringent
requirements of the Detnet charter. You have already noted this point in 
your
response mail.

1) The PCE and PRE-process interaction is going to play significant role 
if we
consider the fact that the listener is going to be one or more 
heterogeneous L2
networks away beyond 6tisch. The PCE is going to be stingy by allocating 
only
part of the total time budget for 6tisch for flows! Of course, this 
stress will
be felt by all the participating transit L2 networks from talker to 
listener.

2) Though it might sound out of scope of the draft, it is important to
recognize that the key requirement for effective operation of PRP is the
infrastructure support, wherein adequate of BBRs and their placement are
crucial to satisfy the delay bounds and providing high reliability. The
infrastructure deployment is not going to be one-time activity any more 
since
the addition of new application flows, changes in the QoS requirements,
sensors, and so on call for its upgrade.

3) With reference to the following para in the draft,

"At each 6TiSCH hop along the Track, the PCE may schedule more than one
timeSlot for a packet, so as to support Layer-2 retries (ARQ). It is also
possible that the field device only uses the second branch if sending 
over the
first branch fails."

interestingly we worked on very similar idea of reacting to link 
failures and
implemented a mechanism on Contiki/RPL, we call LinkPeek.

("Link Peek: A Link Outage Resilient IP Packet Forwarding Mechanism for
6LoWPAN/RPL Based Low-Power and Lossy Networks (LLNs)", IEEE MS-2015.
URL : http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7226673)

The reactive/conditional replication offers the benefit of supporting more
flows with high PDRs. The delay goes up with the number of parents being
explored, and per-parent re-transmit count. The side-effect of this 
additional
delay is the increase in the packet backlog, which can lead to buffer
overflows. The choice of this approach is therefore application specific 
that
are delay tolerant. The 802.1 TSN group might have reservations!

4) The pro-active/unconditional replication certainly gives a sense of 
comfort
since packets simultaneously travel over multiple tracks. Since we could 
end up
being conservative, it could limit the numer of flows that can 
supported. So,
here too PCE has to find ways of optimally utilizing the resources. The 
PCE in
collaboration with NME and collection point can decide on (i) the depth from
where the replication can be initiated, and ii) the degree of 
replication that
is appropriate and set up tracks and bundles. The collection point, for
instance, can indicate to the PCE about the quality of the tracks based 
on the
packets that are consumed from tracks, and so on.

5) The functionality at the collection point is going to be crucial since it
has to perform the tasks of minimizing the waiting time of the missing 
packets
and reduce jitter buffer delays as the packets arrive from different 
tracks. As
mentioned in 1) above, the amount of delay that is permitted needs to 
come from
PCE and application requirements.

In this context, we might want to ask, can collection point be allowed 
to give
out-of-sequence packets to the listener in order to minimize delays ? If 
jitter
delay is going to be significant, are we in danger of hurting end 
application ?
Not sure if we are going to introduce separate sequence numbering for PRP.

Thanks for your patience! Will be very happy to have your inputs.

Anand

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Oct 2015 15:29:12 +0000

Hello Anand

Thanks for this!

> PRP is a very promising concept that is nice and simple, but nevertheless
> needs special attention in its implementation when we have to ensure the
> stringent requirements of the Detnet charter. You have already noted this
> point in your response mail.
> 
> 1) The PCE and PRE-process interaction is going to play significant role if we
> consider the fact that the listener is going to be one or more heterogeneous
> L2 networks away beyond 6tisch. The PCE is going to be stingy by allocating
> only part of the total time budget for 6tisch for flows! Of course, this stress
> will be felt by all the participating transit L2 networks from talker to
> listener.

Yes, the plan would be to separate resources in chunks and allocate some chunks to the PCE
Ideally, the cell in chunks will be evenly spaced to avoid blacking out other cunks for long contiguous periods of time.

> since the addition of new application flows, changes in the QoS
> requirements, sensors, and so on call for its upgrade.

Make sense. We are working on a draft on tracks to extend this draft, and text around that would be useful.

> possible that the field device only uses the second branch if sending over
> the first branch fails."
> 
> interestingly we worked on very similar idea of reacting to link failures and
> additional delay is the increase in the packet backlog, which can lead to
> buffer overflows. The choice of this approach is therefore application
> specific that are delay tolerant. The 802.1 TSN group might have
> reservations!

I worked on similar ideas in the context of tracks as opposed to RPL, and must admit I filed IPR there.
I'll read with great interest : )

> comfort since packets simultaneously travel over multiple tracks. Since we
> could end up being conservative, it could limit the numer of flows that can
> supported. So, here too PCE has to find ways of optimally utilizing the
> resources. The PCE in collaboration with NME and collection point can
> decide on (i) the depth from where the replication can be initiated, and ii)
> the degree of replication that is appropriate and set up tracks and bundles.
> The collection point, for instance, can indicate to the PCE about the quality
> of the tracks based on the packets that are consumed from tracks, and so
> on.

Yes. Probably something to discuss @ detnet or PCE.

> 
> 5) The functionality at the collection point is going to be crucial since it has
> to perform the tasks of minimizing the waiting time of the missing packets
> and reduce jitter buffer delays as the packets arrive from different tracks. As
> come from PCE and application requirements.

Yes, the last cell to destination (if there are many) must be before the official arrival point.
And the destination would have a buffer for incoming that it would not read before that even if a copy of the frame is received earlier.

> 
> In this context, we might want to ask, can collection point be allowed to
> give out-of-sequence packets to the listener in order to minimize delays ? If
> jitter delay is going to be significant, are we in danger of hurting end
> application ?

I would expect that it is app dependant but with my comment above the frames would not be read put of order since they are always read after the last possible time slot for that frame.

> Not sure if we are going to introduce separate sequence numbering for PRP.

Well, it might not be PRP per se (eg there's IPR on it and maybe it is too costly) but yes there will be a sequence.
Now, the sequence may not be written in the frame if it can be deduced from the schedule and the ASN.

> Thanks for your patience! Will be very happy to have your inputs.

: )

Pascal

> 
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 18 Oct 2015 11:48:19 +0530

Hi Pascal,

Thank you very much for shedding light on all the points I raised, and
providing ways of implementing PRP mechanism in the 6tisch context. It 
is nice to
note that we have the initial building blocks in place. As you rightly 
pointed
out, there is a good extent of coupling with the work done in PCE and 
Detnet.
Your recent mail to these groups is very significant. Given that there is so
much of IPR in the area, I suppose we still have open problems to solve!

Anand

 >> Hope you will find the below text interesting. Read on.
nevertheless
 >> consider the fact that the listener is going to be one or more 
heterogeneous
 > Ideally, the cell in chunks will be evenly spaced to avoid blacking 
out other cunks for long contiguous periods of time.
failures and
tracks. As
 > And the destination would have a buffer for incoming that it would 
not read before that even if a copy of the frame is received earlier.
 > I would expect that it is app dependant but with my comment above the 
frames would not be read put of order since they are always read after 
the last possible time slot for that frame.
 > Well, it might not be PRP per se (eg there's IPR on it and maybe it 
is too costly) but yes there will be a sequence.