RFC 5052, "Forward Error Correction (FEC) Building Block", August 2007Source of RFC: rmt (tsv)
See Also: RFC 5052 w/ inline errata
Errata ID: 1006
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Michael Luby
Date Verified: 2007-09-09
Section 9.1.2 says:
... the last source block is L-((L-1)/E) rounded down to the nearest integer)*E octets in length.
It should say:
... the last source block is L-floor((L-1)/E)*E octets in length.
Apparently, this sections has been crafted to give a formulation of
the algorithm avoiding the distinction between various cases, and in
particular a separate formulation for the "regular" corner case of
an object that can be partitioned exactly into blocks of equal size.
The formulae given in Section 9.1.2 make use of the standard
functions 'ceil' and 'floor' (restated in Section 9.1), but the
final paragraph of the section, at the bottom of page 19, tries to
paraphrase the 'floor' function (see above).
Many FEC schemes are only prepared to deal with encoding symbols of
equal size. To accommodate this, wouldn't it therefore have been
preferable to specify padding (to full size E) of the last symbol of
the last block, for the purpose of this common, default algorithm ?
--- VERIFIER NOTES ---
It is the typical case (not a non-standard case) that the object size is not
an even multiple of some nice encoding source block length, and thus
typically A_small not= A_large. Furthermore, it is the typical case that L
is not a multiple of E. Thus, what you characterize as the "regular" case
is actually quite atypical in the real-world.
Also, any application can pad out the last source symbol of a source block
if it wants if the FEC encoder/decoder can't handle it, the specification
does not mandate a particular implementation. On the other hand, it is
unnecessary, and usually wasteful, to actually send those padding bytes over
the wire, and this specification specifies what is sent on the wire and how.
This is why it is like it is.