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

Vincent,

Good point. I suggest option#1.

Cheers,
Rajiv

~~~
June 8, 2011 is the "World IPv6 Day" (http://isoc.org/wp/worldipv6day/)

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On
> Behalf Of Vincent Roca
> Sent: Friday, February 11, 2011 4:03 AM
> To: fecframe@ietf.org
> 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).
> 
> 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
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe