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

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Abhishek ANAND
> Sent: Thursday, February 17, 2011 6:04 AM
> To: [e-mail]
> 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, [e-mail] wrote:
> 
> 	> -----Original Message-----
> 	> From: [e-mail] [mailto:[e-mail]] On Behalf Of Vincent Roca
> 	> Sent: Friday, February 11, 2011 4:03 AM
> 	> To: [e-mail]
> 	> 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
> 	> [e-mail]
> 	> https://www.ietf.org/mailman/listinfo/fecframe
> 
> 
> 
> 
> --
> Abhishek Anand
> Consultant
> STMicroelectronics - Torino - ITALY
> www.st.com
> 
> Phone: [phone]
> mailto: [e-mail]