Hi Pavel and Scott,
Regarding tunneling, I’m coming to a conclusion that indeed, transparent (aka unescaped) payload and tunneling are basically incompatible. Or, to be more precise, out of 3 properties: transparent payload, tunneling support and no out-of-band signaling only two can be satisfied simultaneously. So practically, with transparent payload, TCP which has out of band signaling can support tunneling, and UART serial port can’t. In channels with OOB like TCP or USB, link reset would trigger a connection reset, therefore no recovery is ever required.
Regarding text-based protocol:
I’m consider those two good reasons to build text protocols: when the underlying medium only supports text, or when eyeball debugging/ keyboard simulation is desirable. I don’t actually see any of those in UAVCAN/serial. Eyeball debugging in no realistic with the efficient encodings, and the underlying channel is based on bytes (we’ve come a long way from teletype terminals). So I see no good reason to ignore the high bit or, worse, limit ourselves to 85 characters out of 255.
So practically, the sensible choice seems to pick “transparent payload” for channels with OOB, and use stuffing for pure UART serial links. (since VCP is sometimes chained with UART unknowingly to the end device it will have to be bundled it with the latter for general purpose implementations)
With that in mind, and looking back at efficient stuffing options, what do you mean by “while it [COBS] offers a substantially lower overhead, it undermines the synchronization recovery properties of the protocol.” ? Since each packet is encoded separately, recovery time should not be affected.
P.S.
You might find this interesting:
(source)
P.S.2
For my immediate specific application, where in additional to bandwidth and CPU utilization, code simplicity is also a concern, a direct USB link with transparent payload is probably the best choice. Implementing IP and guaranteed delivery (TCP or alternative) of a sample stream adds rather significant complexity.