Subject: [Fecframe] My comments around draft-begen-fecframe-1d2d-parity-scheme-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2008 18:39:29 -0400

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 +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Thu, 13 Mar 2008 08:14:14 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, March 10, 2008 3:39 PM
> To: [email-masked]
> 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.
> 
> - 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
>