Fountain codes require more buffering of data on both the sender and receiver side, which means increased latency. There is certainly a case for it, but it seems in conflict with the rest of the protocol design.

Various packet erasure codes can definitely be supported. Fountain codes are one family. But better options might be normal packet erasure codes that combine normal/clear data and parity data.

Whether increased latency results is a function of how it is integrated and the code in use. A configuration with a "clear" channel and a "parity" channel should only incur a latency hit when loss is seen. And that latency hit will be less than a selective retransmit which requires an RTT at minimum. Due to the design of the logbuffer data structure, there is also no hit on the parity generation on the publisher.

Let me explain.

One of the consequences of the design of the logbuffer is that it is easy to have multiple non-contending readers. So, a separate thread could be generating parity and sending it on the publisher side without contending on the logbuffer publisher. This means no latency hit to the normal/clear data.

On the receiver side, parity is only required if there is loss. And that can easily be determined by position checks which are done already. If no loss, then no hit on latency.

Aeron is uniquely designed so that it can use some forms of FEC without a latency hit. Which opens up some interesting use cases.