[Fecframe] About the Generic Explicit Source FEC Payload ID

Vincent Roca <vincent.roca@inrialpes.fr> Fri, 11 February 2011 09:02 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ACD3A69DD for <fecframe@core3.amsl.com>; Fri, 11 Feb 2011 01:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEdRekqDAyph for <fecframe@core3.amsl.com>; Fri, 11 Feb 2011 01:02:30 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id C5E303A6921 for <fecframe@ietf.org>; Fri, 11 Feb 2011 01:02:29 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,454,1291590000"; d="scan'208";a="91107826"
Received: from ral022r.vpn.inria.fr ([128.93.178.22]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 11 Feb 2011 10:02:42 +0100
Message-ID: <4D54FB32.9070601@inrialpes.fr>
Date: Fri, 11 Feb 2011 10:02:42 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "fecframe@ietf.org" <fecframe@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Fecframe] About the Generic Explicit Source FEC Payload ID
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2011 09:02:31 -0000

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.