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.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
