From 79687d8e2f407dbc9e1e1686e1ea1a33846fdb69 Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 9 May 2025 21:13:48 +0300 Subject: [PATCH 1/6] #129 --- specification/application/conventions.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specification/application/conventions.tex b/specification/application/conventions.tex index be5710d..d8cd62a 100644 --- a/specification/application/conventions.tex +++ b/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} From 0d46f41ed554967ee666a32065685a6ae9c43dba Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 9 May 2025 21:22:48 +0300 Subject: [PATCH 2/6] #131 --- specification/transport/udp/udp.tex | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/specification/transport/udp/udp.tex b/specification/transport/udp/udp.tex index 38b1633..3076431 100644 --- a/specification/transport/udp/udp.tex +++ b/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 From 400795e04be00a26f83d003ca6d3e446ba5a45ad Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 9 May 2025 21:53:40 +0300 Subject: [PATCH 3/6] #140 --- specification/transport/abstract.tex | 48 ++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 14 deletions(-) diff --git a/specification/transport/abstract.tex b/specification/transport/abstract.tex index 16737bf..2b49214 100644 --- a/specification/transport/abstract.tex +++ b/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{% From 741b21623794ab4a6bc745f5b9b9130f4f1d7183 Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 9 May 2025 21:57:10 +0300 Subject: [PATCH 4/6] #139 --- specification/transport/abstract.tex | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/specification/transport/abstract.tex b/specification/transport/abstract.tex index 2b49214..7089738 100644 --- a/specification/transport/abstract.tex +++ b/specification/transport/abstract.tex @@ -723,6 +723,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, From d36458b737f3f703ca3ca247a50e7c591949695e Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Fri, 9 May 2025 22:00:04 +0300 Subject: [PATCH 5/6] update the introduction --- specification/introduction/introduction.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/specification/introduction/introduction.tex b/specification/introduction/introduction.tex index fbcc9b3..e18e007 100644 --- a/specification/introduction/introduction.tex +++ b/specification/introduction/introduction.tex @@ -241,6 +241,8 @@ \subsection{v1.0 -- work in progress} across multiple repositories and code can be generated from a union of said folders. \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} From f58634265ed35cb2091dc648b4e0dc3d1ebf93d4 Mon Sep 17 00:00:00 2001 From: Pavel Kirienko Date: Mon, 12 May 2025 18:09:01 +0300 Subject: [PATCH 6/6] restore the original meaning of the transfer-ID description although using better wording --- specification/transport/abstract.tex | 29 ++++------------------------ 1 file changed, 4 insertions(+), 25 deletions(-) diff --git a/specification/transport/abstract.tex b/specification/transport/abstract.tex index 7089738..b907f77 100644 --- a/specification/transport/abstract.tex +++ b/specification/transport/abstract.tex @@ -488,11 +488,7 @@ \subsubsection{Transfer-ID}\label{sec:transport_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. -}. +The initial value of a monotonic transfer-ID counter should be zero. Once a new transfer-ID counter is created, 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, @@ -695,26 +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 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. -} +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{%