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