Hello Anand
Thanks for this!
> 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.
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.
>
> 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.
Make sense. We are working on a draft on tracks to extend this draft, and text
around that would be useful.
>
> 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!
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 : )
>
> 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.
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
> mentioned in 1) above, the amount of delay that is permitted needs to
> 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.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
