Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ??
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ??
Hi,
As I stated previously, I do not fully understand the motivation for using a separate flow for conveying FEC payload mapping information.
A generic mapping scheme for building source blocks of the variety of practical FEC codes is a good idea, however I believe that this should be indicated in the designated repair flow.
Until it is so, I don't believe that we should adopt draft-zixuan-fecframe-source-mi as a working group item.
Best regards,
Einat
-----Original Message-----
From: Greg Shepherd [mailto:gjshep at gmail.com]
Sent: Friday, October 02, 2009 4:56 PM
To: Einat Yellin (Lachover)
Cc: zouzixuan; Ali C. Begen (abegen); tme at multicasttech.com; fecframe at ietf.org
Subject: IS: Working Group Item? was: Re: [Fecframe]draft-zixuan-fecframe-source-mi ??
Thank you for the discussion. I think we have enough information in
this thread to make a determination if we want to take on this work in
the FECFrame Working Group.
Please respond to this message and indicate whether or not you feel we
should adopt:
draft-zixuan-fecframe-source-mi
.as a working group item.
Thanks,
Greg
On Mon, Sep 28, 2009 at 11:31 PM, Einat Yellin (Lachover)
<Einat at radvision.com> wrote:
>
>
> -----Original Message-----
> From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On
> Behalf Of zouzixuan
> Sent: Monday, September 28, 2009 10:57 AM
> To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover);
> tme at multicasttech.com; gjshep at gmail.com; fecframe at ietf.org
> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??
>
> Hi, Ali
>
>> I am not questioning backward compatibility, I am questioning the cost
> for
> it
>> and the scenarios where we want backward compatibility. Einat did a
> good
>> summary, so now the WG needs to provide input.
> You mean there should be some input on backward compatibility to the
> framework.
>
>
>> Regarding your example, putting the audio and video packets into the
> source
>> blocks as they are available does not seem to be a good design choice
> to
> me.
>> When I say "systematic," I mean you can create your source blocks in a
>> deterministic way (such as 4 packets from stream 1, one packet from
> stream
> 2).
>> Variable-packet size can be handled.
>
> In this "systematic" case, how could we know the position of a packet in
> the
> source block?
> [Einat] There are different ways to signal the source block structure.
> In our draft we followed rfc 5109 and used the 'base' (first) RTP
> sequence number along with a bitmap. This works for the cases where what
> matters is which RTP packets belong to this FEC source block and the
> order of the packets in the FEC source block is deterministic (from
> lower SN to higher SN and from lower flow ID to higher flow ID). If a
> more detailed structure of source block is needed then I agree that the
> bitmap is not enough. Still, this information can be sent as part of the
> repair packet header which IMO makes more sense.
>
> 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: Monday, September 28, 2009 1:40 AM
>> To: zouzixuan; Einat Yellin (Lachover); tme at multicasttech.com;
>> gjshep at gmail.com; fecframe at ietf.org
>> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>>
>> I am not questioning backward compatibility, I am questioning the cost
> for
> it
>> and the scenarios where we want backward compatibility. Einat did a
> good
>> summary, so now the WG needs to provide input.
>>
>> Regarding your example, putting the audio and video packets into the
> source
>> blocks as they are available does not seem to be a good design choice
> to
> me.
>> When I say "systematic," I mean you can create your source blocks in a
>> deterministic way (such as 4 packets from stream 1, one packet from
> stream
> 2).
>> Variable-packet size can be handled.
>>
>> Cheers, acbegen.
>>
>> > -----Original Message-----
>> > From: zouzixuan [mailto:tendyntu at huawei.com]
>> > Sent: Sunday, September 27, 2009 5:59 AM
>> > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen);
> tme at multicasttech.com;
>> > gjshep at gmail.com; fecframe at ietf.org
>> > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> >
>> > Hi, Einat, Ali
>> > Similar to Einat's explanation on "backward compatible" as
> stated
>> > your draft , our intention is to keep source packet unmodified
> without
>> > adding source payload id to it. And therefore the non-framework
> client
> can
>> > interpret the source packet. But I'm still not sure if the "backward
>> > compatibility" we are referring to here is considered a valuable
> requirement
>> > in FEC framework.
>> >
>> > I'd like to again use the example we gave in the previous
> thread we
>> > replied to Ali's doubts to explain the need of source payload id for
> RTP
>> > flow. Ali, sorry, I was supposed to gave more detailed information
> on
> this.
>> > .
>> > Here are several assumptions on this example:
>> > 1) We assume a FEC-protected audiovisual stream which is
>> > combination of a video and a audio RTP flow. ID 0 identify video
> source
>> > data, and ID 1 identify audio source data. The definition of ID can
> be
>> > conveyed through SDP
>> > 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8
>> > bytes, as is shown.
>> > 3) A video or audio source packet is fed into a source block in
> an
>> > First-come-First-serve order in which the video and audio packets
> are
>> > generated.
>> >
>> > In which case we think the source-pay-load ID is needed. For
>> > backward-compatibility, the source payload id can be conveyed in an
> separate
>> > flow, which could be either an additional flow or the repair flow.
>> >
>> > Ali, would you please give a more details on "systematic
> approach"?
> I'm
>> > not following this.
>> >
>> > 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6
>> B0,7
>> > B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0
> 0
>> >
>> > 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5
> B1,6
>> > B1,7
>> > B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15
> B1,16 0
>> > 0
>> >
>> > 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5
>> > B2,6 B2,7
>> > B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15
> B2,16
>> B2,17
>> > B2,18
>> >
>> > 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5
> B3,6
>> > B3,7
>> > B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0
> 0
> 0
>> > 0
>> >
>> > 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5
> B4,6
>> > B4,7
>> >
>> > So here I think if we want to have answer on the necessity of the
> things
> in
>> > our draft, we need to at first have conclusions on the following: 1)
> whether
>> > the "back compatibility" Elinat and me are referring to is a real
> issue
> to
>> > be considered in FEC framework, And 2) if some cases like this one,
> which
>> > demands source payload id, stands and is representative.
>> >
>> > Cheers
>> > 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: Einat Yellin (Lachover) [mailto:Einat at radvision.com]
>> > > Sent: Thursday, September 24, 2009 1:24 PM
>> > > To: zouzixuan; Ali C. Begen (abegen); fecframe at ietf.org
>> > > Cc: tme at multicasttech.com
>> > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> > >
>> > > Hi,
>> > > Backward compatibility is a major requirement for FEC framework,
> no
>> > > doubt. I believe that the discussion here is around whether a
> separate
>> > > flow for FEC mapping information is required.
>> > >
>> > > While following the discussion, I can relate to the reasons why
> not
>> > > having a separate flow as claimed by Ali:
>> > > a. This is a redundant flow since this information can be conveyed
> in
>> > > the FEC repair flow and in SDP even when protecting multiple RTP
> flows
>> > > (specifically you can see an example in
>> > > draft-galanos-fecframe-rtp-reedsolomon-mf-00).
>> > > b. This separate flow for mapping is also useful only for
> receivers
> that
>> > > support this draft, so the backward compatibility issue remains
> the
> same
>> > > as for the case where mapping is specified in the repair flow.
>> > > c. A separate flow increases the chance of losing packets.
>> > >
>> > > I must say that I don't understand the reasons for using a
> separate
>> > > flow.
>> > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP?
>> > >
>> > > Best,
>> > > Einat
>> > > -----Original Message-----
>> > > From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org]
> On
>> > > Behalf Of zouzixuan
>> > > Sent: Thursday, September 24, 2009 6:24 AM
>> > > To: 'Ali C. Begen (abegen)'; fecframe at ietf.org
>> > > Cc: tme at multicasttech.com
>> > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> > >
>> > > Hi, Ali
>> > > It's a good suggestion that others join the discussion on this.
>> > > The
>> > > point here is that whether we need to take the backward
> compatibility
>> > > into
>> > > account in FEC Framework or not. We may not ignore a fact that the
>> > > diversity
>> > > of clients exists in practice. We didn't mean to make the idea we
>> > > proposed
>> > > to be something depart from the framework. We just hope to
> complement
>> > > the
>> > > framework so that it can be practically more adaptable.
>> > >
>> > > Best regards,
>> > > 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: Thursday, September 24, 2009 12:09 AM
>> > > > To: zouzixuan; fecframe at ietf.org
>> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> > > >
>> > > > There are multiple things here used as an excuse to depart from
> the
>> > > convention
>> > > > used in the framework.
>> > > >
>> > > > The main goal here seems to provide the non-framework capable
> RTP
>> > > > applications a way of using the nice features of the framework.
> In
>> > > this
>> > > example,
>> > > > "a nice feature" stands for the protection of multiple RTP
> streams
>> > > together. I
>> > > > will let others comment on this, too, but personally, I am not
> sure
>> > > whether we
>> > > > should be doing this. On one hand, we want the nice features,
> but at
>> > > the
>> > > same
>> > > > time we don't wanna support the framework, and the excuse is the
>> > > backward
>> > > > compatibility in environments with both framework-capable and
>> > > incapable
>> > > RTP
>> > > > receivers. In addition, using an additional flow may increase
> the
>> > > chances
>> > > of
>> > > > failure since if source fec payload id's are lost, receiver will
> be
>> > > clueless. This
>> > > > deserves a consensus from the WG, probably from AVT, too.
>> > > >
>> > > > Furthermore, I believe two RTP streams can be still protected
> together
>> > > w/o
>> > > any
>> > > > additional source fec payload id's (You asked for an example,
> and I
>> > > will
>> > > try to
>> > > > explain in simple words). If certain features of the RTP streams
> are
>> > > known
>> > > > (which is usually the case), by using a systematic approach (not
> in
>> > > the
>> > > sense of
>> > > > systematic FEC), things can probably be worked out. In your
> example,
> I
>> > > believe
>> > > > in each source block you wanna do a different order of the
> source
>> > > packets
>> > > and
>> > > > flows, so things are quite unpredictable. E.g., packet 16 and 17
> are
>> > > before
>> > > > packet 15 of the same flow, packet 19 is before packet 8 of the
> other
>> > > flow, and
>> > > > packets belonging to flows 0 and 1 are dispersed, any particular
>> > > reason?
>> > > >
>> > > > But, if you follow a systematic approach, your CDP can convey
> the
>> > > mapping
>> > > out
>> > > > of band, and decoding will know what to expect and how to
> decode.
>> > > Remember
>> > > > that there will be constraints on which RTP streams you can
> combine
>> > > prior
>> > > to
>> > > > FEC encoding (this was brought up in the last meeting).
>> > > >
>> > > > If all the RTP streams belong to the same RTP session, their
> SSRC's
>> > > will
>> > > be
>> > > > different, so SSRC+seqnum should uniquely identify each source
> packet.
>> > > But,
>> > > > this would not work if the RTP streams would be from different
>> > > sessions.
>> > > In
>> > > > that case, they could share same SSRC's, and I can see the
>> > > complications.
>> > > >
>> > > > Cheers, acbegen.
>> > > >
>> > > >
>> > > > From: zouzixuan [mailto:tendyntu at huawei.com]
>> > > > Sent: Wednesday, September 23, 2009 4:28 AM
>> > > > To: Ali C. Begen (abegen); fecframe at ietf.org
>> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> > > >
>> > > > >
>> > > > > First question, are you suggesting to apply FEC to the
> combination
>> > > of a
>> > > video
>> > > > > and audio RTP stream?
>> > > >
>> > > > > Second question, assuming the above case is true, I am still
> not
>> > > sure
>> > > why you
>> > > > > need an additional flow carrying the source payload ids. Is it
>> > > because
>> > > there
>> > > > are
>> > > > > two streams? Could you explain?
>> > > >
>> > > > It's not this case that just result in the need of carrying
> source
>> > > play id
>> > > in
>> > > > additional flow. It is this case to prove the need of source
> payload
>> > > id
>> > > for RTP
>> > > > flow. Because you need a source payload id, you gotta transfer
> it to
>> > > the
>> > > client,
>> > > > either in source packet as current FEC framework specified, or
> in an
>> > > additional
>> > > > flow described in our draft. The latter choice for transferring
> the
>> > > source
>> > > > payload is for making source packet accessible to
> non-fecframework
>> > > clients.
>> > > >
>> > > > This table shows an example of multiple flows. The table depicts
> the
>> > > structure
>> > > > of a source block, which is filled up with the packets (of
> length
> 16,
>> > > 17
>> > > 19 15 and
>> > > > 8 bytes) from two sequenced flows. The packets from two flows
> are
>> > > identified
>> > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver
> needs
>> > > to
>> > > know
>> > > > the position of each packet in the source block. The sequence
> number
>> > > can
>> > > only
>> > > > tell the order of a packet in the flow it belongs to in the
> source
>> > > block.
>> > > There is
>> > > > no way to tell where a packet exactly is in the source block.
> Source
>> > > Payload ID is
>> > > > thus in this case needed. Would you please give a solution which
> is
>> > > free
>> > > of
>> > > > source payload id?
>> > > >
>> > > > 0
>> > > > 16
>> > > > B0,0
>> > > > B0,1
>> > > > B0,2
>> > > > B0,3
>> > > > B0,4
>> > > > B0,5
>> > > > B0,6
>> > > > B0,7
>> > > > B0,8
>> > > > B0,9
>> > > > B0,10
>> > > > B0,11
>> > > > B0,12
>> > > > B0,13
>> > > > B0,14
>> > > > B0,15
>> > > > 0
>> > > > 0
>> > > > 0
>> > > > 0
>> > > > 17
>> > > > B1,0
>> > > > B1,1
>> > > > B1,2
>> > > > B1,3
>> > > > B1,4
>> > > > B1,5
>> > > > B1,6
>> > > > B1,7
>> > > > B1,8
>> > > > B1,9
>> > > > B1,10
>> > > > B1,11
>> > > > B1,12
>> > > > B1,13
>> > > > B1,14
>> > > > B1,15
>> > > > B1,16
>> > > > 0
>> > > > 0
>> > > > 1
>> > > > 19
>> > > > B2,0
>> > > > B2,1
>> > > > B2,2
>> > > > B2,3
>> > > > B2,4
>> > > > B2,5
>> > > > B2,6
>> > > > B2,7
>> > > > B2,8
>> > > > B2,9
>> > > > B2,10
>> > > > B2,11
>> > > > B2,12
>> > > > B2,13
>> > > > B2,14
>> > > > B2,15
>> > > > B2,16
>> > > > B2,17
>> > > > B2,18
>> > > > 0
>> > > > 15
>> > > > B3,0
>> > > > B3,1
>> > > > B3,2
>> > > > B3,3
>> > > > B3,4
>> > > > B3,5
>> > > > B3,6
>> > > > B3,7
>> > > > B3,8
>> > > > B3,9
>> > > > B3,10
>> > > > B3,11
>> > > > B3,12
>> > > > B3,13
>> > > > B3,14
>> > > > 0
>> > > > 0
>> > > > 0
>> > > > 0
>> > > > 1
>> > > > 8
>> > > > B4,0
>> > > > B4,1
>> > > > B4,2
>> > > > B4,3
>> > > > B4,4
>> > > > B4,5
>> > > > B4,6
>> > > > B4,7
>> > > >
>> > > >
>> > > > Hope this is clear.
>> > > >
>> > > > 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: Wednesday, September 23, 2009 11:29 AM
>> > > > > To: zouzixuan; fecframe at ietf.org
>> > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>> > > > >
>> > > > > First question, are you suggesting to apply FEC to the
> combination
>> > > of a
>> > > video
>> > > > > and audio RTP stream?
>> > > > >
>> > > > > Second question, assuming the above case is true, I am still
> not
>> > > sure
>> > > why you
>> > > > > need an additional flow carrying the source payload ids. Is it
>> > > because
>> > > there
>> > > > are
>> > > > > two streams? Could you explain?
>> > > > >
>> > > > > Cheers, acbegen.
>> > >
>> > > _______________________________________________
>> > > 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
>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
