Merge pull request #100 from UAVCAN/78

Be more explicit about the flexibility of the transfer-ID timeout setting

specification/introduction/introduction.tex

@@ -15,7 +15,7 @@ \section{Overview}
 with a specialized interface description language and a highly efficient data serialization format
 suitable for use in real-time safety-critical systems with optional modular redundancy.
 
-The name UAVCAN stands for \emph{Uncomplicated Application-level Vehicular Communication And Networking}.
+The name UAVCAN stands for \emph{Uncomplicated Application-level Vehicular Computing And Networking}.
 
 UAVCAN is a standard open to everyone, and it will always remain this way.
 No authorization or approval of any kind is necessary for its implementation, distribution, or use.
@@ -206,9 +206,6 @@ \section{Revision history}
 
 \subsection{v1.0-beta -- Sep 2020}
 
-This version is to be followed by \emph{v1.0} upon completion of the formal standardization process
-in one of the standard bodies.
-
 Compared to v1.0-alpha, the differences are as follows (the motivation is provided on the forum):
 
 \begin{itemize}
@@ -221,6 +218,9 @@ \subsection{v1.0-beta -- Sep 2020}
     \item Added support for delimited serialization; introduced related concepts of \emph{extent} and \emph{sealing}
           (section \ref{sec:dsdl_composite_extent_and_sealing}).
           This change enables one to easily evolve networked services in a backward-compatible way.
+
+    \item Enabled the automatic runtime adjustment of the transfer-ID timeout on a per-subject basis
+          as a function of the transfer reception rate (section \ref{sec:transport_transfer_reception}).
 \end{itemize}
 
 \subsection{v1.0-alpha -- Jan 2020}

specification/transport/abstract.tex

@@ -662,16 +662,19 @@ \subsubsection{Transmission over redundant transports}
     in section~\ref{sec:application_functions}.
 }.
 
-\subsection{Transfer reception}
+\subsection{Transfer reception}\label{sec:transport_transfer_reception}
 
 \subsubsection{Definitions}
 
 \emph{Transfer reassembly} is the real-time process of reconstruction of the transfer payload and its metadata from
 a sequence of relevant transport frames.
 
-\emph{Transfer-ID timeout} is a time interval that is 2 (two) seconds long.
-The semantics of this entity are explained below.
-Implementations are allowed to redefine this value provided that such redefinition is explicitly documented.
+\emph{Transfer-ID timeout} is a time interval whose semantics are explained below.
+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.
 \emph{Transfer reception timestamp} is the reception timestamp of the earliest received frame of the transfer.
@@ -693,13 +696,32 @@ \subsubsection{Behaviors}
 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.
 
+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{%
+    E.g., as a multiple of the average transfer reception interval.
+}.
+The parameters of such computation are to be chosen according to the requirements of the application,
+but they should always be documented.
+
 \begin{remark}
     Low transfer-ID timeout values increase the risk of undetected transfer duplication when such transfers
     are significantly delayed due to network congestion,
     which is possible with very low-priority transfers when the network load is high.
 
     High transfer-ID timeout values increase the risk of an undetected transfer loss
     when a remote node suffers a loss of state (e.g., due to a software reset).
+
+    The ability to auto-detect the optimal transfer-ID timeout value per session at runtime ensures that the
+    application can find the optimal balance even if the temporal properties of the network are not known in advance.
+    As a practical example, an implementation could compute the exponential moving average of the
+    transfer reception interval $x$ for a given session and define the transfer-ID timeout as $2x$.
+
+    It is important to note that the automatic adjustment of the transfer-ID timeout should only be done
+    on a per-session basis rather than for the entire port, because there may be multiple remote nodes
+    emitting transfers on the same port at different rates.
+    For example, if one node emits transfers at a rate $r$ transfers per second, and another node emits transfers
+    on the same port at a much higher rate $100r$, the resulting auto-detected transfer-ID timeout might be
+    too low, creating the risk of accepting duplicates.
 \end{remark}
 
 Implementations are recommended, but not required, to support reassembly of