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.
> 
> The above case is not from the framework draft. I mean in this case, the
> Source FEC Payload ID specified in the fecframework draft is a must, at

In which cases you are considering is the *explicit* source payload id a must?

> least applies to the FEC schemes involved in the scope of IETF, such as
> LDPC, RS, Raptor and 1-D Interleaved Parity FEC.

Source fec payload is of course required but in sequenced streams, it is already in the source itself. What else do we need?
 
> >
> > > 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?
> As I explained above, in principle, it is better to use source fec payload
> id.

I am sorry, I am not following this.

> -zou
> >
> > > 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)?
> 
> That is the reason why we give the above case of multiple source flows.
> There is need to modify the source-packets in that case, as explicit source
> payload ID is needed.

First of all, there were concerns raised in the meeting regarding the use of multiple source RTP streams in FEC encoding. Not all RTP streams can be simply encoded in the same FEC source block because of the clock issues.

Assuming that you are using source RTP streams that could be combined, you still don't need explicit source payload IDs. Finally, for RTP receivers that do not support the FEC framework, you can write an RTP payload format draft as I did for the 1-d interleaved fec. Using an fec scheme based on the framework is not really a requirement and does not make any sense for those who don't support the framework anyway.

Cheers,
-acbegen

> -zou
> >
> > -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