Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID

From: Abhishek ANAND <[email-masked]>
Date: Thu, 17 Feb 2011 12:03:52 +0100

Hello everyone,

I am writing to introduce another scenario where we may use multiple FEC Schemes to protect the same Source Packet flow. The particular scenario is one in which we protect multiple Source Packet flows together (in any possible combination) using multiple FEC Schemes.

Example:
We have two flows F1 and F2 and two FEC Scheme instances FEC1 and FEC2 where FEC1 protects the Source Packets from F1 and FEC2 protects the Source packets from F1 as well as F2. This example can be extended to add additional flows and schemes.

One such scenario is using Layer Aware FEC for protecting layered streams such as H.264 SVC/MVC ( http://www.hhi.fraunhofer.de/en/departments/image-processing/image-communication/multimedia-transmission/layer-aware-forward-error-correction-l-fec/ ). There could be other such use cases as well.

In such cases even when the Source Packet flows are RTP flows we must add Source Packet Payload IDs. In addition we can not use the Generic Explicit Source FEC Payload ID as it is described in Section 5.3.1 of the FEC Framework Draft because the position of a Source Packet in the Source Block will not be unique across all FEC Schemes.

Another observation regarding the Generic Explicit Source FEC Payload ID, since it does not contain the Source Block Number and relies solely on consecutive sequence numbers it seems that the corresponding Repair FEC Payload IDs must also use the Initial Sequence Number of each Source Block instead of the Source Block Number.

Regards,
Abhishek

On 02/11/2011 03:14 PM, [email-masked]<mailto:[email-masked]> wrote:
> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vincent Roca
> Sent: Friday, February 11, 2011 4:03 AM
> To: [email-masked]<mailto:[email-masked]>
> Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID
>
> Hi everybody,
>
> While preparing the new O&M section proposal with Ali,
> we spotted two points we'd like to discuss. Here is the first
> one.
>
> Point 1: about the "Generic Explicit Source FEC Payload ID"
> -------------------------------------------------
>
> Section 5.3.1. of the FECFRAME Framework I-D says:
>
>    "In order to apply FEC protection using multiple FEC schemes to a
>     single source flow, all schemes have to use the same Explicit Source
>     FEC Payload ID format.  In order to enable this, it is RECOMMENDED
>     that FEC schemes support the Generic Explicit Source FEC Payload ID
>     format described below."
>
> Then it explains what is meant by "Generic source FEC payload ID",
> i.e. a two byte field, in network byte order, that contains a sequence
> number shared by all FEC schemes.
>
> When reading 5.3.1, it is clear to me that this field is to be carried
> in an **Explicit Source FEC Payload ID**, i.e. at the end of the packet.
> Section 5.3.1 does not suggest to reuse any sequence number that
> may exist in the application flow (like the RTP sequence number) to
> achieve this goal.
>
> We also notice that the sentence is rather strong in what FEC Schemes
> should define (it says "RECOMMENDED").
>
> It turns out that none of the current FEC Schemes define such a
> Generic Explicit FEC Payload ID.
> Additionally, the only use-case where an application flow is
> protected by two different AL-FEC codes and that is considered
> by IETF is the DVB-IPTV (draft-ietf-fecframe-dvb-al-fec-04). In
> that case the solution consists in reusing the RTP SN field, rather
> than defining a "Generic source FEC payload ID".
>
>
> So we see two options here:
> 1- Extend section 5.3.1 recommendations so that, if the
>      application flow already includes a sequence number that
>      fulfills the requirements of section 5.3.1, then this field can
>      be used to fulfill the needs specified here. But this is not
>      strictly speaking a special case of Explicit FEC Payload ID
>      (nothing is added to source packets).

Right. If there is a seqnum that can be used, it could be used and no chances to the source packets at all. If not, we need to specify the format for the generic source fec payload ID field. And the format we define in the framework draft is RECOMMENDED to be used when an fec scheme desires to support being able to be used with other FEC schemes jointly. In other words, if an FEC scheme chooses a different format for the explicit source fec payload id, it won't be able to be used with other FEC schemes that also need an explicit source fec payload id. This is not interoperability but for greater good, I think we should RECOMMEND the generic format we will define.

-acbegen

> 2- or weaken current 5.3.1 recommendation:
> Old text:
>         "In order to enable this, it is RECOMMENDED
>          that FEC schemes support the Generic Explicit Source FEC
> Payload ID
>          format described below."
> New text:
>         "When this feature is desired, one solution can be for the FEC
> schemes
>          to support the Generic Explicit Source FEC Payload ID format
> described
>          below."
>
> Opinions?
>
> Cheers,
>
>     Vincent and Ali.
> _______________________________________________
> Fecframe mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/fecframe

--
Abhishek Anand
Consultant
STMicroelectronics - Torino - ITALY
www.st.com<http://www.st.com>

Phone: +39 011 2276407
mailto: [email-masked]<mailto:[email-masked]>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Feb 2011 07:50:36 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Abhishek ANAND
> Sent: Thursday, February 17, 2011 6:04 AM
> To: [email-masked]
> Subject: Re: [Fecframe] About the Generic Explicit Source FEC Payload ID
> 
> Hello everyone,
> 
> I am writing to introduce another scenario where we may use multiple FEC Schemes to protect the same Source Packet flow.
> The particular scenario is one in which we protect multiple Source Packet flows together (in any possible combination) using
> multiple FEC Schemes.
> 
> Example:
> We have two flows F1 and F2 and two FEC Scheme instances FEC1 and FEC2 where FEC1 protects the Source Packets from F1
> and FEC2 protects the Source packets from F1 as well as F2. This example can be extended to add additional flows and
> schemes.

Like figure 1 in https://datatracker.ietf.org/doc/rfc5956/?include_text=1 ?

> One such scenario is using Layer Aware FEC for protecting layered streams such as H.264 SVC/MVC (
> http://www.hhi.fraunhofer.de/en/departments/image-processing/image-communication/multimedia-transmission/layer-
> aware-forward-error-correction-l-fec/ ). There could be other such use cases as well.
> 
> In such cases even when the Source Packet flows are RTP flows we must add Source Packet Payload IDs. In addition we can
> not use the Generic Explicit Source FEC Payload ID as it is described in Section 5.3.1 of the FEC Framework Draft because the
> position of a Source Packet in the Source Block will not be unique across all FEC Schemes.

Sorry, I don't understand this. The place of a source packet is derived from the information put in the repair packets, not source packets.

It should be sufficient to have the source packets seqnum'ed. And RTP satisfies that requirement nicely.

> Another observation regarding the Generic Explicit Source FEC Payload ID, since it does not contain the Source Block Number
> and relies solely on consecutive sequence numbers it seems that the corresponding Repair FEC Payload IDs must also use the
> Initial Sequence Number of each Source Block instead of the Source Block Number.

The generic field cannot carry the source block number as you said block sizes can and will vary among fecframe instances. And source block number is something used by the decoder but it is derived from the seqnum and base seqnum of a block (i.e., its value is not really used in an absolute fashion).

I am not sure whether you saw something in the text that said otherwise.

-acbegen
 
> Regards,
> Abhishek
> 
> On 02/11/2011 03:14 PM, [email-masked] wrote:
> 
> 	> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Roca
> 	> To: [email-masked]
> 	Right. If there is a seqnum that can be used, it could be used and no chances to the source packets at all. If not, we
> need to specify the format for the generic source fec payload ID field. And the format we define in the framework draft is
> RECOMMENDED to be used when an fec scheme desires to support being able to be used with other FEC schemes jointly. In
> other words, if an FEC scheme chooses a different format for the explicit source fec payload id, it won't be able to be used
> with other FEC schemes that also need an explicit source fec payload id. This is not interoperability but for greater good, I
> think we should RECOMMEND the generic format we will define.
> 
> 	-acbegen
> 
> 	> [email-masked]
> www.st.com
> mailto: [email-masked]

---

From: Abhishek ANAND <[email-masked]>
Date: Fri, 18 Feb 2011 11:25:27 +0100

On 02/17/2011 04:50 PM, Ali C. Begen (abegen) wrote:

 > I am writing to introduce another scenario where we may use multiple 
FEC Schemes to protect the same Source Packet flow.
 > The particular scenario is one in which we protect multiple Source 
Packet flows together (in any possible combination) using
 > multiple FEC Schemes.
 >
 > Example:
 > We have two flows F1 and F2 and two FEC Scheme instances FEC1 and 
FEC2 where FEC1 protects the Source Packets from F1
 > and FEC2 protects the Source packets from F1 as well as F2. This 
example can be extended to add additional flows and
 > schemes.

abegen: Like figure 1 in 
https://datatracker.ietf.org/doc/rfc5956/?include_text=1 ?

aanand: Yes like that, with LA-FEC being one such application. So in 
addition to DVB ALFEC we have other potential technologies which might 
use interdependent FECFrameworks.

 > In such cases even when the Source Packet flows are RTP flows we must 
add Source Packet Payload IDs. In addition we can
 > not use the Generic Explicit Source FEC Payload ID as it is described 
in Section 5.3.1 of the FEC Framework Draft because the
 > position of a Source Packet in the Source Block will not be unique 
across all FEC Schemes.

abegen: Sorry, I don't understand this. The place of a source packet is 
derived from the information put in the repair packets, not source packets.

anand: I was of the opinion that the Source Packet's place is derived 
from the information put in the Repair Packets only when they belong to 
a single sequenced flow. In this case the Repair FEC Payload ID carries 
the Initial Sequence Number which is used to place the Source Packet in 
its place. In other cases where the Source Packets are not sequenced or 
they belong to multiple arbitrary sequenced flows I believe the Source 
Packet's place is calculated using the information present in the Source 
Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I 
think that is how the Raptor Schemes for DVB AL-FEC are designed. Also 
"draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed 
Solomon codec where a FEC Source Packet MUST contain the specified 
Source FEC payload ID.

abegen: It should be sufficient to have the source packets seqnum'ed. 
And RTP satisfies that requirement nicely.

aanand: When we mix two RTP flows we loose the unique sequence number 
sequences which would have been otherwise used by the FECFrameworks at 
the sender and the receiver to place Source Packets. This problem 
together with my opinion above makes it difficult to use the Generic 
Explicit Source FEC Payload ID which is based on sequence numbers that 
are unique across the FECFrameworks.
For example:
Lets continue the example with flows F1, F2 and frameworks FEC1, FEC2.
We add the following assumptions:
FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
RTP sequence numbers for F1: 1,2,3
RTP sequence numbers for F2: 3,4,5.
I think RTP sequence numbers or any unique "consecutive/"/ sequence 
numbers across all FECFrameworks can not be used to place the Source 
Packets in the Source Block for FEC2, so we must add Source FEC Payload 
IDs.

Maybe I am missing some points, in that case I apologize for my ignorance.

 > Another observation regarding the Generic Explicit Source FEC Payload 
ID, since it does not contain the Source Block Number
 > and relies solely on consecutive sequence numbers it seems that the 
corresponding Repair FEC Payload IDs must also use the
 > Initial Sequence Number of each Source Block instead of the Source 
Block Number.

abegen: The generic field cannot carry the source block number as you 
said block sizes can and will vary among fecframe instances. And source 
block number is something used by the decoder but it is derived from the 
seqnum and base seqnum of a block (i.e., its value is not really used in 
an absolute fashion). I am not sure whether you saw something in the 
text that said otherwise.

aanand: It was just an observation because it means that some FEC 
Schemes which explicitly mention a Source FEC Payload ID, Repair FEC 
Payload ID combination not based on sequence numbers will not be usable 
in the use cases of interdependent FECFrameworks. And if my points above 
are correct we might not be able to use unique sequence numbers to place 
Source Packets across all the interdependent FECFrameworks.

-acbegen

 >       Right. If there is a seqnum that can be used, it could be used 
and no chances to the source packets at all. If not, we
 > need to specify the format for the generic source fec payload ID 
field. And the format we define in the framework draft is
 > RECOMMENDED to be used when an fec scheme desires to support being 
able to be used with other FEC schemes jointly. In
 > other words, if an FEC scheme chooses a different format for the 
explicit source fec payload id, it won't be able to be used
 > with other FEC schemes that also need an explicit source fec payload 
id. This is not interoperability but for greater good, I
 > >          to support the Generic Explicit Source FEC Payload ID format

.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 18 Feb 2011 06:35:26 -0800

> Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I

Note that not every FEC scheme is capable of protecting multiple source flows together since their repair payload IDs are only designed for a single sequenced source flow. If an FEC scheme wants to be able handle such scenarios, it needs to be designed that way.

One could put the multiple source flows and re-seqnum them outside the fecframe and then feed the resulting stream into the fec encoder. And yes, then the original seqnums (such as RTP seqnums) cannot be used. But, this has nothing to do with fecframe's capability of protecting multiple source flows together. Because, here you are still feeding a single flow into fecframe.

> Maybe I am missing some points, in that case I apologize for my ignorance.

You could use an identifier for your source flows and this will allow you to use their original seqnums. And in the repair payload IDs, you could use those identifiers.
 
>  > Initial Sequence Number of each Source Block instead of the Source

Yes. However, if the fec scheme used source block number info during encoding, that means it added source fec payload IDs to reflect that number (i.e., it has modified the source packets and it did not use the generic payload id).

-acbegen

---

From: Abhishek ANAND <[email-masked]>
Date: Mon, 21 Feb 2011 16:24:37 +0100

> Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I

abegen: Note that not every FEC scheme is capable of protecting multiple source flows together since their repair payload IDs are only designed for a single sequenced source flow. If an FEC scheme wants to be able handle such scenarios, it needs to be designed that way.

anand: On the contrary I believe that any FEC Scheme that is capable of protecting multiple source flows together must not rely on sequence numbers (RTP/Self-assigned seq no./Generic Source Payload ID in its current form). It should use Payload IDs containing Source Block Numbers and ESIs so that the Encoding Symbols can be placed correctly at the decoder/reciever.

abegen: One could put the multiple source flows and re-seqnum them outside the fecframe and then feed the resulting stream into the fec encoder. And yes, then the original seqnums (such as RTP seqnums) cannot be used. But, this has nothing to do with fecframe's capability of protecting multiple source flows together. Because, here you are still feeding a single flow into fecframe.

anand: I agrees that re-sequence numbering is possible. But this has limited use as the problems arise at the client. A Source Packet can not have the same sequence number (RTP/Artificial Seq No.) for multiple FECFrameworks simply because the sequence number sequence(assumed to be incremental by 1) will overlap with another such running sequences for other flows.
Example:
Let us assume that we resequence the F1 Source Packets as 1,2,3 and feed them to FEC1 and FEC2. Now, FEC2 resequences the F2 Source Packets as 4,5,6. In this way we have two Source Blocks, one each for FEC1 and FEC2. Now when we get the next set of Source Packets for F1 we can reseqnum them as 4,5,6 for FEC1 but not for FEC2. One can think of using different sequence numbers for the same flow for different frameworks. But then this information (one new sequence number for each framework) must be attached to the Source Packet, otherwise the decoder will not be able to place the Source Packets.

> Maybe I am missing some points, in that case I apologize for my ignorance.

abegen: You could use an identifier for your source flows and this will allow you to use their original seqnums. And in the repair payload IDs, you could use those identifiers.

anand: I think this will not work as you might attach in the repair payload IDs the (FlowID,ISN) combination for each of the flows. However the information about the position of each Source Packet is still not there as this information only tells the ISN for each flow, but does not tell how the Source Packets from multiple flows have been placed together to form the Source Block at the encoding FECFramework.

>  > Initial Sequence Number of each Source Block instead of the Source

abegen: Yes. However, if the fec scheme used source block number info during encoding, that means it added source fec payload IDs to reflect that number (i.e., it has modified the source packets and it did not use the generic payload id).

anand: My motive behind opening this discussion was to discuss if we can define a generic payload id that can be also used for the cases such as LA-FEC. Such cases are not outside the scope of FECFramework but I think currently we do not have a formally defined way of handling them. I think such a Source FEC Payload ID must combine the Source FEC Payload IDs of the individual FEC schemes that have been used to encode the Source Packet.

-acbegen

Regards,
Abhishek

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 21 Feb 2011 07:36:35 -0800

> abegen: Note that not every FEC scheme is capable of protecting multiple source flows together since their repair payload
> IDs are only designed for a single sequenced source flow. If an FEC scheme wants to be able handle such scenarios, it needs
> to be designed that way.
> 
> anand: On the contrary I believe that any FEC Scheme that is capable of protecting multiple source flows together must not
> rely on sequence numbers (RTP/Self-assigned seq no./Generic Source Payload ID in its current form). It should use Payload
> IDs containing Source Block Numbers and ESIs so that the Encoding Symbols can be placed correctly at the decoder/reciever.

This is up to the designer of the code. If you wanna modify the source packets, feel free to but be aware of its implications.
 
> abegen: One could put the multiple source flows and re-seqnum them outside the fecframe and then feed the resulting
> stream into the fec encoder. And yes, then the original seqnums (such as RTP seqnums) cannot be used. But, this has nothing
> to do with fecframe's capability of protecting multiple source flows together. Because, here you are still feeding a single flow
> into fecframe.
> 
> anand: I agrees that re-sequence numbering is possible. But this has limited use as the problems arise at the client. A Source
> Packet can not have the same sequence number (RTP/Artificial Seq No.) for multiple FECFrameworks simply because the
> sequence number sequence(assumed to be incremental by 1) will overlap with another such running sequences for other
> flows.
> Example:
> Let us assume that we resequence the F1 Source Packets as 1,2,3 and feed them to FEC1 and FEC2. Now, FEC2 resequences
> the F2 Source Packets as 4,5,6. In this way we have two Source Blocks, one each for FEC1 and FEC2. Now when we get the
> next set of Source Packets for F1 we can reseqnum them as 4,5,6 for FEC1 but not for FEC2. One can think of using different
> sequence numbers for the same flow for different frameworks. But then this information (one new sequence number for
> each framework) must be attached to the Source Packet, otherwise the decoder will not be able to place the Source Packets.

Resequencing is something I mentioned if you wanted to turn multi-input into a single input. This does not relate to fecframe so we don't discuss it in the framework draft. Also after FEC is done, you need to de-sequence all those input streams somehow. That is also something we don't discuss within fecframe.
 
> abegen: You could use an identifier for your source flows and this will allow you to use their original seqnums. And in the
> repair payload IDs, you could use those identifiers.
> 
> 
> anand: I think this will not work as you might attach in the repair payload IDs the (FlowID,ISN) combination for each of the
> flows. However the information about the position of each Source Packet is still not there as this information only tells the
> ISN for each flow, but does not tell how the Source Packets from multiple flows have been placed together to form the
> Source Block at the encoding FECFramework.

I think you are dismissing the fact that not everything is carried in band, meaning that we have something called configuration information. 

Again, modifying the source packets in the way you would like to is not illegal, but unless absolutely necessary, pretty much nobody does it.
  
> abegen: Yes. However, if the fec scheme used source block number info during encoding, that means it added source fec
> payload IDs to reflect that number (i.e., it has modified the source packets and it did not use the generic payload id).
> 
> anand: My motive behind opening this discussion was to discuss if we can define a generic payload id that can be also used
> for the cases such as LA-FEC. Such cases are not outside the scope of FECFramework but I think currently we do not have a
> formally defined way of handling them. I think such a Source FEC Payload ID must combine the Source FEC Payload IDs of the
> individual FEC schemes that have been used to encode the Source Packet.

If different schemes use different payload IDs for the source packets, it won't work. If you wanna change the content of the generic payload ID, I am still not seeing the need for it.

-acbegen