From abegen@cisco.com Tue Feb 2 08:24:32 2010 Return-Path: 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 C0C643A692D; Tue, 2 Feb 2010 08:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 kyGYNXeZcau5; Tue, 2 Feb 2010 08:24:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8D92E3A68E7; Tue, 2 Feb 2010 08:24:31 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC3hZ0urR7H+/2dsb2JhbADBOJgihEUE X-IronPort-AV: E=Sophos;i="4.49,391,1262563200"; d="scan'208";a="476947837" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2010 16:25:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o12GPAap023602; Tue, 2 Feb 2010 16:25:10 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.3959); Tue, 2 Feb 2010 08:25:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Feb 2010 08:25:22 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B2CB176@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4B621DCA.6050506@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05) Thread-Index: AcqgcbW1ZuBEesR7QOm7pYxm6hqciQDsfBQw References: <27887E65-F19F-405C-B1ED-E04FB41452C5@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540B23D7FE@xmb-sjc-215.amer.cisco.com> <846E11BB-CAB7-43DD-A532-246926CBEA9B@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540B23D8C5@xmb-sjc-215.amer.cisco.com> <4B621DCA.6050506@digium.com> From: "Ali C. Begen (abegen)" To: "Kevin P. Fleming" X-OriginalArrivalTime: 02 Feb 2010 16:25:10.0551 (UTC) FILETIME=[4A484A70:01CAA424] Cc: mmusic@ietf.org, fecframe@ietf.org, Robert Sparks Subject: Re: [Fecframe] [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 16:24:32 -0000 OK, I talked to Robert and I propose to change the draft from obsoleting 4756 to updating it (there is no "deprecated" keyword for the drafts). There will be a note in section 3.1: This document introduces the changes required in the FEC grouping semantics and updates [RFC4756]. New implementations SHOULD use the new semantics introduced in this document whenever possible, but they may need to use [RFC4756] semantics when backward compatibility is desired, as described in Section 4.4. Before we go ahead with the revision, please let me know if you are not OK with this change. If there are no objections, we will move forward with this change. Thanks, -acbegen > -----Original Message----- > From: Kevin P. Fleming [mailto:kpfleming@digium.com] > Sent: Thursday, January 28, 2010 6:29 PM > To: Ali C. Begen (abegen) > Cc: Robert Sparks; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD > Review:draft-ietf-mmusic-rfc4765bis-05) >=20 > Ali C. Begen (abegen) wrote: >=20 > > OK, right. "FEC" semantics are not defined in the new draft. If a new > > implementation wants to be able to speak to 4756 endpoints, it will need > > 4756. Then I guess you are disagreeing that we are obsoleting 4756. > > > > Well, I am not sure what is the right term here. At that time, I was > > told "obsoleting" was the right choice. To me, RFC 4756 will still be > > available for anybody who wants to be backward compatible anyway. So, I > > did not think it would be a problem. But, if you say it is a problem, I > > can't argue with that. >=20 > The correct word, in English at least, is 'deprecated'. The previous > version is still valid, but is not recommended for new implementations. >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kpfleming@digium.com > Check us out at www.digium.com & www.asterisk.org From pierre.roux@cea.fr Tue Feb 9 03:10:38 2010 Return-Path: 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 469323A7321 for ; Tue, 9 Feb 2010 03:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 N6PgQP5K4ddK for ; Tue, 9 Feb 2010 03:10:36 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 5F66E3A702D for ; Tue, 9 Feb 2010 03:10:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o19BBdo6009986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Feb 2010 12:11:40 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o19BBdhO004072 for ; Tue, 9 Feb 2010 12:11:39 +0100 (envelope-from pierre.roux@cea.fr) Received: from levau.intra.cea.fr (levau.intra.cea.fr [132.166.88.52]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o19BBcXJ002835 for ; Tue, 9 Feb 2010 12:11:39 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.44]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 12:11:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Feb 2010 12:11:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft submitted: draft-roux-fecframe-repacketization-00.txt Thread-Index: AcqpeJ+lkyqlrdhORoW2jrYsFzl+Wg== From: "ROUX Pierre" To: X-OriginalArrivalTime: 09 Feb 2010 11:11:28.0157 (UTC) FILETIME=[A02724D0:01CAA978] Subject: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 11:10:39 -0000 Dear all, I have recently submitted the following Internet-Draft: Title : Benefits of re-packetization for FEC based protection of multimedia streams Author(s) : P. Roux, C. Janneteau, K. Mounir Filename : draft-roux-fecframe-repacketization-00.txt Pages : 12 Date : 2010-2-9 URL:=20 http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- 00.txt This is an informational draft that presents the advantages of re-packetizing multimedia streams to be FEC protected, for better performance. Any kind of feedback about this Internet-Draft will be very welcomed. Best regards, Pierre From stockhammer@nomor.de Tue Feb 9 04:08:38 2010 Return-Path: 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 DE34F3A69B6 for ; Tue, 9 Feb 2010 04:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7sr-8D1T3AiS for ; Tue, 9 Feb 2010 04:08:37 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 87C753A71A3 for ; Tue, 9 Feb 2010 04:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1265717380; l=2987; s=domk; d=nomor.de; h=To:Date:Subject:From:Cc:Content-Transfer-Encoding:Content-Type: Mime-Version:In-Reply-To:References:X-RZG-CLASS-ID:X-RZG-AUTH; bh=tVEUV8ynRKIwa9IgxGpscLyIWN0=; b=pXOHKZs6a0/2lL+AxL3ECMSbRI2iU4mmhQQIWle5DTngO33jppTOTAIoAAR1xbnl8EG mTvsVusVVtRpxYzEk1PZqIpUpnNxnT2RxOTw0CzxCbutbmtMqlys8AA1ZR2BLP5KpGwie d1YTHDZROebpIES+B2iaQjtbUsdTm/pWDiQ= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFk7RnvKC67oOfpzXah2UgRw9hgiX9BbGWsas= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.149] (dialbs-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (mrclete mo41) (RZmta 22.6) with ESMTP id i04b26m19BPRt9 ; Tue, 9 Feb 2010 13:09:38 +0100 (MET) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Message-Id: Content-Transfer-Encoding: quoted-printable From: Thomas Stockhammer Date: Tue, 9 Feb 2010 13:09:37 +0100 To: "ROUX Pierre" X-Mailer: Apple Mail (2.1077) Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 12:08:39 -0000 Pierre, I quickly scanned through this draft. Some very initial comments: Comment 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D You strategy (c)=20 (c) Have small repair symbols but put many repair symbols per repair=20= packet.=20 and your pitfall: (c) will have poor performances because the loss of a single repair=20 packet will translate into a large number of repair symbol being=20 lost.=20 I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. Despite you loose more symbols, you also get more symbols from correct = packets. So it works very well, but you need a long code such as Raptor = or RaptorQ. Comment 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. Comment 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. It is also not clear why the alpha values are different for these = configurations. Can you explain? Best regards Thomas On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: > Dear all, > I have recently submitted the following Internet-Draft: >=20 > Title : Benefits of re-packetization for FEC based protection > of multimedia streams > Author(s) : P. Roux, C. Janneteau, K. Mounir > Filename : draft-roux-fecframe-repacketization-00.txt > Pages : 12 > Date : 2010-2-9 >=20 > URL:=20 > = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- > 00.txt >=20 > This is an informational draft that presents the advantages of > re-packetizing multimedia streams to be FEC protected, for better > performance. >=20 > Any kind of feedback about this Internet-Draft will be very welcomed. >=20 > Best regards, >=20 > Pierre > _______________________________________________ > 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 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. MWC 2010: Visit Nomor Research at booth 2F33 From pierre.roux@cea.fr Tue Feb 9 07:27:20 2010 Return-Path: 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 BFBDE3A73C7 for ; Tue, 9 Feb 2010 07:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 LwjqvWzKpVRb for ; Tue, 9 Feb 2010 07:27:19 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 73D673A73C5 for ; Tue, 9 Feb 2010 07:27:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o19FSNvB012294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2010 16:28:24 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o19FSLQ0020374; Tue, 9 Feb 2010 16:28:22 +0100 (envelope-from pierre.roux@cea.fr) Received: from levau.intra.cea.fr (levau.intra.cea.fr [132.166.88.52]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o19FSKAp008688; Tue, 9 Feb 2010 16:28:21 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.44]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Feb 2010 16:28:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Feb 2010 16:28:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt Thread-Index: AcqpgMjcyf55amDdTi6wLTexrzHFYQADgkyQ References: From: "ROUX Pierre" To: "Thomas Stockhammer" X-OriginalArrivalTime: 09 Feb 2010 15:28:15.0441 (UTC) FILETIME=[7F9C1C10:01CAA99C] Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:27:20 -0000 Thanks you for your quick feedback. Here are tentative answers. With respect to comment 1, I agree about your statement ("you get more = symbols form correct packets"). I also agree that this strategy can be = efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 With respect to comment 3: Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. As for the simulation results they are not far away so that it is = difficult to derive definitive conclusions. If we compare 20x16 to 10x32 = or 10x16 to 5x32, then the winner depends on which table we look at: = PLR=3D0.1 or PLR=3D0.2.=20 What you were expecting seems to be what we got with PLR=3D0.2. I hope it answers you first comments. Best regards. Pierre -----Message d'origine----- De=A0: Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 Envoy=E9=A0: Tuesday, February 09, 2010 1:10 PM =C0=A0: ROUX Pierre Cc=A0: fecframe@ietf.org Objet=A0: Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt Pierre, I quickly scanned through this draft. Some very initial comments: Comment 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D You strategy (c)=20 (c) Have small repair symbols but put many repair symbols per repair=20 packet.=20 and your pitfall: (c) will have poor performances because the loss of a single repair=20 packet will translate into a large number of repair symbol being=20 lost.=20 I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. Despite you loose more symbols, you also get more symbols from correct = packets. So it works very well, but you need a long code such as Raptor = or RaptorQ. Comment 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. Comment 3: =3D=3D=3D=3D=3D=3D=3D=3D=3D What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. It is also not clear why the alpha values are different for these = configurations. Can you explain? Best regards Thomas On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: > Dear all, > I have recently submitted the following Internet-Draft: >=20 > Title : Benefits of re-packetization for FEC based protection > of multimedia streams > Author(s) : P. Roux, C. Janneteau, K. Mounir > Filename : draft-roux-fecframe-repacketization-00.txt > Pages : 12 > Date : 2010-2-9 >=20 > URL:=20 > = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- > 00.txt >=20 > This is an informational draft that presents the advantages of > re-packetizing multimedia streams to be FEC protected, for better > performance. >=20 > Any kind of feedback about this Internet-Draft will be very welcomed. >=20 > Best regards, >=20 > Pierre > _______________________________________________ > 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 Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. MWC 2010: Visit Nomor Research at booth 2F33 From stockhammer@nomor.de Tue Feb 9 08:04:09 2010 Return-Path: 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 8846B3A7368 for ; Tue, 9 Feb 2010 08:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 wqKmVB-Kgzjh for ; Tue, 9 Feb 2010 08:04:08 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id DB31D3A71DF for ; Tue, 9 Feb 2010 08:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1265731513; l=6492; s=domk; d=nomor.de; h=To:Date:Subject:From:Cc:Content-Transfer-Encoding:Content-Type: Mime-Version:In-Reply-To:References:X-RZG-CLASS-ID:X-RZG-AUTH; bh=8x97T+sCleD0h8qSTimZ89iokKY=; b=IkSQenw6+0AQWhs/IS16oAnrC8JtONEVRsRK4xPkPjvFBSGUvzwcz/97aGOwC+P/vPm qHLOQ6yIYUn4061uCw4Y5VXpNa3VHcSmjLjcVIYmwidLa/vPGPK504SC2b/ewByECFdSK fz51Vs15kf+7dPRL6KdOkN8duHGjByXYpVY= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFk7RnvKC67oOfpzXZhm8gTfTrVt8qtNCusw== X-RZG-CLASS-ID: mo00 Received: from ip-109-85-71-158.web.vodafone.de ([109.85.71.158]) by post.strato.de (mrclete mo32) (RZmta 22.6) with ESMTP id V042d9m19G3tzN ; Tue, 9 Feb 2010 17:05:08 +0100 (MET) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Message-Id: Content-Transfer-Encoding: quoted-printable From: Thomas Stockhammer Date: Tue, 9 Feb 2010 17:05:06 +0100 To: "ROUX Pierre" X-Mailer: Apple Mail (2.1077) Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:04:09 -0000 Pierre, inline [Thomas] *** > With respect to comment 1, I agree about your statement ("you get more = symbols form correct packets"). I also agree that this strategy can be = efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. [Thomas] ***I am sorry, I miss the logic. If the source block size stays the = same, but you only change the dimensions, this does not change the = delay. You add the same amount of source packets in either case. This is = independent of the bitrate and delay tolerance. > With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 > Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 [Thomas] ***I still do not understand the use case, but if the use case is really = relevant (which I still need to be convinced) then you may use the FEC = Framework as is and only send repair packets. Then you can have packets = of the exact symbol size. So I do not see the necessity of a new layer = as backward-comptibility is anyways broken with this new layer. > With respect to comment 3: > Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. [Thomas] *** Still not getting it. Which padding are you referring to? In FEC = framework the packets are sent unmodified (in case RTP is used) and your = repair packets all have the same size. So where would the extra overhead = come from? The padding in the source block to create the source symbols = is never "transmitted". > As for the simulation results they are not far away so that it is = difficult to derive definitive conclusions. If we compare 20x16 to 10x32 = or 10x16 to 5x32, then the winner depends on which table we look at: = PLR=3D0.1 or PLR=3D0.2.=20 > What you were expecting seems to be what we got with PLR=3D0.2. [Thomas] *** Again see above, I do not understand the logic. You are sending the = same amount if repair packets, all of the same size, and you are also = sending the same source packets and you are using MDS codes, so why = would there be any difference? Thomas >=20 > I hope it answers you first comments. >=20 > Best regards. >=20 > Pierre >=20 > -----Message d'origine----- > De : Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 > Envoy=E9 : Tuesday, February 09, 2010 1:10 PM > =C0 : ROUX Pierre > Cc : fecframe@ietf.org > Objet : Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt >=20 > Pierre, >=20 > I quickly scanned through this draft. Some very initial comments: >=20 > Comment 1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > You strategy (c)=20 > (c) Have small repair symbols but put many repair symbols per repair=20= > packet.=20 > and your pitfall: > (c) will have poor performances because the loss of a single repair=20 > packet will translate into a large number of repair symbol being=20 > lost.=20 >=20 > I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. > Despite you loose more symbols, you also get more symbols from correct = packets. So it works very well, but you need a long code such as Raptor = or RaptorQ. >=20 > Comment 2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. >=20 > Comment 3: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. > It is also not clear why the alpha values are different for these = configurations. Can you explain? >=20 > Best regards >=20 > Thomas >=20 >=20 > On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: >=20 >> Dear all, >> I have recently submitted the following Internet-Draft: >>=20 >> Title : Benefits of re-packetization for FEC based = protection >> of multimedia streams >> Author(s) : P. Roux, C. Janneteau, K. Mounir >> Filename : draft-roux-fecframe-repacketization-00.txt >> Pages : 12 >> Date : 2010-2-9 >>=20 >> URL:=20 >> = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >> 00.txt >>=20 >> This is an informational draft that presents the advantages of >> re-packetizing multimedia streams to be FEC protected, for better >> performance. >>=20 >> Any kind of feedback about this Internet-Draft will be very welcomed. >>=20 >> Best regards, >>=20 >> Pierre >> _______________________________________________ >> 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 > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 > MWC 2010: Visit Nomor Research at booth 2F33 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 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. MWC 2010: Visit Nomor Research at booth 2F33 From Einat@radvision.com Wed Feb 10 01:28:59 2010 Return-Path: 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 47D203A68F2 for ; Wed, 10 Feb 2010 01:28:59 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIZlEjHms2nC for ; Wed, 10 Feb 2010 01:28:58 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id CBB893A6B67 for ; Wed, 10 Feb 2010 01:28:54 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o1A9Tr7t001490 for fecframe@ietf.org; Wed, 10 Feb 2010 11:29:53 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o1A9TqhX001484; Wed, 10 Feb 2010 11:29:52 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Feb 2010 11:30:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt Thread-Index: Acqpoa/G/rlRHXZ1S+6CO575IeBsYAAjokUw References: From: "Einat Yellin (Lachover)" To: "Thomas Stockhammer" , "ROUX Pierre" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o1A9TqhX001484 Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:28:59 -0000 Hi, Adding to the discussion. In general the ideal behind leveling the unit sizes in FEC is good, but I believe that with the suggested draft it could fail in practice. On top of the backward compatibility "small" issue, there is also a computational drawback in implementing this. If I understand correctly both sender and receiver would be required to rearrange RTP packets, which means recopying the bytes and producing new RTP headers. Other comments that I would like to make are about different assumptions in the Appendix: A. Block periodicity of 500ms is way to high if you target low-latency applications. It means that in some cases the receiver would have to wait 500 ms before packet restore can be done. B. FEC bit rate that equals source bit rate seems to be unrealistic IMHO. If, as you suggested, you target low bitrate video you will get better quality by using more bitrate for the video itself and use only a fraction of the bit rate for FEC, especially in the common cases of up to 5% packet loss - see C. C. Packet loss rates - I think that you should experiment with lower and more typical packet losses in the range of 1-5% as well. Regards, Einat -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Thomas Stockhammer Sent: Tuesday, February 09, 2010 6:05 PM To: ROUX Pierre Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt Pierre, inline [Thomas] *** > With respect to comment 1, I agree about your statement ("you get more symbols form correct packets"). I also agree that this strategy can be efficient with long codes. The context that we were interested in in this draft is when we can't afford long codes (low bitrates and no tolerance about latency). Then this strategy (short symbols and many symbols per repair packet) is probably not the best one. [Thomas] ***I am sorry, I miss the logic. If the source block size stays the same, but you only change the dimensions, this does not change the delay. You add the same amount of source packets in either case. This is independent of the bitrate and delay tolerance. > With respect to comment 2: OK for the lack of backward compatibility. This drawback is pointed out in the draft. > Exploiting RFC3984 is also a worthy suggestion. The advantage of the "new layer" is that it is applicable to any media stream. [Thomas] ***I still do not understand the use case, but if the use case is really relevant (which I still need to be convinced) then you may use the FEC Framework as is and only send repair packets. Then you can have packets of the exact symbol size. So I do not see the necessity of a new layer as backward-comptibility is anyways broken with this new layer. > With respect to comment 3: > Alpha values are slightly different because the amount of padding depends on the symbol size. We have more padding when we use symbol size=32 as compared to symbol size=16. So if we want to reach the same total bit-rate target, we can afford a greater alpha when symbol size=16. [Thomas] *** Still not getting it. Which padding are you referring to? In FEC framework the packets are sent unmodified (in case RTP is used) and your repair packets all have the same size. So where would the extra overhead come from? The padding in the source block to create the source symbols is never "transmitted". > As for the simulation results they are not far away so that it is difficult to derive definitive conclusions. If we compare 20x16 to 10x32 or 10x16 to 5x32, then the winner depends on which table we look at: PLR=0.1 or PLR=0.2. > What you were expecting seems to be what we got with PLR=0.2. [Thomas] *** Again see above, I do not understand the logic. You are sending the same amount if repair packets, all of the same size, and you are also sending the same source packets and you are using MDS codes, so why would there be any difference? Thomas > > I hope it answers you first comments. > > Best regards. > > Pierre > > -----Message d'origine----- > De : Thomas Stockhammer [mailto:stockhammer@nomor.de] > Envoyé : Tuesday, February 09, 2010 1:10 PM > À : ROUX Pierre > Cc : fecframe@ietf.org > Objet : Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt > > Pierre, > > I quickly scanned through this draft. Some very initial comments: > > Comment 1: > ========= > You strategy (c) > (c) Have small repair symbols but put many repair symbols per repair > packet. > and your pitfall: > (c) will have poor performances because the loss of a single repair > packet will translate into a large number of repair symbol being > lost. > > I do not understand why this would results in poor performance. This works very well is applied in the MBMS streaming framework. > Despite you loose more symbols, you also get more symbols from correct packets. So it works very well, but you need a long code such as Raptor or RaptorQ. > > Comment 2: > ========== > I disagree with the approach to modify source packets the way you propose. This has significant backward-compatibility issues and had been discussed in AVT for some time. However, there are nice ways to achieve what you propose in a very simple manner. For example, RFC3984 permits the use of fragmentation units and you can fragment entire slice into fragments that exactly fit the purpose you want. the major advantage is that this is backward-compatible and it is part of the payload format. Creating a new layer for the purpose of generic fragmentation seems to create many problems. > > Comment 3: > ========= > What is strange about your results is that the performance of symbol size 16 with 20 symbols per packet performs worse than symbol size 32 with 10 symbols per packet. The same with 5x32 and 10x16. > It is also not clear why the alpha values are different for these configurations. Can you explain? > > Best regards > > Thomas > > > On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: > >> Dear all, >> I have recently submitted the following Internet-Draft: >> >> Title : Benefits of re-packetization for FEC based protection >> of multimedia streams >> Author(s) : P. Roux, C. Janneteau, K. Mounir >> Filename : draft-roux-fecframe-repacketization-00.txt >> Pages : 12 >> Date : 2010-2-9 >> >> URL: >> http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >> 00.txt >> >> This is an informational draft that presents the advantages of >> re-packetizing multimedia streams to be FEC protected, for better >> performance. >> >> Any kind of feedback about this Internet-Draft will be very welcomed. >> >> Best regards, >> >> Pierre >> _______________________________________________ >> 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 > Nomor Research GmbH - Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering. > > MWC 2010: Visit Nomor Research at booth 2F33 > --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 Nomor Research GmbH - Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering. MWC 2010: Visit Nomor Research at booth 2F33 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From pierre.roux@cea.fr Wed Feb 10 01:35:15 2010 Return-Path: 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 570713A6C92 for ; Wed, 10 Feb 2010 01:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4Tjy7+TPRFjq for ; Wed, 10 Feb 2010 01:35:14 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id B0B713A6B67 for ; Wed, 10 Feb 2010 01:35:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1A9aLK9028523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 10:36:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1A9aL2I019761; Wed, 10 Feb 2010 10:36:21 +0100 (envelope-from pierre.roux@cea.fr) Received: from mansart.intra.cea.fr (mansart.intra.cea.fr [132.166.88.54]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1A9aLsS005792; Wed, 10 Feb 2010 10:36:21 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.44]) by mansart.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 10:36:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 10:36:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt Thread-Index: Acqpoa8es7P/3e1QRwChtq9GqR8pmwAAnvYw References: From: "ROUX Pierre" To: X-OriginalArrivalTime: 10 Feb 2010 09:36:21.0266 (UTC) FILETIME=[80FE6F20:01CAAA34] Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:35:15 -0000 Hello Thomas,=20 I was afraid about a possible lack of feedback, but I have not such fear = anymore. Let us try to solve misunderstandings. Please find answers inline (after (Pierre]). Best regards. Pierre -----Message d'origine----- De=A0: Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 Envoy=E9=A0: Tuesday, February 09, 2010 5:05 PM =C0=A0: ROUX Pierre Cc=A0: fecframe@ietf.org Objet=A0: Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt Pierre, inline [Thomas] *** > With respect to comment 1, I agree about your statement ("you get more = symbols form correct packets"). I also agree that this strategy can be = efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. [Thomas] ***I am sorry, I miss the logic. If the source block size stays the = same, but you only change the dimensions, this does not change the = delay. You add the same amount of source packets in either case. This is = independent of the bitrate and delay tolerance. [Pierre] What is compared is large FEC block on one side and medium FEC block on = the other side. The relation with bit-rate and delay tolerance is that when you have a = low bit-rate and delay constraints, it is not possible to have large FEC = block. As an example in the simulation, the average source bit-rate was = around 120 kbit/s, and the FEC block periodicity was set equal 500 ms = (to avoid excessive latency increase), so the average source block size = in bytes was around 7 or 8 kbytes. > With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 > Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 [Thomas] ***I still do not understand the use case, but if the use case is really = relevant (which I still need to be convinced) then you may use the FEC = Framework as is and only send repair packets. Then you can have packets = of the exact symbol size. So I do not see the necessity of a new layer = as backward-comptibility is anyways broken with this new layer. [Pierre] I am not sure if I understand your point. What is proposed is to use the = FEC Framework as is. The re-packetization/restoration process is outside = of the FEC Framework. > With respect to comment 3: > Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. [Thomas] *** Still not getting it. Which padding are you referring to? In FEC = framework the packets are sent unmodified (in case RTP is used) and your = repair packets all have the same size. So where would the extra overhead = come from? The padding in the source block to create the source symbols = is never "transmitted". [Pierre] Let me try to clarify with a numerical example. We have a block made of 4 source packets, with respective payload sizes = equal to 447, 242, 741, 841 bytes. Those packets are sent unmodified as source packets, as you have pointed = out. We also want to build repair packets on the basis of a symbol size equal = either to 50 bytes or to 100 bytes. If the size is 50 bytes we will put = 10 symbols per repair packet (default), and if the size is 100 bytes we = will put only 5 symbols per repair packet (default). If the symbol size is equal to 50 bytes we build 9,5,15,17 source = symbols out of each respective source packet. The total is 46 source = symbols for the block. If the symbol size is equal to 100 bytes we build 5,3,8,9 source symbols = out of each respective source packet. The total is 25 source symbols for = the block. Then is we assume the same alpha value equal to 1 in each case, we will = derive as many repair symbols as there are source symbols. We will get 5 = repair packets in each case, but when the symbol size is 50, the last = repair packet will be filled with 6 symbols instead of 10. So the repair bit-rate will be lower if the symbol size if 50. Because we want that all configurations are compared with the same total = bit-rate (that includes the repair bit-rate) we would assign a higher = alpha value in case of symbol size equal to 50, as compared to symbol = size equal to 100. > As for the simulation results they are not far away so that it is = difficult to derive definitive conclusions. If we compare 20x16 to 10x32 = or 10x16 to 5x32, then the winner depends on which table we look at: = PLR=3D0.1 or PLR=3D0.2.=20 > What you were expecting seems to be what we got with PLR=3D0.2. [Thomas] *** Again see above, I do not understand the logic. You are sending the = same amount if repair packets, all of the same size, and you are also = sending the same source packets and you are using MDS codes, so why = would there be any difference? [Pierre] See above. Thomas >=20 > I hope it answers you first comments. >=20 > Best regards. >=20 > Pierre >=20 > -----Message d'origine----- > De : Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 > Envoy=E9 : Tuesday, February 09, 2010 1:10 PM > =C0 : ROUX Pierre > Cc : fecframe@ietf.org > Objet : Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt >=20 > Pierre, >=20 > I quickly scanned through this draft. Some very initial comments: >=20 > Comment 1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > You strategy (c)=20 > (c) Have small repair symbols but put many repair symbols per repair=20 > packet.=20 > and your pitfall: > (c) will have poor performances because the loss of a single repair=20 > packet will translate into a large number of repair symbol being=20 > lost.=20 >=20 > I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. > Despite you loose more symbols, you also get more symbols from correct = packets. So it works very well, but you need a long code such as Raptor = or RaptorQ. >=20 > Comment 2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. >=20 > Comment 3: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. > It is also not clear why the alpha values are different for these = configurations. Can you explain? >=20 > Best regards >=20 > Thomas >=20 >=20 > On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: >=20 >> Dear all, >> I have recently submitted the following Internet-Draft: >>=20 >> Title : Benefits of re-packetization for FEC based protection >> of multimedia streams >> Author(s) : P. Roux, C. Janneteau, K. Mounir >> Filename : draft-roux-fecframe-repacketization-00.txt >> Pages : 12 >> Date : 2010-2-9 >>=20 >> URL:=20 >> = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >> 00.txt >>=20 >> This is an informational draft that presents the advantages of >> re-packetizing multimedia streams to be FEC protected, for better >> performance. >>=20 >> Any kind of feedback about this Internet-Draft will be very welcomed. >>=20 >> Best regards, >>=20 >> Pierre >> _______________________________________________ >> 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 > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 > MWC 2010: Visit Nomor Research at booth 2F33 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. MWC 2010: Visit Nomor Research at booth 2F33 From stockhammer@nomor.de Wed Feb 10 02:34:18 2010 Return-Path: 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 20D9328C0F6 for ; Wed, 10 Feb 2010 02:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 5-f1jeGON+0P for ; Wed, 10 Feb 2010 02:34:16 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 38EF43A76A7 for ; Wed, 10 Feb 2010 02:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1265798123; l=10373; s=domk; d=nomor.de; h=To:Date:Subject:From:Cc:Content-Transfer-Encoding:Content-Type: Mime-Version:In-Reply-To:References:X-RZG-CLASS-ID:X-RZG-AUTH; bh=bRn7/5JYnXttwpPQF9JUhntQuAc=; b=hDn0V40iyOrMGdlzR1hgkml0r3l9xhve7hqBDuJKZyBvmULb7s2pRP57Lc/LamA0Y8j NElOQrOtB2W5YXLjhFrHgd5zNmtOs+zfdYB7GOisZEdCXsQTN0etr8YmnEVs4NeO6SMHW C0NNgU6z9xnAlaPYnab/O/wVUxU0pJxTXqM= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFk7RnvKC67oOfpzXah2UgRw9hgiX9BbGWsas= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.149] (dialbs-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (mrclete mo9) (RZmta 22.6) with ESMTP id m0637bm1AAIj3J ; Wed, 10 Feb 2010 11:35:12 +0100 (MET) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 Message-Id: <5C932EE4-0E2E-49EF-B055-BF02F0CBE71B@nomor.de> Content-Transfer-Encoding: quoted-printable From: Thomas Stockhammer Date: Wed, 10 Feb 2010 11:35:08 +0100 To: ROUX Pierre X-Mailer: Apple Mail (2.1077) Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:34:18 -0000 Pierre, >> With respect to comment 1, I agree about your statement ("you get = more symbols form correct packets"). I also agree that this strategy can = be efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. >=20 > [Thomas] > ***I am sorry, I miss the logic. If the source block size stays the = same, but you only change the dimensions, this does not change the = delay. You add the same amount of source packets in either case. This is = independent of the bitrate and delay tolerance. > [Pierre] > What is compared is large FEC block on one side and medium FEC block = on the other side. > The relation with bit-rate and delay tolerance is that when you have a = low bit-rate and delay constraints, it is not possible to have large FEC = block. As an example in the simulation, the average source bit-rate was = around 120 kbit/s, and the FEC block periodicity was set equal 500 ms = (to avoid excessive latency increase), so the average source block size = in bytes was around 7 or 8 kbytes. [Thomas] *** I understand what you say, but again, if the you have small symbols, = e.g. 16 and large source blocks size, e.g. 1024, or large symbols, e.g. = 1024, and small source block size, e.g. 16. There is no difference in = terms of delay. So I do not see the point. >=20 >> With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 >> Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 >=20 > [Thomas] > ***I still do not understand the use case, but if the use case is = really relevant (which I still need to be convinced) then you may use = the FEC Framework as is and only send repair packets. Then you can have = packets of the exact symbol size. So I do not see the necessity of a new = layer as backward-comptibility is anyways broken with this new layer. > [Pierre] > I am not sure if I understand your point. What is proposed is to use = the FEC Framework as is. The re-packetization/restoration process is = outside of the FEC Framework. [Thomas] *** Yes, I understand. But you do not need to have it outside. You can = do it with FECFRAME by just not sending the original data. Just send = more repair symbols and repair symbols only. >=20 >> With respect to comment 3: >> Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. >=20 > [Thomas] > *** Still not getting it. Which padding are you referring to? In FEC = framework the packets are sent unmodified (in case RTP is used) and your = repair packets all have the same size. So where would the extra overhead = come from? The padding in the source block to create the source symbols = is never "transmitted". > [Pierre] > Let me try to clarify with a numerical example. > We have a block made of 4 source packets, with respective payload = sizes equal to 447, 242, 741, 841 bytes. > Those packets are sent unmodified as source packets, as you have = pointed out. > We also want to build repair packets on the basis of a symbol size = equal either to 50 bytes or to 100 bytes. If the size is 50 bytes we = will put 10 symbols per repair packet (default), and if the size is 100 = bytes we will put only 5 symbols per repair packet (default). > If the symbol size is equal to 50 bytes we build 9,5,15,17 source = symbols out of each respective source packet. The total is 46 source = symbols for the block. > If the symbol size is equal to 100 bytes we build 5,3,8,9 source = symbols out of each respective source packet. The total is 25 source = symbols for the block. > Then is we assume the same alpha value equal to 1 in each case, we = will derive as many repair symbols as there are source symbols. We will = get 5 repair packets in each case, but when the symbol size is 50, the = last repair packet will be filled with 6 symbols instead of 10. > So the repair bit-rate will be lower if the symbol size if 50. > Because we want that all configurations are compared with the same = total bit-rate (that includes the repair bit-rate) we would assign a = higher alpha value in case of symbol size equal to 50, as compared to = symbol size equal to 100. [Thomas] *** OK, maybe we are getting closer. So now you have how many packets? - 4 source packets of size 447, 242, 741 and 841 - 5 repair packets, each of size 500 bytes So I have=20 for 50 byte symbols:=20 - source symbols: 9, 5, 15, 17=20 - sum is 46 source symbols - each repair packet has 10 symbols for 100 byte symbols:=20 - source symbols: 5, 3, 8, 9 - sum is 25 source symbols - each repair packet has 5 symbols - I need one of the following (at least) - all 5 repair packets,=20 - 4 repair + packet (1) or packet (3) or packet (4), - 3 repair + packet (1+ 3) or packet (1 + 4) or packet = (2 + 3) or packet (2 + 4) or packet (3 + 4) - 2 repair + packet (1 + 2 + 3) or packet (1 + 2 + 4) = or packet (3 + 4) - 1 repair + packet (1 + 3 + 4) or packet (2 + 3 + 4)=20= - If I check then for all these cases I can also recover for 50 = byte symbols In any case I need at least the amount of source symbols at the = receiver. So I am always doing at least as good or better if use 50 byte = symbols instead of 100 byte symbols. So there is a small difference expected when you use smaller source = symbols, but it is always in favour of the smaller symbols. So I do not = understand your results why the smaller symbols size perform worse. Thomas > Thomas >=20 >>=20 >> I hope it answers you first comments. >>=20 >> Best regards. >>=20 >> Pierre >>=20 >> -----Message d'origine----- >> De : Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 >> Envoy=E9 : Tuesday, February 09, 2010 1:10 PM >> =C0 : ROUX Pierre >> Cc : fecframe@ietf.org >> Objet : Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt >>=20 >> Pierre, >>=20 >> I quickly scanned through this draft. Some very initial comments: >>=20 >> Comment 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> You strategy (c)=20 >> (c) Have small repair symbols but put many repair symbols per repair=20= >> packet.=20 >> and your pitfall: >> (c) will have poor performances because the loss of a single repair=20= >> packet will translate into a large number of repair symbol being=20 >> lost.=20 >>=20 >> I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. >> Despite you loose more symbols, you also get more symbols from = correct packets. So it works very well, but you need a long code such as = Raptor or RaptorQ. >>=20 >> Comment 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. >>=20 >> Comment 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. >> It is also not clear why the alpha values are different for these = configurations. Can you explain? >>=20 >> Best regards >>=20 >> Thomas >>=20 >>=20 >> On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: >>=20 >>> Dear all, >>> I have recently submitted the following Internet-Draft: >>>=20 >>> Title : Benefits of re-packetization for FEC based = protection >>> of multimedia streams >>> Author(s) : P. Roux, C. Janneteau, K. Mounir >>> Filename : draft-roux-fecframe-repacketization-00.txt >>> Pages : 12 >>> Date : 2010-2-9 >>>=20 >>> URL:=20 >>> = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >>> 00.txt >>>=20 >>> This is an informational draft that presents the advantages of >>> re-packetizing multimedia streams to be FEC protected, for better >>> performance. >>>=20 >>> Any kind of feedback about this Internet-Draft will be very = welcomed. >>>=20 >>> Best regards, >>>=20 >>> Pierre >>> _______________________________________________ >>> 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 >> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >>=20 >> MWC 2010: Visit Nomor Research at booth 2F33 >>=20 >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 > MWC 2010: Visit Nomor Research at booth 2F33 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 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. MWC 2010: Visit Nomor Research at booth 2F33 From pierre.roux@cea.fr Wed Feb 10 05:53:35 2010 Return-Path: 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 208713A7043 for ; Wed, 10 Feb 2010 05:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 chWWsYWKjhze for ; Wed, 10 Feb 2010 05:53:34 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 8741A3A6D3C for ; Wed, 10 Feb 2010 05:53:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1ADsfcl015500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 14:54:41 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1ADsf9u022245; Wed, 10 Feb 2010 14:54:41 +0100 (envelope-from pierre.roux@cea.fr) Received: from levau.intra.cea.fr (levau.intra.cea.fr [132.166.88.52]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1ADsfiV028524; Wed, 10 Feb 2010 14:54:41 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.47]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 14:54:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 10 Feb 2010 14:54:39 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt Thread-Index: Acqpoa/G/rlRHXZ1S+6CO575IeBsYAAjokUwAAmwfPA= References: From: "ROUX Pierre" To: "Einat Yellin (Lachover)" X-OriginalArrivalTime: 10 Feb 2010 13:54:41.0132 (UTC) FILETIME=[97A24AC0:01CAAA58] Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:53:35 -0000 Thanks, Einat. We take note of your remarks for possible study complements. Best regards. Pierre -----Message d'origine----- De=A0: Einat Yellin (Lachover) [mailto:Einat@radvision.com]=20 Envoy=E9=A0: Wednesday, February 10, 2010 10:30 AM =C0=A0: Thomas Stockhammer; ROUX Pierre Cc=A0: fecframe@ietf.org Objet=A0: RE: [Fecframe] New draft = submitted:draft-roux-fecframe-repacketization-00.txt Hi, Adding to the discussion. In general the ideal behind leveling the unit sizes in FEC is good, but = I believe that with the suggested draft it could fail in practice. On top of the backward compatibility "small" issue, there is also a = computational drawback in implementing this. If I understand correctly both sender and receiver would be required to = rearrange RTP packets, which means recopying the bytes and producing new = RTP headers. Other comments that I would like to make are about different assumptions = in the Appendix: A. Block periodicity of 500ms is way to high if you target low-latency = applications. It means that in some cases the receiver would have to = wait 500 ms before packet restore can be done. B. FEC bit rate that equals source bit rate seems to be unrealistic = IMHO. If, as you suggested, you target low bitrate video you will get = better quality by using more bitrate for the video itself and use only a = fraction of the bit rate for FEC, especially in the common cases of up = to 5% packet loss - see C. C. Packet loss rates - I think that you should experiment with lower and = more typical packet losses in the range of 1-5% as well.=20 Regards, Einat -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Thomas Stockhammer Sent: Tuesday, February 09, 2010 6:05 PM To: ROUX Pierre Cc: fecframe@ietf.org Subject: Re: [Fecframe] New draft = submitted:draft-roux-fecframe-repacketization-00.txt Pierre, inline [Thomas] *** > With respect to comment 1, I agree about your statement ("you get more = symbols form correct packets"). I also agree that this strategy can be = efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. [Thomas] ***I am sorry, I miss the logic. If the source block size stays the = same, but you only change the dimensions, this does not change the = delay. You add the same amount of source packets in either case. This is = independent of the bitrate and delay tolerance. > With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 > Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 [Thomas] ***I still do not understand the use case, but if the use case is really = relevant (which I still need to be convinced) then you may use the FEC = Framework as is and only send repair packets. Then you can have packets = of the exact symbol size. So I do not see the necessity of a new layer = as backward-comptibility is anyways broken with this new layer. > With respect to comment 3: > Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. [Thomas] *** Still not getting it. Which padding are you referring to? In FEC = framework the packets are sent unmodified (in case RTP is used) and your = repair packets all have the same size. So where would the extra overhead = come from? The padding in the source block to create the source symbols = is never "transmitted". > As for the simulation results they are not far away so that it is = difficult to derive definitive conclusions. If we compare 20x16 to 10x32 = or 10x16 to 5x32, then the winner depends on which table we look at: = PLR=3D0.1 or PLR=3D0.2.=20 > What you were expecting seems to be what we got with PLR=3D0.2. [Thomas] *** Again see above, I do not understand the logic. You are sending the = same amount if repair packets, all of the same size, and you are also = sending the same source packets and you are using MDS codes, so why = would there be any difference? Thomas >=20 > I hope it answers you first comments. >=20 > Best regards. >=20 > Pierre >=20 > -----Message d'origine----- > De : Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 > Envoy=E9 : Tuesday, February 09, 2010 1:10 PM > =C0 : ROUX Pierre > Cc : fecframe@ietf.org > Objet : Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt >=20 > Pierre, >=20 > I quickly scanned through this draft. Some very initial comments: >=20 > Comment 1: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > You strategy (c)=20 > (c) Have small repair symbols but put many repair symbols per repair=20 > packet.=20 > and your pitfall: > (c) will have poor performances because the loss of a single repair=20 > packet will translate into a large number of repair symbol being=20 > lost.=20 >=20 > I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. > Despite you loose more symbols, you also get more symbols from correct = packets. So it works very well, but you need a long code such as Raptor = or RaptorQ. >=20 > Comment 2: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. >=20 > Comment 3: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. > It is also not clear why the alpha values are different for these = configurations. Can you explain? >=20 > Best regards >=20 > Thomas >=20 >=20 > On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: >=20 >> Dear all, >> I have recently submitted the following Internet-Draft: >>=20 >> Title : Benefits of re-packetization for FEC based protection >> of multimedia streams >> Author(s) : P. Roux, C. Janneteau, K. Mounir >> Filename : draft-roux-fecframe-repacketization-00.txt >> Pages : 12 >> Date : 2010-2-9 >>=20 >> URL:=20 >> = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >> 00.txt >>=20 >> This is an informational draft that presents the advantages of >> re-packetizing multimedia streams to be FEC protected, for better >> performance. >>=20 >> Any kind of feedback about this Internet-Draft will be very welcomed. >>=20 >> Best regards, >>=20 >> Pierre >> _______________________________________________ >> 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 > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 > MWC 2010: Visit Nomor Research at booth 2F33 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. MWC 2010: Visit Nomor Research at booth 2F33 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From pierre.roux@cea.fr Wed Feb 10 06:41:14 2010 Return-Path: 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 748EA28C1D3 for ; Wed, 10 Feb 2010 06:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 WpczmqwK5CYv for ; Wed, 10 Feb 2010 06:41:13 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7FBDC28C1C0 for ; Wed, 10 Feb 2010 06:41:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1AEgLoP007511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 15:42:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1AEgLmR014484; Wed, 10 Feb 2010 15:42:21 +0100 (envelope-from pierre.roux@cea.fr) Received: from levau.intra.cea.fr (levau.intra.cea.fr [132.166.88.52]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1AEgL5M014306; Wed, 10 Feb 2010 15:42:21 +0100 Received: from LODERI.intra.cea.fr ([132.166.64.47]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 15:42:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 15:42:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt Thread-Index: AcqqPMgyU+FgBYQNSJmbU5sxlqxzZQAG9l+QAAGerCA= From: "ROUX Pierre" To: "Thomas Stockhammer" X-OriginalArrivalTime: 10 Feb 2010 14:42:21.0374 (UTC) FILETIME=[407895E0:01CAAA5F] Cc: fecframe@ietf.org Subject: [Fecframe] TR: New draft submitted: draft-roux-fecframe-repacketization-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 14:41:14 -0000 Thanks, Thomas. I understand that you don't question anymore the use of different alpha = values for, e.g. 20x16 versus 10x32. And you come back to your original remark saying that 20x16 should = perform better than 10x32 (e.g.). Now I understand your point, and you are right. There is nothing wrong = with small symbols indeed, even in the context of short FEC blocks. This is confirmed if we observe the results in figure 5 in the draft. = Those related to PLR=3D0.2. For figure 4 with PLR =3D 0.1 we have weird results in this respect, = that are related to the small difference that we want to evaluate, = together with simulation times that should have been longer for this = PLR. The paragraph about the third pitfall mentioned in the draft (small = symbols and many of them per repair packet) makes no sense and should be = deleted.=20 However, this doesn't affect the main purpose of the draft that consists = in showing the benefits of re-packetization in terms of performance. With respect to this comment: >You can do it with FECFRAME by just not sending the original data. Just = >send more repair symbols and repair symbols only. When re-packetization is used, we assume only one symbol per source = packet, and we have this property that if one source packet is lost, = only one source symbol is lost. This property brings good performances. = If we don't re-packetize the source packets that are sent, then this = property is lost. Best regards. Pierre -----Message d'origine----- De=A0: Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 Envoy=E9=A0: Wednesday, February 10, 2010 11:35 AM =C0=A0: ROUX Pierre Cc=A0: fecframe@ietf.org Objet=A0: Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt Pierre, >> With respect to comment 1, I agree about your statement ("you get = more symbols form correct packets"). I also agree that this strategy can = be efficient with long codes. The context that we were interested in in = this draft is when we can't afford long codes (low bitrates and no = tolerance about latency). Then this strategy (short symbols and many = symbols per repair packet) is probably not the best one. >=20 > [Thomas] > ***I am sorry, I miss the logic. If the source block size stays the = same, but you only change the dimensions, this does not change the = delay. You add the same amount of source packets in either case. This is = independent of the bitrate and delay tolerance. > [Pierre] > What is compared is large FEC block on one side and medium FEC block = on the other side. > The relation with bit-rate and delay tolerance is that when you have a = low bit-rate and delay constraints, it is not possible to have large FEC = block. As an example in the simulation, the average source bit-rate was = around 120 kbit/s, and the FEC block periodicity was set equal 500 ms = (to avoid excessive latency increase), so the average source block size = in bytes was around 7 or 8 kbytes. [Thomas] *** I understand what you say, but again, if the you have small symbols, = e.g. 16 and large source blocks size, e.g. 1024, or large symbols, e.g. = 1024, and small source block size, e.g. 16. There is no difference in = terms of delay. So I do not see the point. >=20 >> With respect to comment 2: OK for the lack of backward compatibility. = This drawback is pointed out in the draft.=20 >> Exploiting RFC3984 is also a worthy suggestion. The advantage of the = "new layer" is that it is applicable to any media stream.=20 >=20 > [Thomas] > ***I still do not understand the use case, but if the use case is = really relevant (which I still need to be convinced) then you may use = the FEC Framework as is and only send repair packets. Then you can have = packets of the exact symbol size. So I do not see the necessity of a new = layer as backward-comptibility is anyways broken with this new layer. > [Pierre] > I am not sure if I understand your point. What is proposed is to use = the FEC Framework as is. The re-packetization/restoration process is = outside of the FEC Framework. [Thomas] *** Yes, I understand. But you do not need to have it outside. You can = do it with FECFRAME by just not sending the original data. Just send = more repair symbols and repair symbols only. >=20 >> With respect to comment 3: >> Alpha values are slightly different because the amount of padding = depends on the symbol size. We have more padding when we use symbol = size=3D32 as compared to symbol size=3D16. So if we want to reach the = same total bit-rate target, we can afford a greater alpha when symbol = size=3D16. >=20 > [Thomas] > *** Still not getting it. Which padding are you referring to? In FEC = framework the packets are sent unmodified (in case RTP is used) and your = repair packets all have the same size. So where would the extra overhead = come from? The padding in the source block to create the source symbols = is never "transmitted". > [Pierre] > Let me try to clarify with a numerical example. > We have a block made of 4 source packets, with respective payload = sizes equal to 447, 242, 741, 841 bytes. > Those packets are sent unmodified as source packets, as you have = pointed out. > We also want to build repair packets on the basis of a symbol size = equal either to 50 bytes or to 100 bytes. If the size is 50 bytes we = will put 10 symbols per repair packet (default), and if the size is 100 = bytes we will put only 5 symbols per repair packet (default). > If the symbol size is equal to 50 bytes we build 9,5,15,17 source = symbols out of each respective source packet. The total is 46 source = symbols for the block. > If the symbol size is equal to 100 bytes we build 5,3,8,9 source = symbols out of each respective source packet. The total is 25 source = symbols for the block. > Then is we assume the same alpha value equal to 1 in each case, we = will derive as many repair symbols as there are source symbols. We will = get 5 repair packets in each case, but when the symbol size is 50, the = last repair packet will be filled with 6 symbols instead of 10. > So the repair bit-rate will be lower if the symbol size if 50. > Because we want that all configurations are compared with the same = total bit-rate (that includes the repair bit-rate) we would assign a = higher alpha value in case of symbol size equal to 50, as compared to = symbol size equal to 100. [Thomas] *** OK, maybe we are getting closer. So now you have how many packets? - 4 source packets of size 447, 242, 741 and 841 - 5 repair packets, each of size 500 bytes So I have=20 for 50 byte symbols:=20 - source symbols: 9, 5, 15, 17=20 - sum is 46 source symbols - each repair packet has 10 symbols for 100 byte symbols:=20 - source symbols: 5, 3, 8, 9 - sum is 25 source symbols - each repair packet has 5 symbols - I need one of the following (at least) - all 5 repair packets,=20 - 4 repair + packet (1) or packet (3) or packet (4), - 3 repair + packet (1+ 3) or packet (1 + 4) or packet (2 + 3) or = packet (2 + 4) or packet (3 + 4) - 2 repair + packet (1 + 2 + 3) or packet (1 + 2 + 4) or packet (3 + = 4) - 1 repair + packet (1 + 3 + 4) or packet (2 + 3 + 4)=20 - If I check then for all these cases I can also recover for 50 byte = symbols In any case I need at least the amount of source symbols at the = receiver. So I am always doing at least as good or better if use 50 byte = symbols instead of 100 byte symbols. So there is a small difference expected when you use smaller source = symbols, but it is always in favour of the smaller symbols. So I do not = understand your results why the smaller symbols size perform worse. Thomas > Thomas >=20 >>=20 >> I hope it answers you first comments. >>=20 >> Best regards. >>=20 >> Pierre >>=20 >> -----Message d'origine----- >> De : Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 >> Envoy=E9 : Tuesday, February 09, 2010 1:10 PM >> =C0 : ROUX Pierre >> Cc : fecframe@ietf.org >> Objet : Re: [Fecframe] New draft submitted: = draft-roux-fecframe-repacketization-00.txt >>=20 >> Pierre, >>=20 >> I quickly scanned through this draft. Some very initial comments: >>=20 >> Comment 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> You strategy (c)=20 >> (c) Have small repair symbols but put many repair symbols per repair=20 >> packet.=20 >> and your pitfall: >> (c) will have poor performances because the loss of a single repair=20 >> packet will translate into a large number of repair symbol being=20 >> lost.=20 >>=20 >> I do not understand why this would results in poor performance. This = works very well is applied in the MBMS streaming framework. >> Despite you loose more symbols, you also get more symbols from = correct packets. So it works very well, but you need a long code such as = Raptor or RaptorQ. >>=20 >> Comment 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I disagree with the approach to modify source packets the way you = propose. This has significant backward-compatibility issues and had been = discussed in AVT for some time. However, there are nice ways to achieve = what you propose in a very simple manner. For example, RFC3984 permits = the use of fragmentation units and you can fragment entire slice into = fragments that exactly fit the purpose you want. the major advantage is = that this is backward-compatible and it is part of the payload format. = Creating a new layer for the purpose of generic fragmentation seems to = create many problems. >>=20 >> Comment 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> What is strange about your results is that the performance of symbol = size 16 with 20 symbols per packet performs worse than symbol size 32 = with 10 symbols per packet. The same with 5x32 and 10x16. >> It is also not clear why the alpha values are different for these = configurations. Can you explain? >>=20 >> Best regards >>=20 >> Thomas >>=20 >>=20 >> On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote: >>=20 >>> Dear all, >>> I have recently submitted the following Internet-Draft: >>>=20 >>> Title : Benefits of re-packetization for FEC based protection >>> of multimedia streams >>> Author(s) : P. Roux, C. Janneteau, K. Mounir >>> Filename : draft-roux-fecframe-repacketization-00.txt >>> Pages : 12 >>> Date : 2010-2-9 >>>=20 >>> URL:=20 >>> = http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization- >>> 00.txt >>>=20 >>> This is an informational draft that presents the advantages of >>> re-packetizing multimedia streams to be FEC protected, for better >>> performance. >>>=20 >>> Any kind of feedback about this Internet-Draft will be very = welcomed. >>>=20 >>> Best regards, >>>=20 >>> Pierre >>> _______________________________________________ >>> 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 >> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >>=20 >> MWC 2010: Visit Nomor Research at booth 2F33 >>=20 >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 > MWC 2010: Visit Nomor Research at booth 2F33 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. MWC 2010: Visit Nomor Research at booth 2F33 From abegen@cisco.com Thu Feb 11 14:48:36 2010 Return-Path: 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 0065828C247; Thu, 11 Feb 2010 14:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 ohULLoA5n35c; Thu, 11 Feb 2010 14:48:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C638D28C165; Thu, 11 Feb 2010 14:48:34 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPkXdEurR7Ht/2dsb2JhbACbAHSoGpd3hFYEgxM X-IronPort-AV: E=Sophos;i="4.49,455,1262563200"; d="scan'208";a="481877186" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Feb 2010 22:49:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1BMno14009766; Thu, 11 Feb 2010 22:49:50 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.3959); Thu, 11 Feb 2010 14:49:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2010 14:50:10 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B417641@xmb-sjc-215.amer.cisco.com> In-Reply-To: <82F55EE7-98DC-454D-966E-F96D77F3B1EB@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05) Thread-Index: AcqrWb/2mHyX0s62RYeT4XE9ipacNgAEsEjw References: <27887E65-F19F-405C-B1ED-E04FB41452C5@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540B23D7FE@xmb-sjc-215.amer.cisco.com> <846E11BB-CAB7-43DD-A532-246926CBEA9B@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540B23D8C5@xmb-sjc-215.amer.cisco.com> <4B621DCA.6050506@digium.com> <04CAD96D4C5A3D48B1919248A8FE0D540B2CB176@xmb-sjc-215.amer.cisco.com> <82F55EE7-98DC-454D-966E-F96D77F3B1EB@nostrum.com> From: "Ali C. Begen (abegen)" To: "Robert Sparks" X-OriginalArrivalTime: 11 Feb 2010 22:49:50.0890 (UTC) FILETIME=[84F448A0:01CAAB6C] Cc: mmusic@ietf.org, fecframe@ietf.org, "Kevin P. Fleming" Subject: Re: [Fecframe] [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 22:48:36 -0000 Here is the new version. http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-06.txt=20 Cheers, acbegen. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Thursday, February 11, 2010 3:35 PM > To: Ali C. Begen (abegen) > Cc: Kevin P. Fleming; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05) >=20 > Hi Ali - >=20 > Please submit the revised document. >=20 > RjS >=20 > On Feb 2, 2010, at 10:25 AM, Ali C. Begen (abegen) wrote: >=20 > > OK, I talked to Robert and I propose to change the draft from > > obsoleting > > 4756 to updating it (there is no "deprecated" keyword for the drafts). > > > > There will be a note in section 3.1: > > > > This document introduces the changes required in the FEC grouping > > semantics and updates [RFC4756]. New implementations SHOULD use the > > new semantics introduced in this document whenever possible, but > > they > > may need to use [RFC4756] semantics when backward compatibility is > > desired, as described in Section 4.4. > > > > Before we go ahead with the revision, please let me know if you are > > not > > OK with this change. If there are no objections, we will move forward > > with this change. > > > > Thanks, > > -acbegen > > > > > >> -----Original Message----- > >> From: Kevin P. Fleming [mailto:kpfleming@digium.com] > >> Sent: Thursday, January 28, 2010 6:29 PM > >> To: Ali C. Begen (abegen) > >> Cc: Robert Sparks; mmusic@ietf.org; fecframe@ietf.org > >> Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD > >> Review:draft-ietf-mmusic-rfc4765bis-05) > >> > >> Ali C. Begen (abegen) wrote: > >> > >>> OK, right. "FEC" semantics are not defined in the new draft. If a > > new > >>> implementation wants to be able to speak to 4756 endpoints, it will > > need > >>> 4756. Then I guess you are disagreeing that we are obsoleting 4756. > >>> > >>> Well, I am not sure what is the right term here. At that time, I was > >>> told "obsoleting" was the right choice. To me, RFC 4756 will still > > be > >>> available for anybody who wants to be backward compatible anyway. > > So, I > >>> did not think it would be a problem. But, if you say it is a > > problem, I > >>> can't argue with that. > >> > >> The correct word, in English at least, is 'deprecated'. The previous > >> version is still valid, but is not recommended for new > > implementations. > >> > >> -- > >> Kevin P. Fleming > >> Digium, Inc. | Director of Software Technologies > >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > >> skype: kpfleming | jabber: kpfleming@digium.com > >> Check us out at www.digium.com & www.asterisk.org From root@core3.amsl.com Wed Feb 24 17:00:02 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 53CCC28C295; Wed, 24 Feb 2010 17:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100225010002.53CCC28C295@core3.amsl.com> Date: Wed, 24 Feb 2010 17:00:02 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-config-signaling-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 01:00:02 -0000 --NextPart 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 : Methods to convey FEC Framework Configuration Information Author(s) : R. Asati Filename : draft-ietf-fecframe-config-signaling-02.txt Pages : 17 Date : 2010-02-24 FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-config-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24164913.I-D@ietf.org> --NextPart--