Merge branch 'master' into utf8-byte

Author: pavel-kirienko

specification/application/conventions.tex

@@ -12,8 +12,8 @@ \subsection{Node identifier distribution}
 Valid values of node-ID range from 0 up to a transport-specific upper boundary
 which is guaranteed to be above 127 for any transport.
 
-The two uppermost node-ID values are reserved for diagnostic and debugging tools;
-these node-ID values should not be used in fielded systems.
+Node-ID values of 126 and 127 are reserved for diagnostic and debugging tools.
+These values should not be used in fielded systems.
 
 \subsection{Service latency}
 

specification/introduction/introduction.tex

@@ -243,6 +243,8 @@ \subsection{v1.0 -- work in progress}
     \item Support for UTF-8 strings and byte strings has been added.
 
     \item Cyphal/UDP and Cyphal/serial transport specifications have been introduced.
+
+    \item Minor adjustments of the transport layer definitions.
 \end{itemize}
 
 \subsection{v1.0-beta -- Sep 2020}

specification/transport/abstract.tex

@@ -480,22 +480,22 @@ \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 zero.
 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 +673,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 +691,9 @@ \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
+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.
 
 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{%
@@ -703,6 +702,13 @@ \subsubsection{Behaviors}
 The parameters of such computation are to be chosen according to the requirements of the application,
 but they should always be documented.
 
+The transfer-ID timeout used with service response transfers should be zero\footnote{%
+    With a non-zero transfer-ID timeout, responses may be lost if the server responds to multiple requests
+    from the same client not in the order of their arrival.
+    There is no risk of response duplication because the client will retire the pending request entry
+    once its first response is received, ignoring subsequent duplicates.
+}.
+
 \begin{remark}
     Low transfer-ID timeout values increase the risk of undetected transfer duplication when such transfers
     are significantly delayed due to network congestion,

specification/transport/udp/udp.tex

@@ -373,6 +373,14 @@ \subsection{Maximum transmission unit}
     which is allowed as long as such behavior is opaque to the Cyphal/UDP end systems.
 }.
 
+In multi-frame transfers, the payload size of all frames except the last one shall be the same.
+The payload size of the last frame shall be greater than zero and not greater than that of the preceding
+frames\footnote{%
+    The same-MTU constraint for all frames except the last is necessary to enable efficient reassembly of
+    multi-frame transfers with frames arriving out-of-order, including the case of frames interleaving between
+    adjacent transfers.
+}.
+
 \subsection{Real-time and resource-constrained systems}
 
 It is anticipated that real-time and/or resource-constrained systems may implement Cyphal/UDP