This section contains different simulations in a general channel setting.
We model this with packets being transmitted one-at-a-time and with added constant link-latency.
In general, we wish to showcase the packet loss, that remains after retransmission/repair attempts (residual packet loss) and the added per-packet-latency for Rely against 4 different codecs:
The latency and residual packet loss are therefore important parameters to minimize in order to maximize the Quality of Service in many different use-cases.
Example use-cases could be some real-time sensors sending data to a monitoring-station, video conferencing with low delay and high resolution, etc.
We also simulate these codecs using a bursty source, that is a channel where multiple packets are sent simultaneously with a fixed interval. An example of this in a use-case is a video stream, where frames are sent with a fixed interval.
Residual packet loss:
The general FEC codecs are block codes. Block codes are memoryless, meaning that if a packet is lost after the code attempts to correct it, the packet is lost.
Rely is a Sliding-Window code. It has memory of a ‘window’ of packets, giving it more leeway to fix an unlucky situation, where too many packets were lost. This adds more consistent reliability.
ARQ is a totally reliable protocol given full leeway to retransmit as many packets as possible.
ARQ actively trades latency for reliability, while Rely trades extra bandwidth for reliability.
Latency:
In order to level the residual loss playing-field, we have allowed the FEC algorithms to operate on larger repair intervals than Rely.
This is an active trade of latency for reliability for block codes. Hence Rely will most likely outperform these.
ARQ will add much latency than Rely given the retransmissions. Rely will fix most lost packets within the following 2 repair intervals of packets, which will add negligible latency in a regular-high bandwidth stream.
Table Of Contents: