... | ... | @@ -10,6 +10,7 @@ |
|
|
* PRRT on [riot-os](https://riot-os.org/) (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, ...)
|
|
|
|
|
|
## API
|
|
|
* Synchronized / Gap-preserving mode: This mode returns empty packets (fill-value is configurable) if they did not arrive in time.
|
... | ... | @@ -20,16 +21,20 @@ |
|
|
* Application parameters: Allow specification of tolerable loss rate.
|
|
|
|
|
|
## Performance
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
## Features
|
|
|
* 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](https://groups.google.com/forum/#!topic/bbr-dev/8pgyOyUavvY ). |
|
|
\ No newline at end of file |
|
|
* 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](https://groups.google.com/forum/#!topic/bbr-dev/8pgyOyUavvY).
|
|
|
* 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). |
|
|
\ No newline at end of file |