[Robustness] teleconf for Oct 12
Terry L Anderson
tla at LUCENT.COM
Tue Oct 10 14:50:41 EDT 2000
Dear Mr. Li, dear experts,
thank you very much for your response but the question remains unsettled
Your answer is concentrated on the Packet #3. With no doubt this packet is
non-critical. Therefore, our questions was about Packet #2 and the
protection with ULP #2.
Here is the scenario in doubt again:
+ However, when considering your example in Figure 1 on the next page, we
+ a simple loss situation, for which the above statement does not seem to
+ Let us assume that out of the seven given packets, exactly (information)
packets #2 and #3
+ are lost, but all the others have been received correctly. Since packets
#1-#3 are only
+ protected with one single FEC packet, ULP #1, at level L_0, the leftmost
part of the
+ lost packets #2 and #3 can definitely not be recovered anymore.
+ If we now consider the protection strategy for level L_1, we see that the
second part of
+ packets #1, #2, #4, and #5 are protected via the respective part of FEC
packet, ULP #2.
+ But only the part belonging to packet #2 has been lost (packet #3 is not
related to ULP
+ #2), which should definitely be recoverable then.
+ Thus, we would be able to overcome the loss in packet #2 at protection
level L_1, but
+ not at level L_0, which is a contradiction to the above statement.
> The statement about the grouping rules in the document is
> describing one important general principles for any efficient forward
> scheme. It is nice to know that Mr. Gero agrees on the same principle. We
> are not intending to claim that the grouping rules in APC-1905 absolutely
> guarantees the property
Of course we agree on that. It is one of the favourable characteristics of
our approach to guarantee the recovery within this rules.
> For example, in a interleaving scheme proposed in APC-1841, even correctly
> transmitted data will have to be discarded because of the holes in
> rearranged packets.
In opposition to the UCLA proposal this data are not protected in a special
way(normal regressive profile).
Within the UCLA proposal the packets are first processed completely and then
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd