Subject: [AVT] (no subject)

From: "Botzko, Stephen" <[email-masked]>
Date: Thu, 30 Nov 2006 10:45:50 -0500

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 08:22:38 -0800

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