[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.
- [Fecframe] About the Generic Explicit Source FEC … Vincent Roca
- Re: [Fecframe] About the Generic Explicit Source … Rajiv Asati (rajiva)
- Re: [Fecframe] About the Generic Explicit Source … Ali C. Begen (abegen)
- Re: [Fecframe] About the Generic Explicit Source … Abhishek ANAND
- Re: [Fecframe] About the Generic Explicit Source … Ali C. Begen (abegen)
- Re: [Fecframe] About the Generic Explicit Source … Abhishek ANAND
- Re: [Fecframe] About the Generic Explicit Source … Ali C. Begen (abegen)
- Re: [Fecframe] About the Generic Explicit Source … Abhishek ANAND
- Re: [Fecframe] About the Generic Explicit Source … Ali C. Begen (abegen)