- Pacing using the max-filter did work for ULLWN, but it poses problems for video streaming.
- We should consider changing the filter.
- Use results from Kleinrock18 and use \epsilon * BDP as a guidance for pacing (with \epsilon close to but not exactly 1).
- Consider using one filter per pace or sync the different paces so that "internal", "external" and "dependent" timeout at the same time.
- Evaluate multi-hop scenarios (validate that NW buffers are empty) .
- Wireless hop (how do aggregation et al. Have an impact?)
- Evaluate with cross-traffic (check if CC is working reliably).
- Compare with TCP Vegas to ensure that both avoid latency.
- Video Streaming
- Control Applications
- Note: Most systems are Markovian, so the most recent values are the most valuable ones. For "model learning", old values are still relevant.
- Provide a VM with everything installed to be used out of the box
- PRRT on riot-os (and RFC7228 hardware)
- Publish PRRT to pypi index
- Think about porting to Windows (how about Gstreamer and DPDK?)
- Evaluate on top of MAC layer (e.g. Socket4CAN, ZigBee, ...)
- Synchronized / Gap-preserving mode: This mode returns empty packets (fill-value is configurable) if they did not arrive in time.
- Zero-Copy Send: Applications asks for a ready-made packet, fills it and passes this to PRRT.
- Register a handling function with the socket, which is called upon packet reception.
- Receive updates about the channel parameters.
- Application parameters: Allow specification of tolerable loss rate.
- There are a number of performance improvements, that need to be tested and integrated:
- LossStatistics: https://git.nt.uni-saarland.de/LARN/PRRT/tree/feature/statistics-efficiency
- Coding Configuration Performance: https://git.nt.uni-saarland.de/LARN/PRRT/tree/feature/codingConfigurationPerformance
- Block Refactor: https://git.nt.uni-saarland.de/LARN/PRRT/tree/feature/block-refactor, https://git.nt.uni-saarland.de/LARN/PRRT/tree/eval/block-refactor, #22
- Avoiding copies.
- Efficient packet to buffer conversion.
- 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).