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

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

Hi Adam

I agree that it is important to define how performance is measured.  To
some degree, this depends on the application requirements, so I think
there is more than one right way.

I agree also that the strength of the protection should be based on the
channel conditions.  I would add that there is also a need to consider
both the latency bound required by the application and the QOS goal.

I don't think that we're in sync yet, but I think that it makes more
sense to go off-line (or pick it up later on in FecFrame). 

I do not object to ULP going forward, because I think it does provide
more efficiency than RFC 2733 for applications that can exploit unequal
protection. I am certainly not an advocate (at least not at this point),
but I will not object.

Regards, 

Stephen Botzko

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

Hi Stephen,

Thanks for your reply.
> 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).
>   
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.
> 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.
>   
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.
> 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.
>   
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

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