[AVT] Updates to draft-ietf-avt-ulp

["Adam Li" <adamli at hyervision.com>]

Chairs, Mark, All, 

An updated version of the ULP draft has just been submitted. It may also be
obtained through anonymous FTP at
ftp://ftp.hyervision.com/pub/IETF/ULP/draft-ietf-avt-ulp-15.txt before the
ID manager updates the database.

Most of the comments received in WGLC are updated into the latest version of
the draft. Thanks a lot for Mark's detailed reading and suggestions. I have
some line-by-line comments on the comments from Mark as following. 

Your helps are all very much appreciated.

Adam


A) Technical aspects with respect to FEC

A.1) Specification of the decoding algorithm

What Mark pointed out is a very valuable point to deal with scenarios when a
given payload packet is protected by multiple FEC packets at the same level.
In this document, we specify the transmission protocol and the recovery
operations, but leave the recovery algorithm to the implementer, as
discussed in Para 2 of Section 9. So I think we do not need to discuss these
cases.

A.2) Relationship between levels

First of all, I do agree that even with our restriction in protection
levels, there are finite probability that partially recovered data can be at
the higher level. That is the reason we use "almost always" instead of
"always". 

When in use, the sender will usually want to choose a protection group size
that have payload recoverable (at least for the lower level) in majority of
the cases. The 2-loss scenarios would be rare, and even under it there are
only 2 cases where partial recovery of ends happens. In additional, the
group size 2 is used in example so I don't have to draw too many blocks, and
the group size N is usually larger. The total cases goes as O(N^2) while the
partial recovery of ends goes as O(N). So I think it is fair to say "almost
always". Or how about "in majority of the cases"?

A.3) Applicability

Agreed. Updated as suggested.

B) Opinions on FEC-related aspects

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

I do agree with you that "Unequal Erasure Protection" needs to be used
carefully. It requires first breaking payload data and fill into a group of
intermediate packets, then sort-of "cross-hash" those packets into a new
group of packets to be transmitted. It is probably a little too complicated
to be summarized in a sentence in this draft, so I assumed the reader of
this section have know how both works. I am simply pointing out the strength
and comparison between the two schemes.

B.2) Value of Unequal Level Protection

Yes, it is a subtle issue as you said. And I do see your point. I usually
use relative terms and tried to avoid any strong broad assertion. I will
comb through the draft to see if there are any unnecessary overbroad
statements and will change them if I see one.

B.3) Section 5, Second Paragraph

Agreed. Updated as suggested.

C) Some technical comments on the specification text
D) Editorial

Mostly updated. Some with different wording from suggested. 



> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Mark
> Watson
> Sent: Wednesday, January 04, 2006 10:35 AM
> To: avt at ietf.org
> Subject: [AVT] RE: Working group last call: draft-ietf-avt-ulp-14.txt
> 
> 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




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