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

["Botzko, Stephen" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, November 30, 2006 11:23 AM
To: Botzko, Stephen
Cc: Stephan Wenger; Colin Perkins; Even, Roni; [e-mail]
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:[e-mail]]
> Sent: Thursday, November 30, 2006 7:39 AM
> To: Colin Perkins
> Cc: Adam Li; Even, Roni; Botzko, Stephen; [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt