Re: [Fecframe] Last Call: <draft-ietf-fecframe-rtp-raptor-05.txt> (RTP Payload Format for Raptor FEC) to Proposed Standard

Vincent Roca <vincent.roca@inrialpes.fr> Tue, 25 October 2011 07:27 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7C721F8AFE; Tue, 25 Oct 2011 00:27:53 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lznkVp7p3G9m; Tue, 25 Oct 2011 00:27:53 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id D628321F8AFC; Tue, 25 Oct 2011 00:27:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.69,403,1315173600"; d="scan'208";a="125738542"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 Oct 2011 09:27:50 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Vincent Roca <vincent.roca@inrialpes.fr>
In-Reply-To: <20111020134716.20244.40862.idtracker@ietfa.amsl.com>
Date: Tue, 25 Oct 2011 09:27:50 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <3D4BEDE3-3F17-49CC-A28C-B4FCAF3C4626@inrialpes.fr>
References: <20111020134716.20244.40862.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] Last Call: <draft-ietf-fecframe-rtp-raptor-05.txt> (RTP Payload Format for Raptor FEC) to Proposed Standard
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 25 Oct 2011 07:27:54 -0000

Hi everybody,

I've already mentioned this point in March 18th, this year, in the
FECFrame list.

Unless I missed some key sentence, I have the feeling that this
I-D **leaves implicit** the strong requirement that there  must not be any
RTP packet loss (or reordering) before reaching the Fecframe encoder,
i.e. that the RTP Sequence Numbers used to identify  source symbols in
the FEC block are always in sequence.

This is a key requirement that MUST be clearly stated rather than
being left implicit.

I haven't checked carefully in draft-ietf-fecframe-raptor-05, but sections
8.2.2. and 8.2.4. in this I-D do not seem to be more explicit on this point.

This requirement, that is specific to situations where RTP source packets
are left unchanged, and some solutions to mitigate it, have already been
discussed on the list and guidelines have been added in RFC6363:

10.2. Operational and Management Recommendations
[...]
5.  Management of Communication Issues before Reaching the Sending
       FECFRAME Instance:

Cheers,

   Vincent


On Oct. 20, 2011, 15:47, The IESG wrote:
> 
> The IESG has received a request from the FEC Framework WG (fecframe) to
> consider the following document:
> - 'RTP Payload Format for Raptor FEC'
>  <draft-ietf-fecframe-rtp-raptor-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-11-03. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document specifies an RTP Payload Format for Forward Error
>   Correction repair data produced by the Raptor FEC Schemes.  Raptor
>   FEC Schemes are specified for use with the IETF FEC Framework which
>   supports transport of repair data over both UDP and RTP.  This
>   document specifies the Payload Format which is required for the use
>   of RTP to carry Raptor repair flows.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe