Specify Cyphal/UDP [experimental] #127
Conversation
|
To save everyone a bit of time: |
|
I think: |
@maksimdrachov Currently, valid subject-ID values are from 0 to 8191 inclusive:
This range may be increased in the future. Both Cyphal/UDP and Cyphal/CAN are ready for that by providing extra bits for the identifiers that are currently unused. |
specification/transport/udp/udp.tex
Outdated
|
|
||
| This specification does not restrict the MTU of the underlying transport. | ||
| It is recommended, however, to avoid MTU values less than 508~bytes to allow reduced (simplified) implementations | ||
| of the protocol that do not require large transfer payloads to omit support for multi-frame transfers. |
There was a problem hiding this comment.
What about IP fragmentation and reassembly? Do we require and/or recommend that IP framing be used in lieu of Cyphal framing? Do we prohibit it? It seems complicated, if hand-writing a Cyphal/UDP/IP stack, to have to support both.
There was a problem hiding this comment.
I am inclined to prohibit multipart IP transfers as they are indeed redundant in the presence of Cyphal framing, but wouldn't that be overreach on our part? We define the protocol in terms of UDP/IP, and, strictly speaking, most of the things that happen underneath are not our responsibility.
There was a problem hiding this comment.
This continues to vex me. It's important, for the smallest and/or most critical nodes, that the amount of software required to run Cyphal is minimised. This means the network designer has to chose between ip framing or Cyphal. I'd like to take some stance on this and I'm leaning towards prohibiting multi-part Cyphal messages on IP networks. What reason do we have to go the other way and prohibit ethernet framing in favor of Cyphal?
There was a problem hiding this comment.
I added a clarification with an elaboration on why IP fragmentation should be avoided.
|
|
||
| This specification does not restrict the MTU of the underlying transport. | ||
| It is recommended, however, to avoid MTU values less than 508~bytes, | ||
| allowing applications to exchange up to $508 - 24 - 4 = 480$ bytes of payload in a single-frame transfer. |
There was a problem hiding this comment.
Should we recommend 1280 octets since that's the IPV6 link minimum (per https://datatracker.ietf.org/doc/html/rfc8200)? I'm not sure what the general MTU support available is for networking equipment but looking at my Macbook, for example, it lists 1500 as "standard" MTU for both a USB ethernet link I have and the internal wifi radio.
There was a problem hiding this comment.
Indeed, 1500 bytes is standard for Ethernet, and I am fairly confident that 1280 will work anywhere unless you want to shuttle your packet across the public Internet, but there is another concern we should be considering: the worst-case preemption latency, which is a function of the link speed and MTU. You may remember that AFDX limits the MTU per VL type for this reason. By requiring (or recommending) a higher MTU we may strip the designer of the flexibility required to meet the timing constraints. You might argue here that this is less relevant for Cyphal/UDP as there is Cyphal/TSN on the horizon, but unless there are strong reasons to do otherwise, we should not undermine the ability of the protocol to meet stricter real-time requirements.
specification/transport/udp/udp.tex
Outdated
| (section~\ref{sec:transport_transfer_payload}). | ||
| The preference towards Cyphal framing over IP framing is to remove the limitation on the maximum transfer size | ||
| imposed by the UDP protocol and to permit preemption of long transfers by higher-priority transfers. | ||
| Further, the support for reassembly of large fragmented IP packets is not universal. |
There was a problem hiding this comment.
Let's reference this RFC -> https://datatracker.ietf.org/doc/html/rfc8900 <- and just say "Cyphal does not require IP framing per the recommendations of RFC8900"
specification/transport/udp/udp.tex
Outdated
| Limiting the MTU at this value allows nodes that do not transmit and/or receive transfers larger than 480~bytes | ||
| to omit support for multi-frame transfer decomposition and/or reassembly. | ||
|
|
||
| Nodes emitting Cyphal/UDP traffic \emph{should} avoid IP fragmentation by |
There was a problem hiding this comment.
We need to be a bit stronger here since the specification must provide a reasonable amount interoperability guarantees. We should state that Cyphal/UDP end systems shall not utilize IP fragmentation on transmission and shall not be required to support it for reception. If routers end up doing it in a manner that is opaque to the end systems then the specification makes no prohibitions, however; any router that Cyphal/UDP end systems are connected to SHOULD not send ICMP messages indicating a transmission is too large (PTB) because:
- This increases the network load which can modify the timing of the system and which may be considered an attack vector for some systems.
- Cyphal/UDP nodes are not required to support ICMP messaging and will therefore not be able to modify their behaviour based on PTB messages.
The specification is quite concise because the key concepts are already covered in section "4.1 Abstract concepts". In the new section, I only had to cover the layouts.