Re: [Fecframe] My comments arounddraft-begen-fecframe-1d2d-parity-scheme-00

["Ali Begen (abegen)" <[e-mail]>]

Hi Magnus,

Thanks for your summary. Regarding your comments:

- Appropriateness issue: 
Yes, we agree that it fits the framework as a specialized FEC scheme.
Indeed, it is an FEC scheme (so specialization should be OK to some
extent) and has broad selection of use cases.

We will look into the issue of combining multiple source flows and
generate a single repair stream. At first look, this is not very trivial
and seems to be limiting for some of the use cases. I will report more
once we can get a better idea of how feasible it will be to do it.

- The feedback issue:
We believe feedback is an important component of any FEC scheme. The
design team earlier decided to make it "recommended" for the individual
FEC schemes and CDPs to support feedback and the type of the feedback
reports. We chose RTCP instrumentation for the obvious reasons, as it
provides many good features and abilities for reporting feedback:
regular RTCP RRs, extended reports, etc. 

However, I do understand that there is a need for a wider discussion for
the feedback issue before the WG proceeds with any FEC scheme. I'll post
the write-up we came up with after the design team meeting and I am
hoping it will be a good starting point for discussion.

Thanks,
-acbegen


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Monday, March 10, 2008 3:39 PM
> To: [e-mail]
> Subject: [Fecframe] My comments 
> arounddraft-begen-fecframe-1d2d-parity-scheme-00
> 
> Hi,
> 
> In today's WG session I did appear quite negative to this 
> draft. I am sorry that I wasn't better prepared and had read 
> and thought about this before.
> 
> Let me try to put down my comments here and with some hindsight.
> 
> - Appropriateness in the FEC framework: Yes, this does fit 
> the framework as a rather speciallized FEC code that results 
> in one repair stream for every SSRC in a single RTP session. 
> That is quite far from a more generic FEC scheme that can 
> take multiple streams and combine them etc. 
>    In fact it is very similar to the already existing RTP 
> payload level FEC mechanisms like ULP (RFC5109). Thus, it 
> seem to leverage very little of the framework and instead be 
> very much something that could be done in AVT.
> 
> - The selection of RTP/UDP as repair stream transport layer. 
> I don't think this really is a FEC scheme but rather a 
> instantiation of the FEC framework using a component that 
> haven't been much discussed to my knowledge. I do understand 
> that it can provide feedback on how well the repair stream is 
> delivered to the receiver(s). Which actually is a good point 
> for general deployment. However in that case one maybe need 
> to consider what general feedback that a FEC framework 
> instance should provide towards the sender, i.e. including 
> both source and repair stream related statistics. Something 
> to think about and actually should make it way into the framework.
> 
> So I primarily would like to get the issue of the repair 
> stream feedback mechanism and what the WG think is suitable 
> for this before this is adopted anywhere.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe
> 
_______________________________________________
Fecframe mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/fecframe