Warning: This is an old version. The latest stable version is Version 11.0.1.
In this section we give some basic advice on how to parameterize your code. As a general disclaimer, this does not guarantee any specific performance from the code, but means that the parameters are reasonable.
The following is based on rough back-of-the-envelope calculation, and simplifies a lot of things. For more in-depth analysis and help please contact firstname.lastname@example.org.
If you see an unfamiliar term used, try to visit the Definitions section and you should find a description.
We will look at how to specify two settings:
The coding rate is often denoted
n is the total number
of symbols to send out of which
k is the original data and
r = n - k
is the repair symbols. The
coding rate is computed as
As a rule of thumb, we need to specify the
coding rate lower
than one minus the loss rate.
(1-0.5) = 0.5e.g.
k=1our rate is then
k/n = 1/2which is just enough to cope with the packet loss (in the worst case). In practice, you would probably want to lower the rate.
(1-0.25) = 0.75e.g.
k=2our rate is then
k/n = 2/3 = 0.66which should be enough to cope with the packet loss.
If we want to minimize delay we should try to specify
k as low as
possible. Since this means we will generate repair traffic more often.
In general, we should try to minimize
(n,k) but still within
a comfortable margin of one minus the packet loss rate. With a smaller
(n,k) parameter, we can interleave repair packets more often, and
therefore the decoder will more often have the chance to decode
and release a symbol.
If we select a coding rate of
(n=3,k=2), this means that after every
k=2 packets we send
r=1 repair packet.
This has the same coding rate as a
(n=6,k=4), but here we send two
repair packets after every four packets. We therefore wait more
before generating repair.
Essentially, the coding window can be determined based on two different considerations:
In the latter case, the right parameter combination heavily depends on the target platform (e.g. high-end server or limited embedded device). Depending on the use-case, benchmarking may be a good way to find a suitable set of parameters for the given platform. In other cases please contact email@example.com.
For the delay-constrained use-case, it is usually possible to determine the coding window based on the delay requirement.
Say we have an application that generates a fixed stream of 1 MBps and has a latency requirement of 60 ms. If we choose our symbol size to 1400 bytes, then we find that our coding window can be:
The decoder receives symbols encoded with the encoder’s window. But, it may itself choose to have a larger decoding window. This might be advantageous, because even though a symbol is now considered “too” old, it may still be useful for decoding symbols that are still within the deadline.
As a general rule of thumb, specifying the decoding window as two times the encoding window works well in most cases.
If the decoding window is smaller than the encoding window the decoder will not be able to use any repair symbols.