[AVT] RE: Working group last call: draft-ietf-avt-ulp-14.txt

["Mark Watson" <mark at digitalfountain.com>]

All,

I was asked by the Chairs to review this draft and forward my comments to the list. Although it looks in principle fine to me, I had quite a few specific comments, which are listed below. I have tried to include concrete proposals as much as possible (which of course makes the comments look even longer) with the aim of avoiding any unnecessary delay.

The comments which are in four categories:

A) Some technical aspects with respect to FEC
B) Some opinions on the FEC-related material, especially in the introduction
C) Some technical comments on the specification text
D) Editorials

A) Technical aspects with respect to FEC

A.1) Specification of decoding algorithm

The draft specifies how to recover (potentially only part of) a source data packet from a received FEC packet. However it is possible to construct FEC codes with this scheme in which a given source packet is protected by more than one FEC packet and in this case there are (at least) three approaches to decoding which will yield rather different results:

(a) each parity packet is checked to see if it can recover any lost source packets and if not it is discarded
(b) as (a), except parity packets are kept and re-checked recursively as other lost packets are recovered to see if they can recover any lost source packets
(c) a complete parity matrix is constructed and gaussian elimination (or equivalent) applied to solve for as many source packets as possible

For example, a block of 31 source packets could be protected by 5 FEC packets constructed according to a Hamming Code. Applying (a) will allow recovery of between 1 and 5 lost packets depending very much on exactly which packets are lost (i.e. there are many patterns of just 2 lost packets which would be unrecoverable).

On the other hand, with (b) then it will always be possible to recover from 2 lost packets and in many cases more than that.

Further, if an extended Hamming Code was used, by adding an additional FEC packet which is the sum of all 31 source packets, then recovery from 3 lost packets is always possible but only with algorithm (c).

This point is not even mentioned in the specification (that I could find), but it is rather important for the sender to know the capabilities of the receiver in this regard in order to determine the amount and type of FEC packets to generate. In my opinion it should be required that receivers apply at least algorithm (b).

A.2) Relationship between levels

It is stated in Section 5, last para, and Section 9.2.2 last para that the requirement for packets protected at level p to also be protected at level p-1 ensures - or makes very likely - that the situation in which only a later part of a packet can be recovered is avoided. I do not think this is generally the case and requires careful design on the unequal protection scheme (i.e. which packets are protected by which FEC packets at which levels).

For example, in Example 10.3, if Packet B and ULP packet #1 are lost then the level 1 part of Packet B can be recovered but not the level 0 part. In this example, loss of any one packet can always be completely recovered - and indeed this could be achieved with ULP#2 alone, so it is the case in which two packets are lost which is supposed to benefit from ULP. Of the 15 such cases, 4 are completely unrecoverable, 2 are completely recoverable, 1 does not require any recovery, 6 provide partial recovery of the beginning of the packets and 2 provide partial recovery of the end of the packets. So, it is not true to say that the 'partial recover of the higher level only' situation is avoided or even 'almost always' avoided.

So, I would suggest removing these statements in Section 5 and Section 9.2.2, or - better - including some analysis and recommendations for the sender to reduce such possibilities. 

A.3) Applicability

Section 16 starts with "The generic FEC algorithm specified in this document is designed to deal with any type of packet loss occurring in transmission."

Firstly, 'FEC algorithm' would usually be interpreted as including the pattern of packet protection (i.e. which packets are protected by which FEC packets) and this is not something specified in the document. Secondly, the ability to deal with 'any type of packet loss' is a rather broad claim which is not in practice true for this scheme due to the very limited maximum block length.

I would suggest replacing the first sentence of section 16 with:

"This document describes a generic protocol for Forward Error Correction supporting a wide range of short block parity FEC algorithms, including for example simple and interleaved parity codes and Hamming Codes. The scheme is limited to interleaving parity codes over a distance of 48 packets."

The words 'interoperable between' in the next sentence should be replaced with 'backwards compatible with' since interoperable carries the implication that the scheme actually works (interoperates) to protect data with hosts which do not support it!

B) Opinions on FEC-related aspects

B.1) "Unequal Level Protection" vs "Unequal Erasure Protection"

There is a little bit of discussion of this issue in Section 16 (Applicability Statement) but that is all in terms of comparison with the specific UXP scheme (which I understand is not being progressed right now).

It would be useful, I think, to clearly explain the different between Unequal Level Protection - where different *parts* of the packets are protected to different extents - and Unequal Erasure Protection - where different *packets* are protected to different extents.

In fact, this draft can implement both, since there is no requirement to protect all packets to the same extent. However, in general one has to be rather careful with Unequal Erasure Protection: providing multiple non-zero levels of protection for different groups of packets can in some cases be counter-productive since you lose more by breaking the stream into smaller groups than you gain by the opportunity to reduce the protection on the less important packets. This is because the number of errors found in a given block will be closer to the average error rate if the block is larger and so for a fixed percentage overhead the probability that the block can be corrected will be higher.

B.2) Value of Unequal Level Protection

There are many statements, specifically in the introduction, claiming that Unequal Level Protection is makes more efficient use of the channel, is more robust to errors or generally more appropriate for some class of applications. I think the value of unequal protection is overstated and few of the value statements say what the comparison is being made against. 

For example, in the first paragraph of Section 3: "By using unequal error protection provide by the extended mode, this scheme can make more efficient use of the channel bandwidth, and provide more efficient error resilience for transmission over error prone channels." 

In fact ULP is per se neither more nor less 'efficient' than protecting all of the packet to the same extent - it is just a _different_ way of using the FEC protection bandwidth which may or may not be more appropriate depending on the application. Take video as an example: broadly speaking and other things being equal, the difference that would be seen between Unequal Level Protection and Equal Level Protection (for want of a better term) would be that in the ULP case one would frequently see minor glitches in playback but major glitches would be rather rare, whereas with 'Equal Level Protection' one would see major glitches slightly more often in return for a complete absence of minor glitches.

The considerations and trade-offs are highly dependent on the application, source coding (which also affects bandwidth usage), error concealment, error rates and of course ones opinion on what behaviours are most important to the user in terms of Quality of Experience.

So, I don't think it is correct to make the kind of broad statements that are made in the introduction: the problem is altogether more subtle.

B.3) Section 5, Second paragraph:

"In general, the FEC protection operation is a trade off between the bandwidth and the protection strength. A smaller group size will generate stronger protection, and hence have a better chance to recover the protected payload when loss occurs. But on the other hand, it will generate FEC data in higher frequency, and hence uses more channel bandwidth."

The general point about bandwidth vs protection is correct but it is incorrect to link this to 'group size' except in the case of a single parity packet per group. In the general case the opposite is true in that a fixed amount of protection (in terms of percentage bandwidth expansion) will provide weaker protection when applied in smaller groups.

I suggest: "In general, the FEC protection operation is a trade off between the bandwidth and the protection strength. The more FEC packets that are generated as a fraction of the source media packets, the stronger the protection against loss but the greater the bandwidth consumed by the combined stream."


C) Some technical comments on the specification text

C.1) Section 3: 2nd para: "The protection length, offset mask and payload type are sufficient to signal the forward error correction schemes based on arbitrarily defined parity protection with little overhead."

In fact the FEC schemes supported are not arbitrary due to the very limited block length (48 packets) and the decoding issue mentioned above.

I suggest replacing this sentence with: "The protection length, offset mask, payload type and Sequence Number base fully identify the parity code applied to generate the FEC packet." 
 
C.2) Section 4: 2nd para: "To be effective, ..." insert 'most' before effective.

C.3) Section 5, 4th and 5th para. These paragraphs introduce the unequal level protection concept but firstly they are not very clear about how it works and secondly they assume that stronger protection equates to shorter block size. This is correct if "block" is interpreted as "the media packets protected by a single parity packet", but it is perhaps more natural to consider a block to be a consecutive set of packets which might be protected by multiple FEC packets. Here is some suggested replacement text:

"A method to apply unequal error protection is to separate the packet into sections of decreasing importance and to apply protection of different strength to each portion - the sections are known as 'levels' and each FEC packet gives the number of bytes at each level. All media packets protected by a given FEC packet must be divided into sections in the same way and a single FEC packet can carry parity data for multiple levels. The protection operation is applied independently at each level."
 

C.4) Section 6: I am not sure I follow the point being made here. The second paragraph claims the encoding is 'very efficient', but it is not clear what aspects are being referred to and what the scheme is being compared with. I suggest replacing the second paragraph with: "This approach has the advantage that media packets can be interpreted by receivers which do not support FEC."

C.5) Section 7.3: Timestamp: it is not clear to me what purpose it serves to timestamp the FEC packet with the time it was sent, since there are many strategies for timing the sending of the FEC packets relative to the original stream. It might be more useful to timestamp it with the same time as the last packet protected by this FEC packet, since that is the time in the stream playout after which the FEC packet is useless. However, this would not result in monotonically increasing timestamps.

C.6) Section 7.4, paragraph 7 (computation of length recovery). The description would be clearer with the insertion of "each of the" before each of the first two occurances of "media packets".

C.7) Section 7.5, 4th para after Figure 5: "... associated with the ULP FEC packet." to "... associated with the ULP FEC packet at that level."

C.8) Section 7.5, last para: "(due to the presence of the FEC headers)" (pluralise 'header').

C.9) Section 8: The terminology 'bit strings' is used in a rather poorly defined way to refer to the data taken from media packets and arranged so as to apply the protection operation. The parity operation is then applied 'across the bit-strings', which is not as clear as it could be. The construction of the FEC protection data for higher levels is rather vaguely applied (on first reading I had a lot of trouble understanding it). 

Also, personally, I am not a fan of writing protocol specification in functional terms (e.g. 'copied') which somehow make assumptions about some underlying virtual machine which performing the operations.

A suggested more rigorous description could be as follows:

a) Section 8.1: Replace the 1st two paras following the bullet list with "If the lengths of the media packets to be protected are not all equal, then the bit string for each packet is padded out to the length of the bit string for the longest packet using zero bits. The resulting bit string is known as the 'protected data' for the media packet.

The resulting protected data for the media packets is used to generate an 'FEC bit string'. The FEC bit string is equal to the bitwise exclusive OR of the protected data for each of the media packets."

b) 8.2.1, replace with:

"The protection operation in the extended mode on protection level 0 is very similar to the protection operation in the baseline mode as described above. The only difference is that only the first K bits of the FEC bit string (constructed as described above) are included in the FEC packet, where:

K = L0 * 8 + 96

L0 = protection length at level zero (in bytes)

The additional 96 bits corresponds to the length of the RTP header up to the end of the SSRC field."

c) 8.2.2, replace with:

"The protection operation at level N is again similar to that at level zero. The FEC bit string is constructed as described above, remembering that the set of packets protected at level N may be different from those protected at other levels by the same packets.

Assuming that the bits of the protected data, and thus the FEC bit string are numbered from zero, with bit zero corresponding to the first bit of the RTP header, then the bits included into the FEC packet for level N correspond to bits S(N) to S(N+1)-1 inclusive of the FEC bit string, where:

S(N) = 96 + 8 * sum{ Li : 0 <= i < N } for N = 1, ..., Nmax+1

and Li is the protection length at level i, in  bytes and Nmax the highest level of protection.

The bit string included in the FEC packet for level N thus has length 8*LN bits and is known as the 'FEC bit string at level N'."

d) 9.1, item (1), replace 'bit string' with 'protected data'.

e) 9.1, item (2), replace 'bit string' with 'FEC bit string'

f) 9.1, item (3) - remove - padding is already part of the 'protected data'

g) 9.1, item (4) - replace: "Calculate the 'recovery bit string' as the exclusive OR of the protected data for each of the media packets in T and the FEC bit string for the FEC packet in T.

h) 9.2.1, first paragraph, replace: "Reconstruction in the extended mode at level 0 is similar to reconstruction in the baseline mode described above except that at step 14, the number of bytes from the recovery bit string included into the recovered packet is equal to the protection length at level 0 (L0)."

i) 9.2.2, 1st para, replace: "Let T be the set of packets (FEC and media) which can be combined to recover some portion of a media packet xi at protection level N. The recovery operation allows bits S(N) to S(N+1)-1 of the protected data for a media packet to be recovered. This bit string, with length 8*LN bits, is known as the 'recovery bit string at level N'. It is assumed that the earlier parts of the protected data (bits 0 to S(N)-1) have been recovered by recovery operations at lower levels."

j) 9.2.2, items (1)-(3) - item (1) especially is completely unparsable IMO - replace these items:

"(1) The recovery bit string at level N is equal to the bitwise exclusive OR of bits S(N) to S(N+1)-1 inclusive of the protected data of each of the media packets in T (constructed as described in Section 8.1) together with the FEC bit string at level N from the FEC packet in T."

k) 9.2.2, Item (4) replace 'payload' with 'protected data' (concatenation of the recovery bit strings results in the protected data, not the payload). Remove 'The construction operation of the lower level MUST be performed before those of higher level is performed' since this is an implementation issue only.

l) 9.2.2, Item (5), remove second sentence - this is an implementation issue only.

D) Editorial:

D.1) Section 7: Second para: replace "in-bound" with "in-band", "signal" with "signalling", "Mode can be changed ..." with "The mode can be changed..."

D.2) Section 7.3: Replace title "RTP Header of FEC Packets" with "RTP Header for FEC Packets"

D.3) Section 7.3: Replace "The RTP header of FEC packets are used when the FEC are sent ..." with "The RTP header for FEC packers is used when the FEC packets are sent ..."

D.4) Section 7.5: Replace title "FEC Header of FEC packets" with "FEC header for FEC packets"

D.5) Section 7.5: Item (c) of list above Figure 5: replace 'Please' with 'Note that'

D.5) Section 8.2.1: 'packages' -> 'packets'

D.6) Section 9.1, item 15, remove the word 'to' from the end of the sentence

D.7) Section 10, second para, replace '...in primarily related to the secure RTP...' with '... is primarily applicable in the case of secure RTP...'

Best regards,

Mark Watson

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt