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

[zouzixuan <tendyntu at huawei.com>]

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? 

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