Transfer-ID reuse in response transfers was a design mistake and it warrants a footnote #148
Description
The transfer-ID is quite essential for multi-frame reassembly, deduplication, sequence monitoring, and redundant interface selection, but its usage for request/response matching was a mistake because it interferes with the primary use cases if the server responds to multiple requests not in the order of their arrival, which has been observed in the wild.
One mitigation is to use a transfer-ID timeout of zero for response transfers; see:
- https://github.com/OpenCyphal-Garage/libcyphal/blob/8716d162ef0390318c2f77120a72cd234b93ca3b/include/libcyphal/presentation/client_impl.hpp#L151-L157
- The transfer-ID timeout for RPC response sessions must be zero libudpard#63
We already mention in Spec v1.0 that the transfer-ID timeout of response ports should be zero, but that is not enough because a delayed duplicated start-of-transfer arriving at the client RX port may cause the port to discard a valid incomplete multiframe transfer, causing transfer loss. Ideally, the transfer-ID timeout should never be zero to avoid this condition.
There is no way to fix this now without breaking compatibility, so this is going to stay as is in RPCs. In v1.1 named topics we should send the responded-to transfer-ID as part of the response payload header.