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

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

Adam,

I reviewed the changes and most comments seem to be addressed. Just a
few which you didn't catch:

I would still suggest removing the sentence in the first paragraph of
Section 3 which says "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." As I explained, Unequal Error Protection is
not 'more efficient', it is just a different use of bandwidth compared
to 'Equal Error Protection', with different results.

Comment C.3 - the text I suggested (and you incorporated) was intended
to replace both paras 4 and 5 - I suggest removing para 4 since it still
contains the confusing reference to different 'block size' when what you
mean is different 'protection strength'.

Comment C.9(k): you still have the text "The reconstruction operation of
the lower level MUST be performed before those of higher level is
performed' since this is an implementation issue only.", but this is an
implementation issue which should not be in the specification (the order
in which operations are performed or even whether they have an order
should not be specified in the document unless the operations are
interdependent, which in this case they are not).

Comment C.9(l): The text 'If the complete recovery operation (of all
levels) does not recover the packet to its full length, the un-recovered
part of the packet SHOULD be filled	(with any data chosen by the
implementation) to the total	length of the packet.' This is an
untestable internal implementation issue and makes no sense in a
specification.

Regards,

Mark







-----Original Message-----
From: Adam Li [mailto:adamli at hyervision.com] 
Sent: Thursday, February 23, 2006 3:46 AM
To: IETF-AVT
Subject: [AVT] Updates to draft-ietf-avt-ulp


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. 






_______________________________________________
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