mod_nn function needs a lot of time (many initializations are run), check is done; evaluates to FALSE all the time
Packet pools might improve performance
Decoupling feedback-sending from reception might speed up processing (could be possible to do it on separate cores)
Think about code blocks where parallel computation or progressive computation makes sense (e.g., at the moment we sometimes create redundancy packets which we might not need eventually).
DPDK as a UDP socket replacement.
Vector packet processing (VPP) to send redundancy packets in batches.
Revisit inter-process communication and look for points to optimize.
Adapative coding: Currently, we can extract channel parameters from the socket and set a new coding configuration. Missing is a box in the middle which decides which configuration to pick.
Protocol-internal clock synchronization: At the moment the sync is not fast enough so that at the beginning of the transmission, packets are dropped. Therefore, the clock sync runs at the moment, but we never query the protocol-internal clock but the system clock. Find out why certain constants are used in clock sync. Check if they can be tuned to improve the sync performance. This could also include sending the hardware-send-timestamp of the last packet to allow for send stack compensation (as done in e.g. PTP).
The original PRRT had a priority field, which we also use in our implementation. It is not yet clear, what this field should be used for.
Acknowledgements: Currently, we use positive selective acknowledgements. It should be tested, how we can move to a) a negative acknowledgement scheme and b) how feedback can be suppressed or aggregated. More ideas can also be found here.
Residual loss rate: Receiver could calculate how many residual errors are present (in contrast to a channel error rate calculation).
Loss rate and correlation estimation based on Gilbert-Elliot or other models.
Check if sender also needs clean-up of its resources.
Revisit usage of Vandermonde matrix. Changing a coding configuration should be relatively inexpensive (get_coder should be fast).