Subject: [AVT] RE: (Stephen Botzko's email)

From: "Botzko, Stephen" <[email-masked]>
Date: Thu, 30 Nov 2006 12:35:51 -0500

Hi Adam

(1) Using FEC group of size 2 or 4 for an error rate of 1% is definitely
not how the FEC performance is discussed and measured, obviously.
I'm not sure I understand this.  If you have a better example to
suggest, I'd be interested in hearing it (either on or off the list).

(2) The concept of using unequal error protection is based on that the
codec is somewhat error tolerant and not all data are of the same
importance. Using "complete recover rate" as a metric here is definitely
not suitable.
The argument was more that the alternative equal-protection mode (with
one level of protection) was more effective than ULP at protecting the
critical data.  I could have computed the unrecovered packet loss rate
for L0 and L1 and compared that to the alternate coding, though I don't
think it would have changed the conclusion. 

(3) Yes, one can always do multilevel protection with one level FEC by
dividing data into multiple packets, and apply different FEC to
different packets. However, that involves too much protocol overhead.
I wasn't meaning to imply that ULP should be changed to do that.

I guess there are two ways of looking at ULP.  One way is that it simply
reduces the FEC overhead associated with RFC 2733 in situations where
you don't need to protect all the data in the stream to the same degree.
I'd say it does accomplish that. 

The second way (which I've been taking) is to compare ULP with
systematic code performance, where I don't think it fares so well.  If
my approach is more appropriate to future FecFrame discussions, I can
certainly table it for now.

Stephen

-----Original Message-----
From: Adam Li [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 11:23 AM
To: Botzko, Stephen
Cc: Stephan Wenger; Colin Perkins; Even, Roni; [email-masked]
Subject: Re: (Stephen Botzko's email)

Hi Stephen Botzko,

I am afraid I can not agree on your conclusion. I have the following
comments.

(1) Using FEC group of size 2 or 4 for an error rate of 1% is definitely
not how the FEC performance is discussed and measured, obviously.

(2) The concept of using unequal error protection is based on that the
codec is somewhat error tolerant and not all data are of the same
importance. Using "complete recover rate" as a metric here is definitely
not suitable.

(3) Yes, one can always do multilevel protection with one level FEC by
dividing data into multiple packets, and apply different FEC to
different packets. However, that involves too much protocol overhead.
That's in additional to the complexity of disassembling and reassembling
the data into packets at both end. Multilevel FEC is a much more elegant
and simple solution.

Adam

Botzko, Stephen wrote:
> Hi Stephan
>
> Of course, I agree that if you are using a single repair packet per 
> FEC block that XOR is the way to go.  In fact it is optimal, since it 
> is a systematic code in that case.
>
> I think we might disagree on the utility of multiple repair packets 
> per FEC block.
>
> In the ULP draft example (figure 1), we are sending two repair packets

> for every 4 data packets.  ULP FEC packet #1 is of course smaller than

> ULP FEC packet #2.
>
> Assume (for purposes of illustration) that the L0 data is 33% of the 
> flow, and L1 is an additional 33%, and that the packet loss rate is
1%.
>
> The probability of recovering all the L0 data intact (across the two 
> L0 groups in the figure) is about 0.9994.  The odds of recovering all 
> the
> L1 data across the larger L1 group is about 0.9990 (fairly close to
L0).
> The probability of receiving all the remaining unprotected data intact

> is 0.9606.
>
> Alternatively, we could re-packetize the original 4 data packets into 
> 12 smaller packets, and add 3 FEC packets using a systematic code.  
> The payload overhead of this is the same as the ULP example (though of

> course there is somewhat more IP overhead), and the latency matches 
> the
> L1 latency.  The probability of recovering all the data in the group 
> intact is 0.9999875 (according to Excel).
>
> So the alternative method protects the entire stream more effectively 
> than the ULP example protects L0.  The computational complexity is 
> undoubtly higher, and we are assuming that the L1 protection latency 
> is acceptable.
>
> All this is not to say ULP offers no value.  Just that the utility
> (IMHO) is quite limited, esp. given that we already have 2733. I'd 
> love to hear a counter-example.
>
>
> Stephen Botzko
>
>
>
> -----Original Message-----
> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Thursday, November 30, 2006 7:39 AM
> To: Colin Perkins
> Cc: Adam Li; Even, Roni; Botzko, Stephen; [email-masked]
> Subject: Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt
>
> Hi Colin, all,
>
> On Nov 28, 2006, at 6:08 PM, Colin Perkins wrote:
>
>   
>> [...]
>> No - given the advances since RFC 2733 was published, I think it 
>> worthwhile to include further justification and explanation of where 
>> this fits in with other FEC schemes.
>>     
>
> Some fairly advanced media formats offer tricks that in our view allow

> to employ simple XOR FEC (only) without significant delay increase.  
> We
> (Nokia) have proposed such tricks in 3GPP SA4. There, we protect two 
> important media packets (whatever that means for the
> specific media codec) with one FEC packet.   I don't want to re- 
> create ongoing discussions in SA4 here, where the usefulness of our 
> trick is challenged, but I can provide pointers to documents for those

> interested.  (Please contact me in private.  We also have academic 
> work in preparation, which should be available in the foreseeable
future).
>
> IMHO, there is little point in evaluating Reed-Solomon or any other 
> "higher" FEC code for an RTP payload format.  If your delay tolerance 
> is such high that you can afford multiple repair packets per FEC 
> block, go use fecframe WG's technology, or use feedback based repair 
> (whatever fits your application better).  When using only a single 
> repair packet per FEC block, there is no difference between XOR FEC 
> and the other FEC schemes.
>
> With respect to the uneven protection feature, and in response to
> Stephen: yes, there are media formats that could employ uneven 
> protection.  Examples include G.723.1 with Annex C enabled, H.263 with

> Annex V enabled, H.264 in extended profile or in baseline when
> RFC3984 aggregation packets are used, and these packets are populated 
> in a smart way.  Yes, no one is using any of these in the way they 
> could be used, but are we all sure that's not a chicken-and-egg
problem?
>
> In consequence, let me speak in favor of moving the ULP draft finally 
> forward.  Yes, there is value in adding some discussion why Reed- 
> Solomon (or any higher FEC code) does not make much sense, perhaps 
> along the lines of point 1 above.  But then, PLEASE, let's call it a 
> day.  18 revisions are enough.
>
> Regards,
> Stephan
>
>
>
>   

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Adam Li <[email-masked]>
Date: Thu, 30 Nov 2006 13:12:53 -0800

Hi Stephen,

Thanks for your reply.
> suggest, I'd be interested in hearing it (either on or off the list).
FEC is a trade off between bandwidth overhead and loss recovery ability.
What I mean there is that in general the strength of the protection
applied is based on the channel conditions. For example, for 1% loss
rate one would likely to use a group size of 48. Using a group size 2
would mean way too much overhead for an extremely small gain. Figure 1
of the draft (which uses group size of 2) is for illustration purpose.
> think it would have changed the conclusion. 
If I understand right, you are basically suggesting breaking down the
data into smaller packets so unequal error protection on the data can be
achieved by equal protection on the packets (which each contains a small
piece of the overall data). If that's what you mean, then the
performance of that is the same as the multi-level protection. And it
will likely have a higher protocol overhead and implementation complexity.
> certainly table it for now.
There are a few issues. The first thing is when you compare code
performance, it is necessary to define how the performance is measured,
particularly when we are talking about media payload in RTP in the
context of using unequal error protection. That is also the point I
wanted to make above.

Another point that often gets overlooked is that unequal error
protection is a superset of equal error protection. You can always use
only one level in ULP and set the length to cover the whole packet.

I am happy to continue the discussion with you (either online or
offline) on topics about FEC. I hope the discussion we have here so far
at least has answered the questions particular to this draft, and that
you have no objection having the draft moving forward (maybe with some
modifications to clarify some points).

Regards,

Adam