Re: [Fecframe] draft-zixuan-fecframe-source-mi ??

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> 1) Combined protection of multiple source flows
> 
> For the case where one FEC repair Flow providing protection to multiple
> source flow, the explicit Source FEC Payload ID, according to the
> "draft-fecframe-framework", has to be used no matter if the protected source
> flows is "sequenced" or not.

Where does it say this?

In section 6.3., it says: The FEC Scheme determines whether the Explicit Source FEC Payload ID field is required.  This determination is specific to each transport flow.

So, it makes a difference whether the flow is sequenced or not.
 
> 2) Single Sequenced Flow Case
> 
> Per draft-fecframe-raptor, the FEC scheme defined for "Single Sequenced
> Flow" protection works well for source packet in fixed size without explicit
> source payload ID.
> 
> But for the source packet of variable size, the source packets must be
> padded with zeros to occupy the same amount of space (equals to the length
> of Source Packet Information) in the source block for FEC encoding/decoding.
> The padded bytes are not sent, but require on the receiver side that the
> amount of repair data for recovering a lost source packet equals to the
> length of Source Packet Information. But this probably has a downside: the
> amount of repair data needed would be much more than the case where padding
> is not used, and thus impact the FEC decoding efficiency. So an alternate to

I am not sure how inefficient padding is. Is it really a better trade-off to use source fec payload id? 

> handle this issue is to not use padding, and therefore the Source Payload ID
> is still needed for making FEC works with variable source packet size.
> 
> 
> > AB: Do we really need to consider non-framework capable receivers?
> >
> > ME: I don't believe this violates our charter. But why are
> > you doing this work?
> >
> > ZZ: For RTP receivers that my use FEC but do not support the
> > FECFramework.
> 
> [zou] As we had answered Marshall, the FECFramework source packet with
> Source Payload ID lead to incompatibility to those receivers not align with
> this Framework. The draft "draft-zixuan-fecframe-source-miu" is proposed for
> solving this issue.

I am still not getting this. If RTP is used, there is no need to modify the source packets, so existing RTP receivers will have no problems. But, is it your goal to make them (i.e., the RTP receivers that don't support the framework) still benefit from the fec packets generated by an FEC scheme (which is based on framework)? 

-acbegen

 
> Zou ZiXuan, Senior Research Staff
> Media & Communication Lab
> HUAWEI TECHNOLOGIES CO.,LTD.
> 
> Address: Huawei Industrial Base
> Bantian Longgang
> Shenzhen 518129, P.R.China
> Tel: +86 0755 28789364
> Fax: +86 0755 28788317
> E-mail: tendyntu at huawei.com
> www.huawei.com
> ----------------------------------------------------------------------------
> ---------------------------------------------------------
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above. Any
> use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
> 
> 
> -----Original Message-----
> From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On Behalf
> Of Ali C. Begen (abegen)
> Sent: Thursday, September 17, 2009 9:56 PM
> To: gjshep at gmail.com; fecframe at ietf.org
> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> There were several comments from myself and some others during the meeting
> about the applicability of this draft, the validity of the problem and some
> details on the bits on the wire.
> 
> Will the authors be addressing those comments with a revision before we move
> forward?
> 
> -acbegen
> 
> > -----Original Message-----
> > From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On
> Behalf Of Greg
> > Shepherd
> > Sent: Thursday, September 17, 2009 9:47 AM
> > To: fecframe at ietf.org
> > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ??
> >
> > I'm following-up with action items from our last WG meeting in
> > Stockholm. We wanted to get some feedback from the list on potential
> > use cases for the proposal:
> >
> > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt
> >
> > ..and to ask if the WG members feels this is a draft we want to take
> > on as a FECFrame WG Item.
> >
> > Please respond by the end of next week - Sept 25th.
> >
> > Thanks,
> > Greg
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe at ietf.org
> > https://www.ietf.org/mailman/listinfo/fecframe
> _______________________________________________
> Fecframe mailing list
> Fecframe at ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe