From gjshep@gmail.com Fri Nov 4 07:29:53 2011 Return-Path: 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 33CD421F8C51 for ; Fri, 4 Nov 2011 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 wZJRFbtfcshP for ; Fri, 4 Nov 2011 07:29:52 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4609121F8C50 for ; Fri, 4 Nov 2011 07:29:52 -0700 (PDT) Received: by mail-bw0-f44.google.com with SMTP id zv15so2025510bkb.31 for ; Fri, 04 Nov 2011 07:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=nU4/qw2BCtfFkALA3vaIR+0rW4yJSkLiXCw16rcFJok=; b=t84ClZS4Jweab+pgQooCSI52BNGjdJH1pXgnM3xwCnJJrdLIkCcX/Y7+lYgA0KU9sn rwFUJFsp1P3Hi6HEkQko92GUyJTv02KCaHGOFlpoL9vIaquGkwzko0cytt7uhjmDXvVX VhnoGPM4ssUWDZU+MfMYudI6iNrr7BB3riDUo= MIME-Version: 1.0 Received: by 10.204.140.3 with SMTP id g3mr12380795bku.28.1320416991863; Fri, 04 Nov 2011 07:29:51 -0700 (PDT) Received: by 10.204.56.13 with HTTP; Fri, 4 Nov 2011 07:29:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 07:29:51 -0700 Message-ID: From: Greg Shepherd To: "Rajiv Asati (rajiva)" , fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] Fwd: IESG Eval followup: config-signaling anf rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:29:53 -0000 *, There are a few things holding up the config-sig draft, but the one we need to help with is: MUST this doc progress as experimental, or is there WG consensus to move it to informational? Please reply promptly to the list. Thanks!, Greg ---------- Forwarded message ---------- From: David Harrington Date: Fri, Nov 4, 2011 at 7:23 AM Subject: IESG Eval followup: config-signaling anf rtp-raptor To: gjshep@gmail.com Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org, draft-ietf-fecframe-rtp-raptor@tools.ietf.org Hi, The IESG reviewed the config signaling and rtp-raptor drafts. We have work to do. config-signaling: 1) Can we publish this as Informational? =A0 =A0 =A0 =A0Is that a problem for any cross-SDO work? =A0 =A0 =A0 =A0If this is published as Informational, then compliance is no longer appropriate - you don't comply to an Informational document. so the RFC2119 keywords should disappear. 2) Ask the WG which version of GDOI is supposed to be used? See Sean's Comments. 3) The document needs a good rewrite, especialy the Abstract and Introduction. There are Discusses and Comments from many that the document doesn't describe its purpose. This must be clairified. 4) There are Discusses and Comments from multiple ADs that must be addressed: Ron: just remove the reference; I don't know if you want to carry any information from that expired mboned doc into this doc. Adrian: clarify what is considered a signaling protocol in this doc Gonzalo: no RFC2119 keywords in the Introduction (so normative text must be moved) Jari: internal references (are you using xml2rfc? they have ways to keep that in sync for you) =A0 =A0 =A0 =A0clarify how you expect this to be used re: SDP, XML, etc. Russ: Gen-ART review Sean: "MAY encrypt" =A0 =A0 =A0 =A0MUST is for implementers - see RFC 3365 - unless this is Informational. =A0 =A0 =A0 =A0GDOI - explain how to use this. Clarify which version. Stephen: "MAY encrypt" =3D> "SHOULD encrypt using PGP or CMS"? =A0 =A0 =A0 =A0GDOI - how to use to manage keys? Pete: If Informational, then you can ignore his comment; If Experimental, then describe the experiment. Robert: new versus copied requirements; point to the existing rules rather than copying them here. =A0 =A0 =A0 =A0The #2 comment is critical - are implementers supposed to choose from one of these protocols =A0 =A0 =A0 =A0(i.e., these are the only ones allowed in a compliant Experimental implementation?) rpt-raptor: 1) A registration request must be sent to ietf-types@iana.org to register the types, per section 5.1 of RFC 4288. The registration template needs to be filled in 2) There are discusses from Sean, Pete, Robert and Stephen that must be addressed, and Comments from Russ (the Gen-ART review) that should be addressed in a Revised ID. I think the usage of RFC2119 keywords is acceptable, but might be improved. Please read and **consider** Pete's comments on RFC2119 usage, and then do what you think is right. Please get these Revised IDs done asap so I can send them off to the RFC Editor. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401=A0(cell) From abegen@cisco.com Wed Nov 9 18:21:58 2011 Return-Path: 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 D536E21F84A2 for ; Wed, 9 Nov 2011 18:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 CDiiW7gWObLf for ; Wed, 9 Nov 2011 18:21:58 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1833F21F84A1 for ; Wed, 9 Nov 2011 18:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=4029; q=dns/txt; s=iport; t=1320891718; x=1322101318; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6Hi+1ggsGtK+chdiBIiIbJ+GHc8Neg+a8/KHzTf50Dc=; b=IgJ+7ZMpDlTdLXkvyTbXZjHJFWTTou9ntVKGbhnZd1SOcZAZQv78q0Bx roapDld7eJM2zZc7Mcx5Io++Jr/AlmyySiENZUuSe+/alGVXawJSYOeth 6nYORvP/5ymZfRed4vn5fAaWpW5t9G8ywQwizKKQeq7/lDNqz22XLHDjs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AALk0u06rRDoJ/2dsb2JhbABAA5ooj3yBBYFyAQEBBAEBAQ8BHT4XBAIBCBEDAQEBCwYXAQYBIAYfCQgBAQQBEggah2iZGgGfBwSGaII0YwSIDJFXhQaHTw X-IronPort-AV: E=Sophos;i="4.69,486,1315180800"; d="scan'208";a="13334372" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Nov 2011 02:21:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAA2LvGZ006576; Thu, 10 Nov 2011 02:21:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 18:21:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2011 18:21:53 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541045F8EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Fwd: IESG Eval followup: config-signaling anf rtp-raptor Thread-Index: Acya/jzfO4VzeZGdSfC1zaQT9Kj5UwEUTndQ References: From: "Ali C. Begen (abegen)" To: , "Rajiv Asati (rajiva)" , X-OriginalArrivalTime: 10 Nov 2011 02:21:57.0717 (UTC) FILETIME=[8574F850:01CC9F4F] Subject: Re: [Fecframe] Fwd: IESG Eval followup: config-signaling anf rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 02:21:58 -0000 I prefer it to be informational FWIW. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Friday, November 04, 2011 11:30 PM > To: Rajiv Asati (rajiva); fecframe@ietf.org > Subject: [Fecframe] Fwd: IESG Eval followup: config-signaling anf = rtp-raptor >=20 > *, >=20 > There are a few things holding up the config-sig draft, but the one we > need to help with is: >=20 > MUST this doc progress as experimental, or is there WG consensus to > move it to informational? >=20 > Please reply promptly to the list. >=20 > Thanks!, > Greg >=20 >=20 > ---------- Forwarded message ---------- > From: David Harrington > Date: Fri, Nov 4, 2011 at 7:23 AM > Subject: IESG Eval followup: config-signaling anf rtp-raptor > To: gjshep@gmail.com > Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org, > draft-ietf-fecframe-rtp-raptor@tools.ietf.org >=20 >=20 > Hi, >=20 > The IESG reviewed the config signaling and rtp-raptor drafts. > We have work to do. >=20 > config-signaling: > 1) Can we publish this as Informational? > =A0 =A0 =A0 =A0Is that a problem for any cross-SDO work? > =A0 =A0 =A0 =A0If this is published as Informational, then compliance = is no > longer appropriate - you don't comply to an Informational document. so > the RFC2119 keywords should disappear. >=20 > 2) Ask the WG which version of GDOI is supposed to be used? See Sean's > Comments. >=20 > 3) The document needs a good rewrite, especialy the Abstract and > Introduction. There are Discusses and Comments from many that the > document doesn't describe its purpose. This must be clairified. >=20 > 4) There are Discusses and Comments from multiple ADs that must be > addressed: > Ron: just remove the reference; I don't know if you want to carry any > information from that expired mboned doc into this doc. > Adrian: clarify what is considered a signaling protocol in this doc > Gonzalo: no RFC2119 keywords in the Introduction (so normative text > must be moved) > Jari: internal references (are you using xml2rfc? they have ways to > keep that in sync for you) > =A0 =A0 =A0 =A0clarify how you expect this to be used re: SDP, XML, = etc. > Russ: Gen-ART review > Sean: "MAY encrypt" > =A0 =A0 =A0 =A0MUST is for implementers - see RFC 3365 - unless this = is > Informational. > =A0 =A0 =A0 =A0GDOI - explain how to use this. Clarify which version. > Stephen: "MAY encrypt" =3D> "SHOULD encrypt using PGP or CMS"? > =A0 =A0 =A0 =A0GDOI - how to use to manage keys? > Pete: If Informational, then you can ignore his comment; If > Experimental, then describe the experiment. > Robert: new versus copied requirements; point to the existing rules > rather than copying them here. > =A0 =A0 =A0 =A0The #2 comment is critical - are implementers supposed = to > choose from one of these protocols > =A0 =A0 =A0 =A0(i.e., these are the only ones allowed in a compliant > Experimental implementation?) >=20 > rpt-raptor: > 1) A registration request must be sent to ietf-types@iana.org to > register the types, per section 5.1 of RFC 4288. The registration > template needs to be filled in >=20 > 2) There are discusses from Sean, Pete, Robert and Stephen that must > be addressed, and Comments from Russ (the Gen-ART review) that should > be addressed in a Revised ID. I think the usage of RFC2119 keywords is > acceptable, but might be improved. Please read and **consider** Pete's > comments on RFC2119 usage, and then do what you think is right. >=20 > Please get these Revised IDs done asap so I can send them off to the > RFC Editor. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401=A0(cell) > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From internet-drafts@ietf.org Thu Nov 24 00:15:13 2011 Return-Path: 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 D3C8421F8A95; Thu, 24 Nov 2011 00:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 eUqkqav8d-51; Thu, 24 Nov 2011 00:15:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03C21F8480; Thu, 24 Nov 2011 00:15:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111124081511.21880.82947.idtracker@ietfa.amsl.com> Date: Thu, 24 Nov 2011 00:15:11 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-raptor-06.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 08:15:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Raptor FEC Schemes for FECFRAME Author(s) : Mark Watson Thomas Stockhammer Michael Luby Filename : draft-ietf-fecframe-raptor-06.txt Pages : 21 Date : 2011-11-24 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-06.txt From stockhammer@nomor.de Thu Nov 24 07:16:05 2011 Return-Path: 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 3849321F8B63 for ; Thu, 24 Nov 2011 07:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bWchyx0ywXSH for ; Thu, 24 Nov 2011 07:16:04 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id C906F21F8ACE for ; Thu, 24 Nov 2011 07:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322147758; l=6553; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=j7CePFb2zi9ORvyyKKSg4xHiLKE=; b=vCK8lHnewLY8MMliLfYwHfaNPDDlnfo1nDDzirhYWdUYsTfN+/cFsnUQGtK5YH+owDA gWXt+XVKnrHPIyl/ck1ySYkWarPPgoV3TLho3MaVKG/cyolyVZt00M5ug53+oX3jfa+5N /2oxXSYA39oFf45YDEODsQrCV25XoyCS9ug= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.170] ([93.104.202.244]) by smtp.strato.de (cohen mo10) (RZmta 26.10 AUTH) with ESMTPA id 903c94nAOFDsSE ; Thu, 24 Nov 2011 16:15:52 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <1D8D7D5D-FC0A-4A45-9AAE-D6AF830177BF@inrialpes.fr> Date: Thu, 24 Nov 2011 16:15:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EAA4FB5-5582-45C5-B02F-9AE49E6939D9@nomor.de> References: <20111020134716.20244.40862.idtracker@ietfa.amsl.com> <3D4BEDE3-3F17-49CC-A28C-B4FCAF3C4626@inrialpes.fr> <4EA7123A.40108@gmail.com> <1D8D7D5D-FC0A-4A45-9AAE-D6AF830177BF@inrialpes.fr> To: Vincent Roca X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-fecframe-rtp-raptor.all@tools.ietf.org, Brian E Carpenter , fecframe@ietf.org Subject: Re: [Fecframe] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:16:05 -0000 Vincent, while working on the RTP Raptor draft, I came over this comment. It seems to be more suitable to add a statement into the FEC scheme = draft=20 http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-06.txt at the end of section 8.2.2 as follows: Note also that the source packet flow processed by the FEC encoder MUST have consecutive sequence numbers. In case the incoming source packet flow has a gap in the sequence numbers then implementors SHOULD insert an ADU in the source block that complies to the format of the source packet flow, but is ignored at the application with high probability. For additional guidelines refer to [RFC6363], Section 10.2, paragraph 5. If this is ok, I would upload a new version of the Raptor FEC schemes = with only his change. Thanks Thomas On Nov 4, 2011, at 1:47 PM, Vincent Roca wrote: > Hello Brian, >=20 > First of all, sorry for the small delay in answering your email. >=20 > I agree, this document shall not duplicate procedures and formats = defined in=20 > [I-D.ietf-fecframe-raptor]. However what I'm highlighting here is a = requirement > that, if not fulfilled, can make a FECFRAME encoder fail. >=20 > It's quite simple to understand: since this RTP framing prevents the = FECFRAME > encoding instance to change the RTP source packet, all the RTP SN of a = given > source block must be in sequence. No gap is possible since the RTP = Raptor > scheme does not authorize it. >=20 > For most use-cases this is not an issue, as this "no loss before the = FECFRAME > encoding instance" is guaranteed. The only problem is that this = REQUIRED > property (in RFC2119 meaning) is not mentioned in = [draft-ietf-fecframe-rtp-raptor-05]. > It seems to me it is not mentioned either in = [I-D.ietf-fecframe-raptor] (at least > not in Section 8.2.4. "Procedures for RTP source flows" where it = should). >=20 > We discussed this topic on the list earlier this year. I've also added = a dedicated > bullet in RFC6363 to discuss it (10.2. "Operational and Management > Recommendations") with recommendations of what could be done if the > problem arises. So it's pretty easy to fix, it's just a matter of = adding a > sentence and a pointer to RFC6363... But please, do not leave this key > requirement implicit. >=20 > Regards, >=20 > Vincent >=20 >=20 > On Oct 25, 2011, at 21:47, Brian E Carpenter wrote: >> Speaking as the Gen-ART reviewer*, IMHO the normative reference to >> RFC 6363 (still disguised as draft-ietf-fecframe-framework) >> seems clear enough: >>=20 >> Procedures and data formats for the use of Raptor Forward Error >> Correction in a FECFRAME context are fully defined in >> [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor] and are >> not duplicated here. The procedures of those documents SHALL be >> followed in order to generate repair data streams to be carried by >> the payload formats defined in this document. >>=20 >> Regards >> Brian Carpenter >>=20 >> * http://www.ietf.org/mail-archive/web/gen-art/current/msg06833.html >>=20 >>=20 >>=20 >> On 2011-10-25 20:27, Vincent Roca wrote: >>> Hi everybody, >>>=20 >>> I've already mentioned this point in March 18th, this year, in the >>> FECFrame list. >>>=20 >>> 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. >>>=20 >>> This is a key requirement that MUST be clearly stated rather than >>> being left implicit. >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> 10.2. Operational and Management Recommendations >>> [...] >>> 5. Management of Communication Issues before Reaching the Sending >>> FECFRAME Instance: >>>=20 >>> Cheers, >>>=20 >>> Vincent >>>=20 >>>=20 >>> 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' >>>> as a Proposed Standard >>>>=20 >>>> 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. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ >>>>=20 >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ >>>>=20 >>>>=20 >>>> No IPR declarations have been submitted directly on this I-D. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>>=20 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From internet-drafts@ietf.org Thu Nov 24 07:29:48 2011 Return-Path: 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 704C621F8B8A; Thu, 24 Nov 2011 07:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pcP5qK5fxjxL; Thu, 24 Nov 2011 07:29:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09D721F8B6C; Thu, 24 Nov 2011 07:29:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111124152947.18106.66130.idtracker@ietfa.amsl.com> Date: Thu, 24 Nov 2011 07:29:47 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-raptor-07.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:29:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Raptor FEC Schemes for FECFRAME Author(s) : Mark Watson Thomas Stockhammer Michael Luby Filename : draft-ietf-fecframe-raptor-07.txt Pages : 22 Date : 2011-11-24 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.txt From stockhammer@nomor.de Thu Nov 24 07:31:20 2011 Return-Path: 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 006B221F8BB5 for ; Thu, 24 Nov 2011 07:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1TiEfa3fM3N0 for ; Thu, 24 Nov 2011 07:31:19 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E921F8BB1 for ; Thu, 24 Nov 2011 07:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322148677; l=13639; s=domk; d=nomor.de; h=Mime-Version:To:References:Date:Subject:Content-Type:From: X-RZG-CLASS-ID:X-RZG-AUTH; bh=r3jtZtWqCKS4yDG/3Ky+e5ktuhE=; b=KrmL3mqR+zuaI32MNSvBazlnl6EIiwywGo+q8B329jPwNx7+BvzhQ1OcdVhC65ZrGkY o3e2vULbOA/+/P5srt9dXS50BHPwDGlhOFXyqbzrfqbKDIBQiCQnKpwBzTp5jT5s5+mgv RGeAR1hVgDSRwcIYdVbSYTMZmAs6LAL8fNg= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.170] ([93.104.202.244]) by smtp.strato.de (jimi mo43) (RZmta 26.10 AUTH) with ESMTPA id Q04d1bnAODfeGg for ; Thu, 24 Nov 2011 16:31:00 +0100 (MET) From: Thomas Stockhammer Content-Type: multipart/alternative; boundary="Apple-Mail=_4BDD0F40-FB07-4A8B-AD3A-52F9B56089AE" Date: Thu, 24 Nov 2011 16:30:59 +0100 References: <20111124152947.18106.66130.idtracker@ietfa.amsl.com> To: fecframe@ietf.org Message-Id: <71932A2F-4714-420D-958E-A606A7C738AF@nomor.de> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [Fecframe] Fwd: I-D Action: draft-ietf-fecframe-raptor-07.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:31:20 -0000 --Apple-Mail=_4BDD0F40-FB07-4A8B-AD3A-52F9B56089AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, another small update to address the comment from Vincent providing a = pointer to the framework on the matter of non-consecutive sequence = numbers. Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [Fecframe] I-D Action: draft-ietf-fecframe-raptor-07.txt > Date: November 24, 2011 4:29:47 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: fecframe@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the FEC Framework Working = Group of the IETF. >=20 > Title : Raptor FEC Schemes for FECFRAME > Author(s) : Mark Watson > Thomas Stockhammer > Michael Luby > Filename : draft-ietf-fecframe-raptor-07.txt > Pages : 22 > Date : 2011-11-24 >=20 > This document describes Fully-Specified Forward Error Correction > (FEC) Schemes for the Raptor and RaptorQ codes and their application > to reliable delivery of media streams in the context of FEC > Framework. The Raptor and RaptorQ codes are systematic codes, where > a number of repair symbols are generated from a set of source = symbols > and sent in one or more repair flows in addition to the source > symbols that are sent to the receiver(s) within a source flow. The > Raptor and RaptorQ codes offer close to optimal protection against > arbitrary packet losses at a low computational complexity. Six FEC > Schemes are defined, two for protection of arbitrary packet flows, > two that are optimised for small source blocks and another two for > protection of a single flow that already contains a sequence number. > Repair data may be sent over arbitrary datagram transport (e.g. = UDP) > or using RTP. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.txt >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail=_4BDD0F40-FB07-4A8B-AD3A-52F9B56089AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Subject: [Fecframe] I-D Action: = draft-ietf-fecframe-raptor-07.txt
Date: November 24, 2011 = 4:29:47 PM GMT+01:00

A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the FEC = Framework Working Group of the IETF.

Title =           : Raptor FEC = Schemes for FECFRAME
Author(s) =       : Mark Watson
=             &n= bsp;           &nbs= p;Thomas Stockhammer
=             &n= bsp;           &nbs= p;Michael Luby
Filename =        : = draft-ietf-fecframe-raptor-07.txt
Pages =           : = 22
= Date =            : = 2011-11-24

  This document describes Fully-Specified = Forward Error Correction
  (FEC) Schemes for the Raptor = and RaptorQ codes and their application
  to reliable = delivery of media streams in the context of FEC
=   Framework.  The Raptor and RaptorQ codes are systematic = codes, where
  a number of repair symbols are generated = from a set of source symbols
  and sent in one or more = repair flows in addition to the source
  symbols that are = sent to the receiver(s) within a source flow.  The
=   Raptor and RaptorQ codes offer close to optimal protection = against
  arbitrary packet losses at a low computational = complexity.  Six FEC
  Schemes are defined, two for = protection of arbitrary packet flows,
  two that are = optimised for small source blocks and another two for
=   protection of a single flow that already contains a sequence = number.
  Repair data may be sent over arbitrary datagram = transport (e.g.  UDP)
  or using RTP.


A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.txt=

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-07.tx= t

_______________________________________________
Fecframe = mailing = list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecfram= e

stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.






= --Apple-Mail=_4BDD0F40-FB07-4A8B-AD3A-52F9B56089AE-- From stockhammer@nomor.de Fri Nov 25 03:44:44 2011 Return-Path: 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 EFC5921F8B8D; Fri, 25 Nov 2011 03:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 o2gmy74H6uxi; Fri, 25 Nov 2011 03:44:44 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1A821F8B89; Fri, 25 Nov 2011 03:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322221479; l=1773; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=7Xf2nCge+dhreIZlN3dIXKFPssw=; b=plhuv6DyOR6fMwZRN5WlJ8vE9Eb1Hry0joOxrc3y+JnAKHTpFb9RAhcTmy17Nh1d/TP VDNSqrpXd/+9sTJhYWUeKvAIvSs6klVSiDCKldegAett52T3tW7NTwGrXPihJfjvpbN3l C1EI99A64mSTjJVk6YPsaD3EVkcoF9e9gRk= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.170] ([93.104.202.244]) by smtp.strato.de (jimi mo7) (RZmta 26.10 AUTH) with ESMTPA id 605d49nAPAWXgC ; Fri, 25 Nov 2011 12:44:34 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> Date: Fri, 25 Nov 2011 12:44:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02A6EFD6-843A-4191-A8FE-CE36D4CDBB07@nomor.de> References: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1251.1) Cc: payload@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 11:44:45 -0000 Ali, thanks for the comments. All of the comments will be addressed in an = updated revision to be published shortly. Thomas > Minor comments: > - The framework draft was published as RFC 6363, the citation should = be updated. > - 2119 keywords should not be used in the intro section. Just make = them small letters. > - Provide some example apps in the registration section (Applications = that use this media type: is empty) > - Controller should be PAYLOAD WG not AVT.=20 > - I-D.ietf-fecframe-sdp-elements is also RFC 6364 now. >=20 > -acbegen >=20 >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Greg Shepherd >> Sent: Monday, October 10, 2011 4:03 PM >> To: fecframe@ietf.org; payload@ietf.org >> Subject: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt >>=20 >> Please read, review, comment - a comment of support is also helpful - >> ASAP. This WG is very close to being finished and this is one of the >> few last bits. >>=20 >> http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt >>=20 >> Thanks!, >> Greg >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From stockhammer@nomor.de Fri Nov 25 04:15:11 2011 Return-Path: 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 9759C21F8C78 for ; Fri, 25 Nov 2011 04:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6] 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 sUD5M8VW9isR for ; Fri, 25 Nov 2011 04:15:10 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 877C621F8B3B for ; Fri, 25 Nov 2011 04:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322223306; l=32789; s=domk; d=nomor.de; h=To:References:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version: Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=6xVEH1MFJFdAx1ubJMSpKN0yLKw=; b=BiO9VSvBBCAt2rgECf2CKdi+dexNgTMQmFFW7xEqXVrgpyPvKHT6YHB3tvwAxvsOm6u 83G1DhfYxag1nOmIHAAaw1UHQY5iQ2Nsr+RuWpe5Mb9mFsMV7oqbwQJMYtBBJPo8k48nk xi8YfKEFEpLcgJODRMlZw7eHU1mYjLiTBEA= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.170] ([93.104.202.244]) by smtp.strato.de (fruni mo60) (RZmta 26.10 AUTH) with ESMTPA id x00347nAPAaoAp ; Fri, 25 Nov 2011 13:14:43 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_011784BE-CEA8-4C91-B6B6-DF8D660616A4" From: Thomas Stockhammer In-Reply-To: Date: Fri, 25 Nov 2011 13:14:43 +0100 Message-Id: <222C0AEA-9121-4917-BCE5-8D71814768A7@nomor.de> References: <20101125193001.16083.70034.idtracker@localhost> To: Colin Perkins X-Mailer: Apple Mail (2.1251.1) Cc: fecframe@ietf.org Subject: Re: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:15:11 -0000 --Apple-Mail=_011784BE-CEA8-4C91-B6B6-DF8D660616A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Colin, thanks for your comments: This e-mail had been missed some time ago and I will address your = comments in an updated draft to be made available shortly. Please find inline replies to your comments: Thomas > - Section 4.1: explain how the RTP payload type is chosen (dynamic = assignment) and signalled using SDP. [T] Yes, this has been added as follows: o Payload Type (PT): The payload type codes SHALL be assigned dynamically through non-RTP means. If SDP is used for signaling, the the rules in Section 7 SHALL apply. > - Section 4.1: explain how the SSRC is assigned, and how the repair = RTP session is associated with the source RTP session using RTCP. They = should probably be sent as separate RTP sessions, using RTCP CNAME to = align, but this somewhat depends on whether the FEC is systematic or = not. [T] This has been added as follows: o SSRC: The SSRC values MUST be set according to [RFC3550]. The SSRC value of the RTP repair flow MUST be different from the SSRC value of the protected source flow. In addition, in a new section 10.3 the following is added: 10.3. Usage of RTCP RTCP SHALL be used according to [RFC3550]. The repair RTP session SHOULD be sent in a separate RTP session and the two sessions MAY be associated using RTCP CNAME. > - Section 5: "Applications that use this media type" is not specified. [T] The following has been added: Applications that use this media type: Real-time multimedia applications like video streaming, audio streaming, and video conferencing. > - Section 10: the SDP is incorrect: RTP/AVT on the m=3D line should be = RTP/AVP and the fmt is not specified. [T] The SDP example is updated as follows: v=3D0 o=3Dali 1122334455 1122334466 IN IP4 fec.example.com s=3DRaptor RTP FEC Example t=3D0 0 a=3Dgroup:FEC-FR S1 R1 m=3Dvideo 30000 RTP/AVP 100 c=3DIN IP4 233.252.0.1/127 a=3Drtpmap:100 MP2T/90000 a=3Dfec-source-flow: id=3D0 a=3Dmid:S1 m=3Dapplication 30000 RTP/AVP 110 c=3DIN IP4 233.252.0.2/127 a=3Drtpmap:110 raptorfec/90000 a=3Dfmtp:110 raptor-scheme-id=3D1; Kmax=3D8192; T=3D128; P=3DA; = repair-window=3D200000 a=3Dmid:R1 > - Section 10: is the grouping using FID mandatory, or an example of = how it can be done? [T] The grouping is not mandatory, but if SDP is used then the signaling = according to RFC6364 is to be used. In the introduction to the example, = the following is added: This section provides an SDP [RFC4566] example. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). The 'group' attribute and the FEC grouping semantics defined in [RFC5888] and [RFC5956], respectively, are used to associate source and repair flows. We form one FEC group with the "a=3Dgroup:FEC S1 R1" line. = The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms. An Explicit Source FEC Payload ID is used for the source flow. > - Section 9 should probably give many more details on how the RTP = headers are constructed, and how the repair flow and source flows are = associated. It seems somewhat light. [T] The section is extended as follows: 10.1. Overview This document only specifies the repair flow construction when the repair packets are delivered with RTP. Source packet construction is covered in [I-D.ietf-fecframe-raptor]. This section provides an overview on how to generate a repair flow including the repair packets and on how to reconstruct missing source packets from a set of available source and repair packets. Detailed algorithms for the generation of Raptor and RaptorQ symbols are provided in [RFC5053] and [RFC6330], respectively. As per the FEC Framework document [RFC6363] the FEC Framework Configuration Information includes among others the identification of the repair flow(s) and the source flow(s). Methods to convey FEC Framework Configuration Information are provided in [I-D.ietf-fecframe-config-signaling]. Specifically, the reader is referred to the SDP elements document [RFC6364], which describes the usage of 'SDP' encoding format as an example encoding format for FEC Framework Configuration Information. For the generation of a repair flow o repair packets SHALL be constructed according to Section 10.2, and o RTCP SHALL be used according to Section 10.3. For the reconstruction of a source packets of a source RTP session at the receiver based on the availability of a source RTP session and an repair RTP session the procedures in Section 10.4 may be used. >=20 > Cheers, > Colin >=20 >=20 >=20 > On 25 Nov 2010, at 19:45, Thomas Stockhammer wrote: >> Experts, >>=20 >> we also have reactivated draft-ietf-fecframe-rtp-raptor-04. = Highlights of the changes compared to -03 >> - Update of authors >> - Alignment with draft-ietf-rmt-bb-fec-raptorq-04 >> - Alignment with draft-ietf-fecframe-raptor-03 >> - Alignment with draft-ietf-fecframe-11 >> - Some minor editorial updates >> - Updates of references >> - A significant amount of comments from Ali are integrated in the = revised version. Non-implemented comments were resolved offline with Ali >> - Some small comments from Mike Luby on terminology are integrated. >>=20 >> Thanks to Ali and Mike. >>=20 >> I think it is time to get this out of the queue.=20 >>=20 >> The document should also be forwarded to AVT once we have a stable = version. >>=20 >> Thanks and Best regards and Happy Thanksgivings ... >>=20 >> Thomas >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Internet-Drafts@ietf.org >>> Date: November 25, 2010 8:30:01 PM GMT+01:00 >>> To: i-d-announce@ietf.org >>> Cc: fecframe@ietf.org >>> Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the FEC Framework Working Group of the = IETF. >>>=20 >>>=20 >>> Title : RTP Payload Format for Raptor FEC >>> Author(s) : M. Watson, T. Stockhammer >>> Filename : draft-ietf-fecframe-rtp-raptor-04.txt >>> Pages : 25 >>> Date : 2010-11-25 >>>=20 >>> This document specifies an RTP payload format for Forward Error >>> Correction /(FEC) 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. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-04.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >> --- >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com >> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail=_011784BE-CEA8-4C91-B6B6-DF8D660616A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
- Section 4.1: explain how = the SSRC is assigned, and how the repair RTP session is associated with = the source RTP session using RTCP. They should probably be sent as = separate RTP sessions, using RTCP CNAME to align, but this somewhat = depends on whether the FEC is systematic or = not.

[T] This has been added = as follows:

  o  SSRC: The SSRC = values MUST be set according to [RFC3550].  The
  =     SSRC value of the RTP repair flow MUST be different from = the SSRC
      value of the protected source = flow.

In addition, in a new section 10.3 = the following is added:

10.3.  Usage = of RTCP

   RTCP SHALL be used = according to [RFC3550].  The repair RTP session
  =  SHOULD be sent in a separate RTP session and the two sessions MAY = be
   associated using RTCP = CNAME.


- Section 5: "Applications = that use this media type" is not = specified.

[T] The following = has been added:

Applications that use this = media type: Real-time multimedia
   applications = like video streaming, audio streaming, and video
  =  conferencing.


- Section 10: the = SDP is incorrect: RTP/AVT on the m=3D line should be RTP/AVP and the fmt = is not specified.

[T] The = SDP example is updated as follows:

  =    v=3D0
     o=3Dali 1122334455 = 1122334466 IN IP4 fec.example.com
  =    s=3DRaptor RTP FEC Example
    =  t=3D0 0
     a=3Dgroup:FEC-FR S1 = R1
     m=3Dvideo 30000 RTP/AVP = 100
     c=3DIN IP4 = 233.252.0.1/127
     a=3Drtpmap:100 = MP2T/90000
     a=3Dfec-source-flow: = id=3D0
     a=3Dmid:S1
    =  m=3Dapplication 30000 RTP/AVP 110
    =  c=3DIN IP4 233.252.0.2/127
    =  a=3Drtpmap:110 raptorfec/90000
    =  a=3Dfmtp:110 raptor-scheme-id=3D1; Kmax=3D8192; T=3D128; P=3DA; = repair-window=3D200000
    =  a=3Dmid:R1


- Section 10: is = the grouping using FID mandatory, or an example of how it can be = done?

[T] The grouping is = not mandatory, but if SDP is used then the signaling according to = RFC6364 is to be used. In the introduction to the example, the following = is added:

   This section = provides an SDP [RFC4566] example.  Assume we have = one
   source video stream (mid:S1) and one FEC = repair stream (mid:R1).  The
   'group' = attribute and the FEC grouping semantics defined in = [RFC5888]
   and [RFC5956], respectively, are used = to associate source and repair
   flows.  We = form one FEC group with the "a=3Dgroup:FEC S1 R1" line. =  The
   source and repair streams are sent to = the same port on different
   multicast groups. =  The repair window is set to 200 ms.  An = Explicit
   Source FEC Payload ID is used for the = source flow.


- Section 9 should = probably give many more details on how the RTP headers are constructed, = and how the repair flow and source flows are associated. It seems = somewhat = light.


[T] = The section is extended as follows:

10.1. =  Overview

   This document only = specifies the repair flow construction when the
  =  repair packets are delivered with RTP.  Source packet = construction is
   covered in = [I-D.ietf-fecframe-raptor].  This section provides = an
   overview on how to generate a repair flow = including the repair
   packets and on how to = reconstruct missing source packets from a set
   of = available source and repair packets.  Detailed algorithms for = the
   generation of Raptor and RaptorQ symbols are = provided in [RFC5053]
   and [RFC6330], = respectively.

   As per the FEC = Framework document [RFC6363] the FEC Framework
  =  Configuration Information includes among others the identification = of
   the repair flow(s) and the source flow(s). =  Methods to convey FEC
   Framework = Configuration Information are provided in
  =  [I-D.ietf-fecframe-config-signaling].  Specifically, the = reader is
   referred to the SDP elements document = [RFC6364], which describes the
   usage of 'SDP' = encoding format as an example encoding format for FEC
  =  Framework Configuration = Information.

   For the generation of = a repair flow

   o  repair = packets SHALL be constructed according to Section 10.2, = and

   o  RTCP SHALL be used = according to Section 10.3.

   For the = reconstruction of a source packets of a source RTP session = at
   the receiver based on the availability of a = source RTP session and an
   repair RTP session the = procedures in Section 10.4 may be = used.



Experts,

we also = have reactivated draft-ietf-fecframe-rtp-raptor-04. Highlights of = the changes compared to -03
- Update of authors
- = Alignment with draft-ietf-rmt-bb-fec-raptorq-04
- = Alignment with draft-ietf-fecframe-raptor-03
- = Alignment with draft-ietf-fecframe-11
- Some minor = editorial updates
- Updates of references
- A = significant amount of comments from Ali are integrated in the revised = version. Non-implemented comments were resolved offline with = Ali
- Some small comments from Mike Luby on terminology are = integrated.

Thanks to Ali and = Mike.

I think it is time to get this out of the = queue. 

The document should also be = forwarded to AVT once we have a stable = version.

Thanks and Best regards and Happy = Thanksgivings = ...

Thomas

<= div>
Begin forwarded message:

Date: November 25, 2010 8:30:01 PM = GMT+01:00
Subject: [Fecframe] I-D = Action:draft-ietf-fecframe-rtp-raptor-04.txt

= A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the FEC Framework Working = Group of the IETF.


Title =           : RTP = Payload Format for Raptor FEC
Author(s) =       : M. Watson, T. Stockhammer
Filename =        : = draft-ietf-fecframe-rtp-raptor-04.txt
Pages =           : = 25
= Date =            : = 2010-11-25

This document specifies an RTP payload format for = Forward Error
Correction /(FEC) 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.

A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapto= r-04.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
<M= ail Attachment>
_______________________________________________
Fecf= rame mailing list
Fecframe@ietf.org
https://www.ietf.o= rg/mailman/listinfo/fecframe

---
Dr. Thomas Stockhammer (CEO) = || stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com<= /div>
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.


=
_______________________________________________
Fecfram= e mailing list
Fecframe@ietf.org
https://www.ietf.o= rg/mailman/listinfo/fecframe


-- 
Colin Perkins




=
stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.






= --Apple-Mail=_011784BE-CEA8-4C91-B6B6-DF8D660616A4-- From internet-drafts@ietf.org Fri Nov 25 15:05:37 2011 Return-Path: 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 BCF8C21F8B6E; Fri, 25 Nov 2011 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 m7ikKOY9Xw0Q; Fri, 25 Nov 2011 15:05:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C721F8B5C; Fri, 25 Nov 2011 15:05:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111125230537.7974.39030.idtracker@ietfa.amsl.com> Date: Fri, 25 Nov 2011 15:05:37 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-rtp-raptor-06.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:05:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : RTP Payload Format for Raptor FEC Author(s) : Mark Watson Thomas Stockhammer Michael Luby Filename : draft-ietf-fecframe-rtp-raptor-06.txt Pages : 25 Date : 2011-11-25 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-06.txt From stockhammer@nomor.de Fri Nov 25 15:47:50 2011 Return-Path: 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 0976521F8B3D for ; Fri, 25 Nov 2011 15:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PFzRzkgXg3y5 for ; Fri, 25 Nov 2011 15:47:49 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A4221F8B38 for ; Fri, 25 Nov 2011 15:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322264863; l=14845; s=domk; d=nomor.de; h=To:Cc:References:Date:Subject:Content-Type:Mime-Version:From: X-RZG-CLASS-ID:X-RZG-AUTH; bh=8dXhGmSJYc5VsOzvW5M0Fw3g9tY=; b=VNdzwQvOb0ZYS6NgqNxTn3AtqnLrSNLS1KNGC/16FjR+4m/Zg8PbOG7hovE5A5vyIJT 1FRXU0V9UpTE0m17uDtuILWlxCS1hTOKjUHRU6P9d/6VRgbz47r+8b7DtI8eGFx1R4uwx xCh6Zak0JRs88RjMuJ1JQC0R6UIybli/FJ4= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Efz/5cQ= X-RZG-CLASS-ID: mo00 Received: from [192.168.1.3] (188-192-154-28-dynip.superkabel.de [188.192.154.28]) by post.strato.de (mrclete mo12) (RZmta 26.10 AUTH) with ESMTPA id N01763nAPMwrUH ; Sat, 26 Nov 2011 00:46:47 +0100 (MET) From: Thomas Stockhammer Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_630852F4-F1EA-4E68-BF4A-E6439F75DF1B" Date: Sat, 26 Nov 2011 00:46:47 +0100 References: <20111125230537.7974.39030.idtracker@ietfa.amsl.com> To: fecframe@ietf.org Message-Id: X-Mailer: Apple Mail (2.1251.1) Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-rtp-raptor@tools.ietf.org, Pete Resnick , Sean Turner , Perkins Colin , Robert Sparks Subject: [Fecframe] Fwd: I-D Action: draft-ietf-fecframe-rtp-raptor-06.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:47:50 -0000 --Apple-Mail=_630852F4-F1EA-4E68-BF4A-E6439F75DF1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, a new draft has been submitted based on comments received during the = IESG evaluation. The following are the major changes: - New author added: Mike Luby, Qualcomm - Reinserted Section 10 from version 04: Repair Flow Generation and = Recovery Procedures - Reinserted Section 11 from version 04: SDP example - Updated references - fixed RFC2119 language throughout document based on different comments - added Payload Type rules based on DISCUSS comment - changed timestamp rules based on DISCUSS comment - added SSRC rules based on DISCUSS comment - added format for repair-windon and rate - add applications that use this media type - change contact person - from version 04 section 10 added reference to = I-D.ietf-fecframe-config-signaling - from version 04 section 10 added in addition the usage of RTCP - from version 04 section 11, updated the SDP example and added = references to the grouping RFC. In addition, an e-mail was sent to ietf-types@iana.org to verify the = media type registration. DISCUSS and COMMENTS have been answered individually and refer to this = updated draft. Thanks to everyone for the support on moving this forward Thomas Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [Fecframe] I-D Action: draft-ietf-fecframe-rtp-raptor-06.txt > Date: November 26, 2011 12:05:37 AM GMT+01:00 > To: i-d-announce@ietf.org > Cc: fecframe@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the FEC Framework Working = Group of the IETF. >=20 > Title : RTP Payload Format for Raptor FEC > Author(s) : Mark Watson > Thomas Stockhammer > Michael Luby > Filename : draft-ietf-fecframe-rtp-raptor-06.txt > Pages : 25 > Date : 2011-11-25 >=20 > 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. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-06.txt >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail=_630852F4-F1EA-4E68-BF4A-E6439F75DF1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 ietf-types@iana.org = to verify the media type registration.

DISCUSS = and COMMENTS have been answered individually and refer to this updated = draft.

Thanks to everyone for the support on = moving this = forward

Thomas

Begin = forwarded message:

Subject: [Fecframe] I-D Action: = draft-ietf-fecframe-rtp-raptor-06.txt
Date: November 26, 2011 = 12:05:37 AM GMT+01:00

A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the FEC = Framework Working Group of the IETF.

Title =           : RTP = Payload Format for Raptor FEC
Author(s) =       : Mark Watson
=             &n= bsp;           &nbs= p;Thomas Stockhammer
=             &n= bsp;           &nbs= p;Michael Luby
Filename =        : = draft-ietf-fecframe-rtp-raptor-06.txt
Pages =           : = 25
= Date =            : = 2011-11-25

  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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapto= r-06.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-0= 6.txt

_______________________________________________
Fecframe = mailing = list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecfram= e

stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.






= --Apple-Mail=_630852F4-F1EA-4E68-BF4A-E6439F75DF1B-- From abegen@cisco.com Mon Nov 28 07:50:16 2011 Return-Path: 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 2A6BA21F8C16 for ; Mon, 28 Nov 2011 07:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NYHp6yViCvDj for ; Mon, 28 Nov 2011 07:50:15 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8321F8C07 for ; Mon, 28 Nov 2011 07:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1198; q=dns/txt; s=iport; t=1322495415; x=1323705015; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+dhYEgQWLP4fMq/paOBOiDTmOt3xqdOJnYJXFIRFGAI=; b=e8PS47LDcrJlp0ysW7ngUxgxg7+iPq/IoNbtiOHzrF6L62DuPOFvcbAs WSEiix2DhnByzhgsr0iL/XXTrEiRO0OUGyYoMgH1wTjSAQ1mI3qhBTqV7 rxa7Qp1ldgbqt8Lvz8O+XcnnhK0KzusXTLGXWJtRaxtGymM7FONaTWnM1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAAOt006rRDoH/2dsb2JhbABDml6QIIEFgXIBAQEEAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah2uYTgGeO4l/YwSIIZ5V X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; d="scan'208";a="16526118" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Nov 2011 15:50:15 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pASFoF9Y008020; Mon, 28 Nov 2011 15:50:15 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Nov 2011 07:50:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2011 07:50:21 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410650B55@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-simple-rs-01 Thread-Index: Acxy6MHYqChNt4IeT1u6DvUa6iYzgg6+LWSQ References: From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 28 Nov 2011 15:50:15.0463 (UTC) FILETIME=[6BCD3B70:01CCADE5] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-simple-rs-01 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 15:50:16 -0000 The document reads well. Mostly editorial comments: Intro: I think ALC and NORM have to be spelled out for completeness. Section 3.1: Why not refer to 6363 for all definitions and use the exact = wording from 6363. Alternatively, just remove the text and simply refer = to 6363. I also think figure 1 should be identical to figure 2 in 6363. Even = slight modifications could be confusing to readers. Section 4.3: missing " after "Group of Pictures (GOP) of an H.264 flow. Section 5.1.1.2: Says "Strict (S) flag", you mean mandatory? fssi =3D E:1400,S:0,m:8 should be "fssi=3DE:1400,S:0,m:8" > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Wednesday, September 14, 2011 10:15 AM > To: fecframe@ietf.org > Subject: [Fecframe] WGLC - draft-ietf-fecframe-simple-rs-01 >=20 > http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ >=20 > Please read and provide feedback as we're so close to finishing up = this WG. >=20 > Thanks! > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Mon Nov 28 09:10:27 2011 Return-Path: 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 1CF3321F889A for ; Mon, 28 Nov 2011 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vxJSwdpfbD32 for ; Mon, 28 Nov 2011 09:10:26 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 15CA321F8BA2 for ; Mon, 28 Nov 2011 09:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1082; q=dns/txt; s=iport; t=1322500226; x=1323709826; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aHMJmW4nJkU/tBXmxsrhvOKoq5ogAfTf3qY/+Wmt4zY=; b=G8Jk1nqUc8yr+SOKB/GQRuiABA2DXZjcapa+9Z5RsQ9+YDV7xVQMPhuo KAlq5zbyL7rfe221mYVMT2FCxC3NnXWCIO7ahxnoNU38Fnc6/lraqAlW5 BYhDPbVKhVxhdXrwXJ8SqT6RJtxqNUTd+gpj7EDGwU2tg/sonC7yHBdJQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AANa/006rRDoG/2dsb2JhbABDmkmQIIEFgXIBAQEEAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah2uYYwGeQIl/YwSIIZ5V X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208";a="16541881" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Nov 2011 17:10:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pASHANVf015912; Mon, 28 Nov 2011 17:10:23 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Nov 2011 09:10:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Nov 2011 09:10:06 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410650BB5@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 Thread-Index: Acxy6RiM39Y9jX5QTji0u8mcfZl9NA6+GKjA References: From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 28 Nov 2011 17:10:23.0245 (UTC) FILETIME=[9D768BD0:01CCADF0] Subject: Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 17:10:27 -0000 This document also reads well, text is largely based on the previous RS = draft. Mostly editorial comments: - Section 3.1: Again why not refer to 6363 for all definitions and use = the exact wording from 6363. Alternatively, just remove the text and = simply refer to 6363. - Figure 1 should be identical to figure 2 in 6363. - Remove the spaces in the fssi example. - SDP elements draft is now 6364. Cheers, -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Wednesday, September 14, 2011 10:18 AM > To: fecframe@ietf.org > Subject: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 >=20 > http://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc/ >=20 > ..and another WGLC. Please read and provide feedback so we can close > the group before Taipei and give David something to brag about. ;-) >=20 > Thanks!, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From internet-drafts@ietf.org Tue Nov 29 03:47:51 2011 Return-Path: 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 679D321F863E; Tue, 29 Nov 2011 03:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 60BmTpG4AiY7; Tue, 29 Nov 2011 03:47:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3A21F84C3; Tue, 29 Nov 2011 03:47:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111129114751.14397.95913.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 03:47:51 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-01.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 11:47:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Simple LDPC-Staircase Forward Error Correction (FEC) Sch= eme for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Filename : draft-ietf-fecframe-ldpc-01.txt Pages : 20 Date : 2011-11-29 This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-ldpc-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-ldpc-01.txt From internet-drafts@ietf.org Tue Nov 29 05:21:24 2011 Return-Path: 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 E0EA221F8BB0; Tue, 29 Nov 2011 05:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 txB6bpp1BsTz; Tue, 29 Nov 2011 05:21:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEE421F8B77; Tue, 29 Nov 2011 05:21:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111129132124.13872.6691.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 05:21:24 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-simple-rs-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 13:21:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Simple Reed-Solomon Forward Error Correction (FEC) Schem= e for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Amine Bouabdallah Kazuhisa Matsuzono Filename : draft-ietf-fecframe-simple-rs-02.txt Pages : 21 Date : 2011-11-29 This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <=3D m <=3D 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of LDPC codes for instance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-simple-rs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-simple-rs-02.txt From vincent.roca@inria.fr Tue Nov 29 05:35:53 2011 Return-Path: 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 B392D21F8C2B for ; Tue, 29 Nov 2011 05:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 FBw0dGDIZpgZ for ; Tue, 29 Nov 2011 05:35:53 -0800 (PST) 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 E230521F8C1F for ; Tue, 29 Nov 2011 05:35:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,591,1315173600"; d="scan'208";a="133157237" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.10]) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 29 Nov 2011 14:35:50 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410650BB5@xmb-sjc-215.amer.cisco.com> Date: Tue, 29 Nov 2011 14:35:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <398D928C-5B44-427A-9969-0C31D702CBBF@inria.fr> References: <04CAD96D4C5A3D48B1919248A8FE0D5410650BB5@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" , Martin Ellis X-Mailer: Apple Mail (2.1084) Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 13:35:53 -0000 Hello everybody, Thanks a lot Ali and Martin for your reviews of this draft as well as = the RS draft. I'm doing a common response since we did our best to keep both documents = as close to one another as possible. =46rom Ali: > - Section 3.1: Again why not refer to 6363 for all definitions and use = the exact wording from 6363. Alternatively, just remove the text and = simply refer to 6363. We've aligned the definitions with RFC6363. That's a good point. We've kept a few additional sentences here and there when there is something specific to the LDPC (resp. RS) FEC Scheme. We've also kept a definition that is not in RFC6363, namely=20 "ADU Block", which we differentiate from the "source block". It depends on the point of view in fact: - FECFRAME instance =3D> ADU block - FEC Scheme =3D> source block If we go into the details, the source block is composed of symbols created from the ADUIs, not the ADUs. There are a few additional bytes considered during the encoding process. > - Figure 1 should be identical to figure 2 in 6363. Done. > - Remove the spaces in the fssi example. Good catch! > - SDP elements draft is now 6364.- Corrected. =46rom Martin: > The last 2 paragraphs of section 4.2 discuss a max_rt parameter,=20 > which restricts the ADU block size for the real-time constraints of a > particular application. Would it be appropriate to give an example > here? (this also applies to the simple-rs draft). We've added an example as suggested. We've also improved the full section 4.2 for better clarity. > - In section 7.1, some specific numbers are given on levels of=20 > overhead required to reduce residual loss rates. Are these results > based on the [Matsuzono10] reference? If so, I think it would be > better to say so explicitly (and briefly mention the assumptions made > in that study; i.e., uniform random packet loss). As said before, these results come from an evaluation of the LDPC codes, using a dedicated simulator. However they give an idea of what performance (in terms of erasure recovery) can be expected for real use-cases if these codes are correctly used.=20 We've added "independently of FECFRAME" before introducing the results, which we hope will be sufficient to clarify the point. Thanks! Greg, unless new reviews are expected, we think both I-Ds are ready. Regards, Vincent, on behalf of the authors