Subject: [Fecframe] transmit source payload ID in separate flow

From: Zou ZiXuan <[email-masked]>
Date: Mon, 04 May 2009 15:12:05 +0800

Hi,

         I have a question on the source FEC payload ID, which I think
belongs to FEC Framework . I would appreciate for comments on this
question. 

"Draft-ietf-fecframe-framework-03" and
"draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned the case
where source FEC packet does not carry source FEC payload ID for FEC
protection. The reason for not having source FEC payload ID is that the
sequence number (if exist) can take the source FEC payload ID's place.
This brings backward compatibility to FEC-incapable client. RTP was said
to be an example that can be applied to this case. But this works based
on a requirement that the source FEC packets have to be of identical
length, which is not necessarily met during FEC protection. RTP packet
length may vary during streaming. So, though there is sequence number,
sometimes the source FEC payload ID is still a must. 

In such a case, if we still want to have backward compatibility by not
changing the source packet format, a possible way to follow is to
transmit the source FEC payload IDs in separate packets. In order to
indicate the position of source packet in a source block, the sequence
number of source packet would also be sent along with the source FEC
payload ID. For example, we could define a packet format with at least
the following content: the sequence number of the very first source
packet of a source block, followed by source FEC payload ID of all
source packets of the same source block. These metrics collaboratively
determines the position of a source packet in a source block.

The comments on the above are welcome. 

Best Regards.

Zou ZiXuan, Ph.D, Senior Research Staff
Media & Communication Laboratory 

Corporate Research Department huawei_logo

Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: 86-0755-28789364
Fax: 86-0755-28567643
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)" <[email-masked]>
Date: Mon, 4 May 2009 09:07:12 -0700

Hi Zou,

Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Zou ZiXuan
> Sent: Monday, May 04, 2009 12:12 AM
> To: [email-masked]
> Subject: [Fecframe] transmit source payload ID in separate flow
> 
> Hi,
> 
>          I have a question on the source FEC payload ID, which I think belongs to FEC Framework . I
> would appreciate for comments on this question.
> 
> 
> 
> “Draft-ietf-fecframe-framework-03” and “draft-ietf-fecframe-interleaved-fec-scheme-04” both mentioned
> the case where source FEC packet does not carry source FEC payload ID for FEC protection. The reason
> for not having source FEC payload ID is that the sequence number (if exist) can take the source FEC
> payload ID’s place. This brings backward compatibility to FEC-incapable client. RTP was said to be an

Yes.

> example that can be applied to this case. But this works based on a requirement that the source FEC
> packets have to be of identical length, which is not necessarily met during FEC protection. RTP packet
> length may vary during streaming. So, though there is sequence number, sometimes the source FEC
> payload ID is still a must.

Sure they can vary. And in the interleaved draft, we don't care. There is a field in the FEC header, called "Length recovery" which determines the length of the recovered packet.

> In such a case, if we still want to have backward compatibility by not changing the source packet
> format, a possible way to follow is to transmit the source FEC payload IDs in separate packets. In
> order to indicate the position of source packet in a source block, the sequence number of source
> packet would also be sent along with the source FEC payload ID. For example, we could define a packet
> format with at least the following content: the sequence number of the very first source packet of a
> source block, followed by source FEC payload ID of all source packets of the same source block. These
> metrics collaboratively determines the position of a source packet in a source block.

Keeping the source packets unchanged is of course desirable. However, generating a new flow may bring up other issues, like needing a new multicast group, etc. So, the trade-off must be examined well.

BR,
-acbegen

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

---

From: Zou ZiXuan <[email-masked]>
Date: Tue, 05 May 2009 10:35:11 +0800

Hi, Ali,
	Inline

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 12:07 AM
> To: Zou ZiXuan; [email-masked]
> Subject: RE: [Fecframe] transmit source payload ID in separate flow
> 
> Hi Zou,
> 
> Inline.
> 
> > From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Zou ZiXuan
> belongs to FEC Framework . I
> "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned
> > the case where source FEC packet does not carry source FEC payload
ID
> for FEC protection. The reason
> > for not having source FEC payload ID is that the sequence number (if
exist)
> can take the source FEC
> > payload ID's place. This brings backward compatibility to
FEC-incapable
> client. RTP was said to be an
> 
> Yes.
> 
> > packets have to be of identical length, which is not necessarily met
during
> FEC protection. RTP packet
> Sure they can vary. And in the interleaved draft, we don't care. There
is a field
> in the FEC header, called "Length recovery" which determines the
length of
> the recovered packet.
[ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But
it does exist under other circumstance like using Raptor code for
content delivery protection. My question is basically related to the
description in FEC framework draft related to unchanged source packet.
It only cover the case of excluding FEC payload ID during protection. I
think we should add some text in FEC framework draft regarding taking
FEC payload ID out and transmitting it in separate packets. 
> changing the source packet
> > format, a possible way to follow is to transmit the source FEC
payload IDs
> in separate packets. In
> > order to indicate the position of source packet in a source block,
the
> sequence number of source
> > format with at least the following content: the sequence number of
the very
> first source packet of a
> > source block, followed by source FEC payload ID of all source
packets of
> the same source block. These
> > metrics collaboratively determines the position of a source packet
in a
> source block.
> 
> Keeping the source packets unchanged is of course desirable. However,
> generating a new flow may bring up other issues, like needing a new
> multicast group, etc. So, the trade-off must be examined well.
[ZiXuan] Sharing a session among repair packet flow (or source packet
flow) and "source FEC payload ID" flow is probably a way to go for your
concern. For client making a distinguish between two flows, payload type
multiplexing of some kind is probably needed. A "FEC header" with a PT
field of different value shall be used for identifying different flows. 
------------------------------------------------------------------------
------------------------------
> > 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
> > recipient(s) is prohibited. If you receive this e-mail in error,
please notify the
> sender by

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 4 May 2009 19:58:55 -0700

> FEC payload ID out and transmitting it in separate packets.

I guess you can propose some text to Mark that explains your motivation and how to make this work in practice. Whether this approach will be taken or not by an implementation, it depends, but we can certainly mention it in the framework draft.

BR,
-acbegen

> From: Zou ZiXuan [mailto:[email-masked]]
> Sent: Monday, May 04, 2009 7:35 PM
> To: Ali C. Begen (abegen); [email-masked]

---

From: Zou ZiXuan <[email-masked]>
Date: Wed, 06 May 2009 14:39:55 +0800

Hi Mark,
	We made some comments in mail list on FEC framework draft (see
inline). The comments focus on the case of not having source FEC payload
ID in source packet, if the source packet has sequence number. This
leads to backward compatibility. But it requires the source FEC packet
to be of identical size, which sometime does not practically stand. RTP
over NAL+H.264 encoded payload is a good example, where packet size can
vary. In this example, for some FEC scheme free of the requirement of
fixing packet size, like Raptor, the source FEC payload ID is still
needed. But keeping source packet unchanged is still possible. A way to
follow is to transmit the source FEC payload IDs in separate packet
flows. In order to indicate the position of source packet in a source
block, the sequence number of source packet would also be sent along
with the source FEC payload ID. For example, we could define a packet
format with at least the following content: the sequence number of the
very first source packet of a source block, followed by source FEC
payload ID of all source packets of the same source block. These metrics
collaboratively determines the position of a source packet in a source
block. I think we may add some relevant text to the fec framework draft
to complement the back-ward compatibility description.

We'v submitted a internet-draft to fec framework, disclosing our ideas
in greater details, hopefully appears in mail list today or tomorrow.
Your comments and opinions will be very appreciated. 

> Sent: Tuesday, May 05, 2009 10:59 AM
> I guess you can propose some text to Mark that explains your
motivation and
> how to make this work in practice. Whether this approach will be taken
or not
> by an implementation, it depends, but we can certainly mention it in
the
> framework draft.
> > > > example that can be applied to this case. But this works based
on a
> > > requirement that the source FEC
> > > > In such a case, if we still want to have backward compatibility
by
> > not
> > > > packet would also be sent along with the source FEC payload ID.
For
> > > example, we could define a packet
> > > > disclosure, reproduction, or dissemination) by persons other
than

---

From: "Watson, Mark" <[email-masked]>
Date: Wed, 6 May 2009 09:05:19 -0700

Hi Zou,

It is not correct that the source packet sizes must be fixed when the Explicit Source FEC Payload ID is not used. For example, in draft-fecframe-raptor we define an FEC Scheme for a "Single Sequenced Flow" which can handle variable source packet sizes and requires only that some kind of sequence number is available in the source packets.

As with the interleaved draft, every packet occupies the same amount of space in the source block for encoding and decoding, so packets shorter than this have to be padded with zeros (in the source block). This padding is never sent, but it does mean that to recover a lost source packet an amount of repair data equal to the maximum packet size is needed, independent of the size of the actual packet being recovered.

You can indeed improve on this by allocating each packet space in the source block which is closer to the packet's actual size and signalling in some way the positioning of the packets (either in the Explicit Source FEC Payload Id, or in another way such as you have proposed).

However, simply signalling the full Explicit Source FEC Payload Id for every packet may not be efficient: in the Raptor case, for example, the Explicit Source FEC Payload Id contains the Source Block Number and the Encoding Symbol Id (4 bytes per packet). Since you have the 2-byte sequence number in every source packet in fact your 'separate flow' signalling needs only the initial sequence number for the block and one byte more per packet to specify the packet size in symbols. In fact less than one byte may be sufficient depending on the symbol size.

So, the details should be dependent on the FEC Scheme, just as the contents of the Explicit Source FEC Payload ID are defined by the FEC Scheme and because the format of the source block itself is defined in the FEC Scheme. For this reason I would prefer not to specify this in the Framework, but to leave it to FEC Schemes to provide such a mechanism if they choose.

Of course if there is a generic mechanism that could be reused by multiple FEC Schemes then this could be published separately.

I look forward to seeing your draft - note that you also have to consider how reliability will be provided for the extra signalling packets and IMO you might as well also provide support for combined protection of multiple source flows which is not otherwise available when sequence numbers are used.

...Mark

On 5/5/09 11:39 PM, "Zou ZiXuan" <[email-masked]> wrote:

Hi Mark,

motivation and
or not
the
on a
by
For
than

---

From: zouzixuan 61302 <[email-masked]>
Date: Thu, 07 May 2009 17:57:39 +0800

Hi, Mark

Inline

Hi Zou,

It is not correct that the source packet sizes must be fixed when the
Explicit Source FEC Payload ID is not used. For example, in
draft-fecframe-raptor we define an FEC Scheme for a “Single Sequenced
Flow” which can handle variable source packet sizes and requires only that
some kind of sequence number is available in the source packets.

As with the interleaved draft, every packet occupies the same amount of
space in the source block for encoding and decoding, so packets shorter than
this have to be padded with zeros (in the source block). This padding is
never sent,

 but it does mean that to recover a lost source packet an amount of repair
data equal to the maximum packet size is needed, independent of the size of
the actual packet being recovered.

Agree. 

You can indeed improve on this by allocating each packet space in the source
block which is closer to the packet’s actual size and signalling in some
way the positioning of the packets (either in the Explicit Source FEC
Payload Id, or in another way such as you have proposed).

However, simply signalling the full Explicit Source FEC Payload Id for every
packet may not be efficient: in the Raptor case, for example, the Explicit
Source FEC Payload Id contains the Source Block Number and the Encoding
Symbol Id (4 bytes per packet). Since you have the 2-byte sequence number in
every source packet in fact your ‘separate flow’ signalling needs only the
initial sequence number for the block and one byte more per packet to
specify the packet size in symbols. In fact less than one byte may be
sufficient depending on the symbol size.
This is exactly a good idea. In fact, we disclosed a similar solution in the
draft, which is called “source FEC Payload MIU” , which has “initial
sequence number” field for the same purpose. 

So, the details should be dependent on the FEC Scheme, just as the contents
of the Explicit Source FEC Payload ID are defined by the FEC Scheme and
because the format of the source block itself is defined in the FEC Scheme.
For this reason I would prefer not to specify this in the Framework, but to
leave it to FEC Schemes to provide such a mechanism if they choose.

Of course if there is a generic mechanism that could be reused by multiple
FEC Schemes then this could be published separately.

We’v taken this concern into account by defining a “FEC header format”,
Please see the draft.

I look forward to seeing your draft – note that you also have to consider
how reliability will be provided for the extra signalling packets and 

IMO you might as well also provide support for combined protection of
multiple source flows which is not otherwise available when sequence numbers
are used.

Yes, we’v had a solution for supporting multiple source flows protection,
see the draft enclosed. Please see the draft.

Hi Mark,

motivation and
or not
the
on a
by
For
than