Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ??

From: zouzixuan <[email-masked]>
Date: Fri, 09 Oct 2009 19:40:00 +0800

Hi, 

> Hi,

> As I stated previously, I do not fully understand the motivation for using
a

> separate flow for conveying FEC payload mapping information.

                    As stated in your draft: "Add padding (bytes containing
binary zeroes) so that the byte array is in the size of the largest packet
protected by this source block including the two bytes from section a.  (The
largest packet does not contain zero padding).", conveying FEC payload
mapping information in repair flow needs padding. But padding may lead to
recovery performance degradation.  We give an example, as the figures show
below. 

For the padding case as depicted in Figure 1, the redundant data for
recovering the packet of length 11 is 48, which is same as that for the
packet of length 40.

Figure1. Source block with padding

|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+
|0000000000000000|
+----------------+
|0000000000000000|
+----------------+

For a non-padding case as depicted in Figure2, recovering the packet of
length 11 only requires redundant data of length 16. The redundancy is much
less than the padding case. 
 
                                                    Figure 2. Source block
without padding
|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+

If choosing non-padding strategy as an alternative for FEC protection, the
position of source packet cannot be acquired simply by the sequence number.
The information with greater detail, for example ESI of each source packet,
have to be conveyed. These information may expand the FEC header in the
repair flow to a fairly large size. An alternative is to convey them in a
separate flow. 

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

The focus of our draft is on backward-compatibility issue. Separate flow is
just an option. Based on the previous discussion on the draft, now we think
defining a generic mapping information format for various ways of building
source block in practice should be the most important issue for backward
compatibility. We suggest to make this work (defining a generic mapping
information format) to be a work item. We can update our draft to be the
basis of this work. 

-----Original Message-----

> From: Einat Yellin (Lachover) [mailto:[email-masked]]

> Sent: Tuesday, October 06, 2009 11:00 PM

> To: [email-masked]

> Cc: zouzixuan; Ali C. Begen (abegen); [email-masked];

> [email-masked]

> Subject: RE: Working Group Item? was: Re:

> [Fecframe]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: [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

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 9 Oct 2009 12:22:42 -0700

> The focus of our draft is on backward-compatibility issue. Separate flow is just an
> option. Based on the previous discussion on the draft, now we think defining a generic

What other option(s) do you propose?

Using a separate flow requires additional support on the clients already supporting the framework. Rather than wasting that energy on those modifications, I'd rather prefer making the non-framework clients compatible with the framework if they indeed want to benefit from the framework features.

Ow, I suggest the non-compatible clients to stick with the non-complicated FEC scenarios. This whole stuff is not worth the effort IMO.

-acbegen

> mapping information format for various ways of building source block in practice should be
> the most important issue for backward compatibility. We suggest to make this work
> (defining a generic mapping information format) to be a work item. We can update our draft
> to be the basis of this work.

---

From: zouzixuan <[email-masked]>
Date: Sat, 10 Oct 2009 17:16:11 +0800

Hi, 
  > > The focus of our draft is on backward-compatibility issue. Separate
flow is just
> an
> > option. Based on the previous discussion on the draft, now we think
defining a
> generic
Other option can be repair flow.

> Ow, I suggest the non-compatible clients to stick with the non-complicated
FEC
> scenarios. This whole stuff is not worth the effort IMO.
>

So we need to draw a conclusion on if compatibility is a worth work or not
in FEC framework. 

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!

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Saturday, October 10, 2009 3:23 AM
> To: zouzixuan; Einat Yellin (Lachover); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: RE: Working Group Item? was: Re:
> > The focus of our draft is on backward-compatibility issue. Separate flow
is just
> an
> > option. Based on the previous discussion on the draft, now we think
defining a
> generic
> Using a separate flow requires additional support on the clients already
> supporting the framework. Rather than wasting that energy on those
> modifications, I'd rather prefer making the non-framework clients
compatible
> with the framework if they indeed want to benefit from the framework
> features.
> 
> Ow, I suggest the non-compatible clients to stick with the non-complicated
FEC
> scenarios. This whole stuff is not worth the effort IMO.
> 
> -acbegen
> 
> > (defining a generic mapping information format) to be a work item. We
can
> update our draft

---

From: "Einat Yellin (Lachover)" <[email-masked]>
Date: Sun, 11 Oct 2009 07:18:03 +0200

Hi,

The recovery performance degradation while padding is there, I agree.

However, this is one factor out of many that the application needs to
consider while choosing the FEC scheme to use.

For example, if recovery performance is critical one can choose using
1D2D scheme, which is less demanding on CPU power.

In addition, for high bit rate video applications, such as the one we
designed and implemented our scheme for, it is common to use MTU size
for RTP packets to reduce overhead. This makes the recovery performance
degradation due to padding negligible.

Einat

From: zouzixuan [mailto:[email-masked]] 
Sent: Friday, October 09, 2009 1:40 PM
To: Einat Yellin (Lachover); [email-masked]
Cc: 'Ali C. Begen (abegen)'; [email-masked]; [email-masked]
Subject: RE: RE: Working Group Item? was:
Re:[Fecframe]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.

                    As stated in your draft: "Add padding (bytes
containing binary zeroes) so that the byte array is in the size of the
largest packet protected by this source block including the two bytes
from section a.  (The largest packet does not contain zero padding).",
conveying FEC payload mapping information in repair flow needs padding.
But padding may lead to recovery performance degradation.  We give an
example, as the figures show below. 

|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+
|0000000000000000|
+----------------+
|0000000000000000|
+----------------+

For a non-padding case as depicted in Figure2, recovering the packet of
length 11 only requires redundant data of length 16. The redundancy is
much less than the padding case. 
 
                                                    Figure 2. Source
block without padding
|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+

If choosing non-padding strategy as an alternative for FEC protection,
the position of source packet cannot be acquired simply by the sequence
number. The information with greater detail, for example ESI of each
source packet, have to be conveyed. These information may expand the FEC
header in the repair flow to a fairly large size. An alternative is to
convey them in a separate flow. 

practical

> FEC codes is a good idea, however I believe that this should be
indicated in the

The focus of our draft is on backward-compatibility issue. Separate flow
is just an option. Based on the previous discussion on the draft, now we
think defining a generic mapping information format for various ways of
building source block in practice should be the most important issue for
backward compatibility. We suggest to make this work (defining a generic
mapping information format) to be a work item. We can update our draft
to be the basis of this work. 

-----Original Message-----

> As I stated previously, I do not fully understand the motivation for
using a

practical

> FEC codes is a good idea, however I believe that this should be
indicated in the

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On
Behalf Of zouzixuan

To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover);
[email-masked]; [email-masked]; [email-masked]

Hi, Ali

for

it

good

 

source

to

me.

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? 

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.

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 28 Oct 2009 07:01:49 -0700

I believe we have covered all we can on this discussion. The majority
opinion is that adding complexity to the framework for the sake of
compatibility with non-framework clients is out of scope for the WGs
original objectives.

So I don't feel the WG should take on this work.

Sorry,
Greg