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

From: Greg Shepherd <[email-masked]>
Date: Thu, 17 Sep 2009 06:46:47 -0700

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Sep 2009 06:55:45 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
> Shepherd
> Sent: Thursday, September 17, 2009 9:47 AM
> To: [email-masked]
> Subject: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: zouzixuan <[email-masked]>
Date: Fri, 18 Sep 2009 18:52:07 +0800

Hi, All
 The followings are from minutes of the last 75th IEFT meeting
 
> AB: We don't modify the source packets anyway so this is not 
> a problem.

[zou] In order to answer the concerns in the last meeting about why we
brought up this draft, I think we should first clarify the need of Source
Payload ID argued by Ali's comments as the above. We gave the following
scenario/explanation to show the need of Source Payload ID.

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.

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

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: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ali C. Begen (abegen)
Sent: Thursday, September 17, 2009 9:56 PM
To: [email-masked]; [email-masked]
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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 18 Sep 2009 04:04:01 -0700

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

> this Framework. The draft "draft-zixuan-fecframe-source-miu" is proposed for

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)? 

-acbegen

---

From: zouzixuan <[email-masked]>
Date: Sat, 19 Sep 2009 15:52:02 +0800

Hi, Ali
	inline

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Friday, September 18, 2009 7:04 PM
> To: zouzixuan; [email-masked]; [email-masked]
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 

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

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. 

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 19 Sep 2009 01:45:20 -0700

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

> 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?
 
> As I explained above, in principle, it is better to use source fec payload

I am sorry, I am not following this.

> There is need to modify the source-packets in that case, as explicit source

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

---

From: zouzixuan <[email-masked]>
Date: Wed, 23 Sep 2009 11:15:16 +0800

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

> > > > 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.
> > >
> > > 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
> > > benefit from the fec packets generated by an FEC scheme (which is
based
> on
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.

> Sent: Saturday, September 19, 2009 4:45 PM
> > > > "draft-fecframe-framework", has to be used no matter if the
protected
> > > source
> Source fec payload is of course required but in sequenced streams, it is
already
> in the source itself. What else do we need?
> 
> > >
> > > > length of Source Packet Information. But this probably has a
downside:
> > the
> > > > 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.
> > >
> > > benefit from the fec packets generated by an FEC scheme (which is
based
> on
> 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.
> > > > is intended only for the person or entity whose address is listed
above.
> > Any
> > > > From: [email-masked] [mailto:[email-masked]]
On
> > > Behalf
> > > > about the applicability of this draft, the validity of the problem
and
> > some
> > > > Will the authors be addressing those comments with a revision before
we
> > > move
> > > > > From: [email-masked] [mailto:[email-masked]]
> On
> > > > Behalf Of Greg
> > > > > Shepherd

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 22 Sep 2009 20:29:26 -0700

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.

---

From: zouzixuan <[email-masked]>
Date: Wed, 23 Sep 2009 16:27:40 +0800

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

Bantian Longgang

Tel: +86 0755 28789364

Fax: +86 0755 28788317

www.huawei.com

 

> Sent: Wednesday, September 23, 2009 11:29 AM

> To: zouzixuan; [email-masked]

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 23 Sep 2009 09:08:45 -0700

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:[email-masked]] 
Sent: Wednesday, September 23, 2009 4:28 AM
To: Ali C. Begen (abegen); [email-masked]
Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??

> 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

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.

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: [email-masked]
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!

> 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

---

From: zouzixuan <[email-masked]>
Date: Thu, 24 Sep 2009 11:24:10 +0800

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,

> Sent: Thursday, September 24, 2009 12:09 AM
> 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.
> 
> 
video
> > need an additional flow carrying the source payload ids. Is it because
there
> are
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?
----------------------------------------------------------------------------
------------------------------------
> ---------------------
HUAWEI,
> which
> is intended only for the person or entity whose address is listed above.
Any use
> of the
total or
> partial
intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
notify the
> sender by
video
> > need an additional flow carrying the source payload ids. Is it because
there
> are

---

From: "Einat Yellin (Lachover)" <[email-masked]>
Date: Thu, 24 Sep 2009 08:24:23 +0300

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: [email-masked] [mailto:[email-masked]] On
Behalf Of zouzixuan
Sent: Thursday, September 24, 2009 6:24 AM
To: 'Ali C. Begen (abegen)'; [email-masked]
Cc: [email-masked]
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,

------------------------------------------------------------------------
----

convention
example,
together. I
whether we
same
RTP
of
clueless. This
any
try to
sense of
believe
and
before
flow, and
out
to
be
But,
In
video
> > and audio RTP stream?
> 
> > Second question, assuming the above case is true, I am still not
sure
why you
there
in
for RTP
client,
additional
clients.
structure
19 15 and
identified
know
only
There is
Payload ID is
of
> E-mail: [email-masked]
------------------------------------------------------------------------
----
------------------------------------
HUAWEI,
above.
Any use
total or
intended
notify the
video
> > and audio RTP stream?
> >
> > Second question, assuming the above case is true, I am still not
sure
why you
there

---

From: zouzixuan <[email-masked]>
Date: Sun, 27 Sep 2009 17:58:38 +0800

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

> From: Einat Yellin (Lachover) [mailto:[email-masked]]
> Sent: Thursday, September 24, 2009 1:24 PM
> To: zouzixuan; Ali C. Begen (abegen); [email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 27 Sep 2009 10:40:20 -0700

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.

> Sent: Sunday, September 27, 2009 5:59 AM
> To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); [email-masked];
> [email-masked]; [email-masked]

---

From: zouzixuan <[email-masked]>
Date: Mon, 28 Sep 2009 16:57:03 +0800

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? 

> Sent: Monday, September 28, 2009 1:40 AM
> To: zouzixuan; Einat Yellin (Lachover); [email-masked];
> 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.
> 
> > B2,8	  B2,9	B2,10  B2,11	  B2,12	B2,13  B2,14	  B2,15
B2,16
Any
above.
> > > > Furthermore, I believe two RTP streams can be still protected
together
> > > w/o
> > > > of a source block, which is filled up with the packets (of length
16,
> > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver
needs

---

From: "Einat Yellin (Lachover)" <[email-masked]>
Date: Tue, 29 Sep 2009 08:31:17 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of zouzixuan
Sent: Monday, September 28, 2009 10:57 AM
To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover);
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??

Hi, Ali

it

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

it
source
me.
2).
> > adding source payload id to it. And therefore the non-framework
client
can
> > flow. Ali, sorry, I was supposed to gave more detailed information
on
this.
> >    Ali, would you please give a more details on "systematic
approach"?
I'm
B2,16
> > B3,8	  B3,9	B3,10  B3,11	  B3,12	B3,13  B3,14	   0
0
0
> > So here I think if we want to have answer on the necessity of the
things
in
> > the "back compatibility" Elinat and me are referring to is a real
issue
to
above.
Any
> > > b. This separate flow for mapping is also useful only for
receivers
that
> > > support this draft, so the backward compatibility issue remains
the
same
On
above.
> > > Any
> > > use of the
> > > information contained herein in any way (including, but not
limited
to,
> > > > applications a way of using the nice features of the framework.
In
> > > this
> > > > should be doing this. On one hand, we want the nice features,
but at
> > > > receivers. In addition, using an additional flow may increase
the
> > > chances
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
> > > > 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
> > > > If all the RTP streams belong to the same RTP session, their
SSRC's
> > > will
> > > > > First question, are you suggesting to apply FEC to the
combination
> > > of a
> > > > 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
> > > > flow described in our draft. The latter choice for transferring
the
16,
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.
> > > > thus in this case needed. Would you please give a solution which
is
> > > free
> > > > information contained herein in any way (including, but not
limited
> > > to,
> > > total or
> > > > partial
> > > > disclosure, reproduction, or dissemination) by persons other
than
the
> > > > > First question, are you suggesting to apply FEC to the
combination
> > > of a