#140

Author: pavel-kirienko

specification/transport/abstract.tex

@@ -480,22 +480,26 @@ \subsubsection{Transfer-ID}\label{sec:transport_transfer_id}
 The transfer-ID value of every emitted transfer is determined by sampling the corresponding counter
 keyed by the session specifier of the transfer; afterwards, the counter is incremented by one.
 
-The initial value of a transfer-ID counter shall be zero.
+When the transfer-ID counter reaches the maximum value defined for the concrete transport,
+the next increment resets its value to zero.
+Transports where the number of distinct transfer-ID values is not less than $2^{48}$ are said to have
+\emph{monotonic transfer-ID}.
+Those with narrower transfer-ID counters are said to have \emph{cyclic transfer-ID};
+the number of unique transfer-ID values is referred to as \emph{transfer-ID modulo}.
+
+The initial value of a cyclic transfer-ID counter shall be zero.
+The initial value of a monotonic transfer-ID counter should be chosen randomly whenever a new transfer-ID counter
+is created, unless the execution environment does not provide a good source of true random numbers,
+in which case zero initialization can be used as the fallback solution\footnote{%
+    Refer to section \ref{sec:transport_transfer_reception} for the rationale behind random numbers.
+}.
 Once a new transfer-ID counter is created,
-it shall be kept at least as long as the node remains connected to the transport network;
-destruction of transfer-ID counter states is prohibited\footnote{%
+it should be kept at least as long as the node remains connected to the network.\footnote{%
     The number of unique session specifiers is bounded and can be determined statically per application,
     so this requirement does not introduce non-deterministic features into the application even if it leverages
     aperiodic/ad-hoc transfers.
 }.
 
-When the transfer-ID counter reaches the maximum value defined for the concrete transport,
-the next increment resets its value to zero.
-Transports where such events are expected to take place during operation are said to have \emph{cyclic transfer-ID};
-the number of unique transfer-ID values is referred to as \emph{transfer-ID modulo}.
-Transports where the maximum value of the transfer-ID is high enough to be unreachable under all conceivable
-practical circumstances are said to have \emph{monotonic transfer-ID}.
-
 \emph{Transfer-ID difference} for a pair of transfer-ID values $a$ and $b$ is defined
 for monotonic transfer-ID as their arithmetic difference $a-b$.
 For a cyclic transfer-ID, the difference is defined as the number of increment operations that need to be applied
@@ -673,7 +677,6 @@ \subsubsection{Definitions}
 Implementations may define this value statically according to the application requirements.
 Implementations may automatically adjust this value per session at runtime as a function of the
 observed transfer reception interval.
-Transfer-ID timeout values greater than 2 (two) seconds are not recommended.
 Implementations should document the value of transfer-ID timeout or the rules of its computation.
 
 \emph{Transport frame reception timestamp} specifies the moment of time when the frame is received by a node.
@@ -692,9 +695,26 @@ \subsubsection{Behaviors}
     Unintentional duplications may be introduced by various artifacts of the transport network.
 }.
 
-For a given session specifier, a successfully reassembled transfer that is temporally separated from
-any other successfully reassembled transfer under the same session specifier by more than the transfer-ID timeout
-is considered unique regardless of its transfer-ID value.
+For a given session specifier, a successfully reassembled transfer that is either:
+\begin{itemize}
+    \item temporally separated from any other successfully reassembled transfer under the same session specifier
+    by more than the transfer-ID timeout, or
+    \item has a transfer-ID value that is at least one million counts\footnote{%
+        The probability of randomly picking a 64-bit value that falls into a given million-count span
+        is approximately one in 18 trillion.
+    }
+    less than that of the last successfully reassembled transfer,
+\end{itemize}
+is considered unique regardless of its transfer-ID value.\footnote{%
+    A large leap backward indicates that the sender has lost the state of its transfer-ID counter
+    (e.g., due to power cycling); this is why random initialization is preferred for all nodes.
+    An exception is made for resource-constrained nodes implemented in small MCUs, which may not have access
+    to a good source of entropy to provide distinct transfer-ID values at every boot,
+    in which case zero initialization is acceptable.
+    A possible issue with constant initialization is that once a node is restarted, from the receiver's standpoint
+    it will appear that it is sending duplicate transfers, which will be rejected until the expiration of the
+    transfer-ID timeout.
+}
 
 If the optimal transfer-ID timeout value for a given session cannot be known in advance,
 it can be computed at runtime on a per-session basis\footnote{%