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

[zouzixuan <tendyntu at huawei.com>]

Hi, Ali
	inline

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: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Friday, September 18, 2009 7:04 PM
> To: zouzixuan; gjshep at gmail.com; fecframe at ietf.org
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> > 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
least applies to the FEC schemes involved in the scope of IETF, such as
LDPC, RS, Raptor and 1-D Interleaved Parity FEC. 

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