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

[zouzixuan <tendyntu at huawei.com>]

Hi, Ali
	> > 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?

In case of a RTP Video flow and its coupled RTP audio flow within a RTP
session. 
-zou

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

We think there is still need to modify the source packet if RTP is used,
given "the case of a RTP Video flow and its coupled RTP audio flow within a
RTP session " stands.
-zou

 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)?
Nope, our goal is to make those (RTP receiver) who don't support the
framework still can parse and process the source packets. That's why we
brought up this draft, proposing a packet format for carrying the source
payload ID in a flow separated from the source packet flow for sequence-flow
case, where source packet is not modified. Your point against our draft, in
my understanding, is that the source payload id is essentially not necessary
for RTP (i.e. sequence flow). IMO, I do not agree with your point. So I
raised the above case - a Video RTP flow and its coupled audio RTP flow
within a RTP session, for which your point would not stand.

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

So a question here is whether we can ignore the coexistence of framework and
non-framework clients in practice. Our intention is to make our proposal a
complementary in FECFramework to cover the client diversity.


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: Saturday, September 19, 2009 4:45 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
> 
> 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