Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - ARQ protocol (auto retry, specific to wireless)

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 6 May 2016 18:33:24 +0000

Statement:
6TiCH use case: ARQ protocol (auto retry, specific to wireless)
Discussion:

The relevant text from the draft is shown below. The actionable statement is "this may be a technique that would be appropriate for DetNet and so aspects of the enabling protocol could be co-developed [between DetNet and 6TiSCH]".

So the first question is "Will DetNEt use this ARQ (or ARQ-like) technique?"  If so, how does it affect the DetNet architecture, control or data plane specification?

6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism to
                            provide higher reliability of packet delivery. ARQ is related to packet
                            replication and elimination because there are two independent paths for
                            packets to arrive at the destination, and if an expected packed does not
                            arrive on one path then it checks for the packet on the second path.
                         Although to date this mechanism is only used by wireless networks, this
                            may be a technique that would be appropriate for DetNet and so aspects
                            of the enabling protocol could be co-developed.
                         For example, in <xref target="wi_fig3"/>, a Track is laid out from a
                            field device in a 6TiSCH network to an IoT gateway that is located on a
                            IEEE802.1 TSN backbone.
                         The Replication function in the field device sends a copy of each packet
                            over two different branches, and the PCE schedules each hop of both
                            branches so that the two copies arrive in due time at the gateway. In
                            case of a loss on one branch, hopefully the other copy of the packet
                            still arrives within the allocated time. If two copies make it to the
                            IoT gateway, the Elimination function in the gateway ignores the extra
                            packet and presents only one copy to upper layers.
                         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).
                         In current deployments, a TSCH Track does not necessarily support PRE
                            but is systematically multi-path. This means that a Track is scheduled
                            so as to ensure that each hop has at least two forwarding solutions, and
                            the forwarding decision is to try the preferred one and use the other in
                            case of Layer-2 transmission failure as detected by ARQ.
--------------------------------------------------------