From fecframe-bounces@ietf.org Tue Nov 01 14:45:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX24C-0008PZ-LD; Tue, 01 Nov 2005 14:45:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX24B-0008PJ-0v for fecframe@megatron.ietf.org; Tue, 01 Nov 2005 14:45:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10360 for ; Tue, 1 Nov 2005 14:44:47 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX2Ib-0000ZB-7T for fecframe@ietf.org; Tue, 01 Nov 2005 15:00:02 -0500 Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1EX23y-0004iS-00 for fecframe@ietf.org; Tue, 01 Nov 2005 20:44:54 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1EX23y-0004ZM-00 for fecframe@ietf.org; Tue, 01 Nov 2005 20:44:54 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 20:44:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Nov 2005 14:44:58 -0500 Message-ID: Thread-Topic: Updated fecframe scheduling/agenda Thread-Index: AcXfHL3mFZzfo9SVQHa8/QGQN+4jpw== From: "Mark Watson" To: X-OriginalArrivalTime: 01 Nov 2005 19:44:54.0387 (UTC) FILETIME=[BB450C30:01C5DF1C] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Fecframe] Updated fecframe scheduling/agenda X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0543708347==" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org This is a multi-part message in MIME format. --===============0543708347== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DF1C.BAB31070" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DF1C.BAB31070 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, =20 You may or may not have noticed that the fecframe BOF was rescheduled to Wednesday afternoon. I've updated the agenda at http://www3.ietf.org/proceedings/05nov/agenda/fecframe.txt accordingly. Regards, =20 Mark ------_=_NextPart_001_01C5DF1C.BAB31070 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

You may or may not have noticed = that the fecframe BOF was rescheduled to Wednesday afternoon. I’ve updated = the agenda at http:= //www3.ietf.org/proceedings/05nov/agenda/fecframe.txt accordingly.

Regards,

Mark

------_=_NextPart_001_01C5DF1C.BAB31070-- --===============0543708347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============0543708347==-- From fecframe-bounces@ietf.org Wed Nov 09 14:10:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvL7-0007Nl-O9; Wed, 09 Nov 2005 14:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvL6-0007NU-3f for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 14:10:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01410 for ; Wed, 9 Nov 2005 14:10:04 -0500 (EST) Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvbA-0006PY-7y for fecframe@ietf.org; Wed, 09 Nov 2005 14:27:08 -0500 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.0/8.13.0) with ESMTP id jA9JAHB9022937; Wed, 9 Nov 2005 20:10:17 +0100 (MET) Received: from [194.199.16.79] (vpnrocq15.inrialpes.fr [194.199.16.79]) by dwimmerlaik.inrialpes.fr (8.13.4/8.11.3/ImagV2) with ESMTP id jA9JAGLK003188; Wed, 9 Nov 2005 20:10:17 +0100 (MET) Message-ID: <43724992.3010306@inrialpes.fr> Date: Wed, 09 Nov 2005 20:10:10 +0100 From: Vincent Roca User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fecframe@ietf.org, Mark Watson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mx-serv.inrialpes.fr [194.199.18.100]); Wed, 09 Nov 2005 20:10:17 +0100 (MET) X-SMAUG-MailScanner: Found to be clean X-SMAUG-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Subject: [Fecframe] Concerns WRT draft-watson-tsvwg-fec-sf-00.txt licencing conditions X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Dear Mark, I have serious concerns with respect to the licencing conditions described in Digital Fountains IPR Disclosure (copied in this email for convenience). From the FECframe BOF description, it is clear that the existing I-D (draft-watson-tsvwg-fec-sf-00.txt) is forseen to be the underlying transport mechanism. As explained in the associated IPR disclosure, one or more patents cover parts of the technology. If DF says they "will not assert any such Patent claims against any implementing party for fully complying with the Standard", there is a _big_ if: "(ii) [the party must not] challenge the validity of any patent right owned or controlled by Digital Fountain[...]". In our case, we did our best to produce a technology (LDPC staircase/triangle FEC codes) that remains as far as possible from DF's Patents on the subject. In spite of that, DF posted an IPR Disclosure, explaining the LDPC FEC infringes three patents they own. The fact that we stayed on our position and explained that we do not agree will undoubtedly be interpreted as "challenging DF patents" (correct me if I'm wrong), and therefore we do not benefit from the royaltee free licencing terms above. This is not acceptable IMHO. The fact that the IETF does not take any position on IPR claims does not mean this point should not be considered during the FECframe BOF, since the terms of this IPR disclosure, along with the aggressive IPR attitude of DF, are likely to largely restrict the licencing conditions of the FECframe technology. Cheers, Vincent Follows an extract of the IPR disclosure related to draft-watson-tsvwg-fec-sf-00.txt ---------------------------- https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=632 Digital Fountain is the owner of one or more pending unpublished patent applications (the Patents) relating to the subject matter of Internet-Draft draft-watson-tsvwg-fec-sf-00.txt (Forward Error Correction (FEC) Streaming Framework). If the technology that is fully specified in this document is included in a standard adopted by IETF (a Standard) and any claims of the Patents are necessarily infringed by complying with the standard, then Digital Fountain will not assert any such Patent claims against any implementing party for fully complying with the Standard; provided, however, that such implementing party does not (i) assert any patent right owned or controlled by such party against Digital Fountain or any of its successors, or (ii) challenge the validity of any patent right owned or controlled by Digital Fountain or any of its successors. For the avoidance of doubt, Digital Fountain reserves the right to freely assert its patent rights in connection with any product, service, or technology that does not fully comply with the Standard. ---------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Nov 09 15:57:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZx0E-0005or-A6; Wed, 09 Nov 2005 15:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZx0D-0005n7-Fu for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 15:57:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08715 for ; Wed, 9 Nov 2005 15:56:36 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxGD-0001XX-Bv for fecframe@ietf.org; Wed, 09 Nov 2005 16:13:41 -0500 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 09 Nov 2005 12:56:36 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com for ; Wed, 9 Nov 2005 12:56:32 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CEU62901; Wed, 9 Nov 2005 12:56:34 -0800 (PST) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA21966 for ; Wed, 9 Nov 2005 12:56:33 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com ([10.16.192.221]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 12:56:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Nov 2005 12:56:32 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F10415C0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: PNAT? Thread-Index: AcXlcBCQ+hfirK9cTUyFJfuooXY9EA== From: "Caitlin Bestler" To: fecframe@ietf.org X-OriginalArrivalTime: 09 Nov 2005 20:56:34.0744 (UTC) FILETIME=[11C97380:01C5E570] X-WSS-ID: 6F6CBD0937W8654259-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] PNAT? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Does the current proposal require that all middleboxes operate strictly at L3 and below? I don't see how this scheme would work if there are any middleboxes that modify the UDP port numbers as part of a PNAT/firewall function. If the packet had an error it would get tossed at that point, and there would be no chance to repair it later. And doesn't requiring that there me no L4 aware middleboxes all but require this be IPv6? _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Nov 09 16:20:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxN2-0006ZF-02; Wed, 09 Nov 2005 16:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxN0-0006Vj-Ir for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 16:20:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10396 for ; Wed, 9 Nov 2005 16:20:08 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxd3-0002M5-CV for fecframe@ietf.org; Wed, 09 Nov 2005 16:37:14 -0500 Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1EZxMn-0000q4-00; Wed, 09 Nov 2005 22:20:25 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1EZxMn-0003ro-00; Wed, 09 Nov 2005 22:20:25 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 22:20:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fecframe] PNAT? Date: Wed, 9 Nov 2005 16:18:30 -0500 Message-ID: Thread-Topic: [Fecframe] PNAT? Thread-Index: AcXlcBCQ+hfirK9cTUyFJfuooXY9EAAARpiQ From: "Mark Watson" To: "Caitlin Bestler" , X-OriginalArrivalTime: 09 Nov 2005 21:20:25.0364 (UTC) FILETIME=[6680BD40:01C5E573] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Caitlin, The framework itself does not have any requirements with respect to NATs or NAPTs - we require that the receiver knows the UDP flow definitions of the flows containing source and repair data and that there is a path from sender to receiver. Specific protocols that used the framework would have to address how they work through NA(P)Ts. I assume the case you refer to below is where the source and repair flows are identified using different UDP ports and the traffic attempts to traverse a NAT from the 'outside' to the 'inside'. In this case, just as the protocol must arrange for a suitable binding to exist for the source packets, it must also arrange for a suitable binding to exist for the repair packets - it is the same problem for both source and repair flows. If you are thinking of 'retrofitting' the FEC repair flow to an existing source packet protocol with existing NA(P)T traversal support then I think you would need to make the repair packets look like part of the same flow as the source packets from the NA(P)Ts point of view. This is easy, but the tradeoff is that you have to place some restrictions on the packet contents. You need to have somewhere in there to distinguish source from repair packets i.e. you swap some generality for backwards compatibility. Regards, Mark -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Caitlin Bestler Sent: Wednesday, November 09, 2005 12:57 PM To: fecframe@ietf.org Subject: [Fecframe] PNAT? Does the current proposal require that all middleboxes operate strictly at L3 and below? I don't see how this scheme would work if there are any middleboxes that modify the UDP port numbers as part of a PNAT/firewall function. If the packet had an error it would get tossed at that point, and there would be no chance to repair it later. And doesn't requiring that there me no L4 aware middleboxes all but require this be IPv6? _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Nov 09 16:20:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxN2-0006ZT-4A; Wed, 09 Nov 2005 16:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxN0-0006Vk-It for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 16:20:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10397 for ; Wed, 9 Nov 2005 16:20:08 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxd3-0002M6-CQ for fecframe@ietf.org; Wed, 09 Nov 2005 16:37:14 -0500 Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1EZxMo-0003G1-00; Wed, 09 Nov 2005 22:20:26 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1EZxMo-0003rv-00; Wed, 09 Nov 2005 22:20:26 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 22:20:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2005 16:20:41 -0500 Message-ID: Thread-Topic: Concerns WRT draft-watson-tsvwg-fec-sf-00.txt licencing conditions Thread-Index: AcXlYU1FN18p8hdJSB+Dz6uojutXvQAEeHpA From: "Mark Watson" To: "Vincent Roca" , X-OriginalArrivalTime: 09 Nov 2005 21:20:26.0379 (UTC) FILETIME=[671B9DB0:01C5E573] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Fecframe] RE: Concerns WRT draft-watson-tsvwg-fec-sf-00.txt licencing conditions X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Vincent, Our intention and hope is that the FEC Frame work will be free from IPR concerns and this is why we made a 'royalty free' declaration. We think it benefits everyone - ourselves included - if there are protocols which support FEC which can be developed free from IPR concerns with IPR only being considered when it comes to the choice of FEC code. This has been the basis of our approach in RMT for many years now and is one of the motivations behind the FEC Building Block approach. The reciprocity clause you cite is, in my understanding, a normal thing in such IPR disclosures and just means that in the event of formal legal disputes between us and another company then all our patents can be taken into account, as you might expect in that situation.=20 To answer your question, whether or not you have publicly stated some opinions about some other patents, what those opinions are, and who does and doesn't agree with them, has no bearing on this issue. Best regards, Mark -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: Wednesday, November 09, 2005 11:10 AM To: fecframe@ietf.org; Mark Watson Cc: Vincent Roca Subject: Concerns WRT draft-watson-tsvwg-fec-sf-00.txt licencing conditions Dear Mark, I have serious concerns with respect to the licencing conditions=20 described in Digital Fountains IPR Disclosure (copied in this email for convenience). From the FECframe BOF description, it is clear that the existing I-D (draft-watson-tsvwg-fec-sf-00.txt) is forseen to be the underlying=20 transport mechanism. As explained in the associated IPR disclosure, one or more=20 patents cover parts of the technology. If DF says they "will not assert any such Patent claims against any implementing party for fully complying with the=20 Standard", there is a _big_ if: "(ii) [the party must not] challenge the validity of any=20 patent right owned or controlled by Digital Fountain[...]". In our case, we did our best to produce a technology (LDPC=20 staircase/triangle FEC codes) that remains as far as possible from DF's Patents on the=20 subject. In spite of that, DF posted an IPR Disclosure, explaining the LDPC FEC=20 infringes three patents they own. The fact that we stayed on our position and=20 explained that we do not agree will undoubtedly be interpreted as "challenging DF patents" (correct me if I'm wrong), and therefore we do not benefit from the=20 royaltee free licencing terms above. This is not acceptable IMHO. The fact that the IETF does not take any position on IPR claims does not mean this point should not be considered during the FECframe BOF, since the=20 terms of this IPR disclosure, along with the aggressive IPR attitude of DF, are=20 likely to largely restrict the licencing conditions of the FECframe technology. Cheers, Vincent Follows an extract of the IPR disclosure related to=20 draft-watson-tsvwg-fec-sf-00.txt ---------------------------- https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D632 Digital Fountain is the owner of one or more pending unpublished patent applications (the Patents) relating to the subject matter of Internet-Draft draft-watson-tsvwg-fec-sf-00.txt (Forward Error=20 Correction (FEC) Streaming Framework). If the technology that is fully specified in this document is included in a standard adopted by IETF (a Standard) and any claims of the Patents are necessarily infringed by complying with the standard, then Digital=20 Fountain will not assert any such Patent claims against any implementing party for fully complying with the Standard; provided, however, that such implementing=20 party does not (i) assert any patent right owned or controlled by such party=20 against Digital Fountain or any of its successors, or (ii) challenge the=20 validity of any patent right owned or controlled by Digital Fountain or any of its=20 successors. For the avoidance of doubt, Digital Fountain reserves the right to=20 freely assert its patent rights in connection with any product, service, or technology that does not fully comply with the Standard. ---------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Nov 09 16:26:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSS-0001Th-PE; Wed, 09 Nov 2005 16:26:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSR-0001Tc-IC for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 16:26:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10695 for ; Wed, 9 Nov 2005 16:25:47 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxiU-0002UW-Pb for fecframe@ietf.org; Wed, 09 Nov 2005 16:42:53 -0500 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 09 Nov 2005 13:25:51 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 9 Nov 2005 13:25:47 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CEU70511; Wed, 9 Nov 2005 13:25:49 -0800 (PST) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA28837; Wed, 9 Nov 2005 13:25:48 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com ([10.16.192.221]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 13:25:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Fecframe] PNAT? Date: Wed, 9 Nov 2005 13:25:48 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F10415C7@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Fecframe] PNAT? Thread-Index: AcXlcBCQ+hfirK9cTUyFJfuooXY9EAAARpiQAAChmeA= From: "Caitlin Bestler" To: "Mark Watson" , fecframe@ietf.org X-OriginalArrivalTime: 09 Nov 2005 21:25:51.0446 (UTC) FILETIME=[28DCE760:01C5E574] X-WSS-ID: 6F6CB6D537W8664115-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org I'm asking a more general question. If the UDP port is being mangled in route, then what UDP packets will be eligible for repair? Won't any that are damaged in transit be tossed by the PNATting device? If the UDP datagram is already damanged they cannot modify the header and then forward it.=20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Wednesday, November 09, 2005 1:19 PM > To: Caitlin Bestler; fecframe@ietf.org > Subject: RE: [Fecframe] PNAT? >=20 > Caitlin, >=20 > The framework itself does not have any requirements with=20 > respect to NATs or NAPTs - we require that the receiver knows=20 > the UDP flow definitions of the flows containing source and=20 > repair data and that there is a path from sender to receiver. >=20 > Specific protocols that used the framework would have to=20 > address how they work through NA(P)Ts. I assume the case you=20 > refer to below is where the source and repair flows are=20 > identified using different UDP ports and the traffic attempts=20 > to traverse a NAT from the 'outside' to the 'inside'. >=20 > In this case, just as the protocol must arrange for a=20 > suitable binding to exist for the source packets, it must=20 > also arrange for a suitable binding to exist for the repair=20 > packets - it is the same problem for both source and repair flows. >=20 > If you are thinking of 'retrofitting' the FEC repair flow to=20 > an existing source packet protocol with existing NA(P)T=20 > traversal support then I think you would need to make the=20 > repair packets look like part of the same flow as the source=20 > packets from the NA(P)Ts point of view. This is easy, but the=20 > tradeoff is that you have to place some restrictions on the=20 > packet contents. You need to have somewhere in there to=20 > distinguish source from repair packets i.e. you swap some=20 > generality for backwards compatibility. >=20 > Regards, >=20 > Mark >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Caitlin Bestler > Sent: Wednesday, November 09, 2005 12:57 PM > To: fecframe@ietf.org > Subject: [Fecframe] PNAT? >=20 > Does the current proposal require that all middleboxes=20 > operate strictly at L3 and below? I don't see how this scheme=20 > would work if there are any middleboxes that modify the UDP=20 > port numbers as part of a PNAT/firewall function. If the=20 > packet had an error it would get tossed at that point, and=20 > there would be no chance to repair it later. >=20 > And doesn't requiring that there me no L4 aware middleboxes=20 > all but require this be IPv6? >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe >=20 >=20 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Wed Nov 09 16:35:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxbo-00042J-3I; Wed, 09 Nov 2005 16:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxbm-0003yt-BX for fecframe@megatron.ietf.org; Wed, 09 Nov 2005 16:35:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11716 for ; Wed, 9 Nov 2005 16:35:26 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxrr-0002va-Fr for fecframe@ietf.org; Wed, 09 Nov 2005 16:52:32 -0500 Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1EZxbd-0003yT-00; Wed, 09 Nov 2005 22:35:45 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1EZxbd-0005gQ-00; Wed, 09 Nov 2005 22:35:45 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 22:35:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fecframe] PNAT? Date: Wed, 9 Nov 2005 16:36:03 -0500 Message-ID: Thread-Topic: [Fecframe] PNAT? Thread-Index: AcXlcBCQ+hfirK9cTUyFJfuooXY9EAAARpiQAAChmeAAADh+8A== From: "Mark Watson" To: "Caitlin Bestler" , X-OriginalArrivalTime: 09 Nov 2005 21:35:45.0769 (UTC) FILETIME=[8B1B6590:01C5E575] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Caitlin, Actually, we are concerned with erasure correction, so we are exactly concerned with recovering packets which are lost for whatever reason (rather than 'repairing' packets which are received with errors). There are of course many reasons why packets which pick up an error will be discarded before reaching the end host. ...Mark -----Original Message----- From: Caitlin Bestler [mailto:caitlinb@broadcom.com]=20 Sent: Wednesday, November 09, 2005 1:26 PM To: Mark Watson; fecframe@ietf.org Subject: RE: [Fecframe] PNAT? I'm asking a more general question. If the UDP port is being mangled in route, then what UDP packets will be eligible for repair? Won't any that are damaged in transit be tossed by the PNATting device? If the UDP datagram is already damanged they cannot modify the header and then forward it.=20 > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com]=20 > Sent: Wednesday, November 09, 2005 1:19 PM > To: Caitlin Bestler; fecframe@ietf.org > Subject: RE: [Fecframe] PNAT? >=20 > Caitlin, >=20 > The framework itself does not have any requirements with=20 > respect to NATs or NAPTs - we require that the receiver knows=20 > the UDP flow definitions of the flows containing source and=20 > repair data and that there is a path from sender to receiver. >=20 > Specific protocols that used the framework would have to=20 > address how they work through NA(P)Ts. I assume the case you=20 > refer to below is where the source and repair flows are=20 > identified using different UDP ports and the traffic attempts=20 > to traverse a NAT from the 'outside' to the 'inside'. >=20 > In this case, just as the protocol must arrange for a=20 > suitable binding to exist for the source packets, it must=20 > also arrange for a suitable binding to exist for the repair=20 > packets - it is the same problem for both source and repair flows. >=20 > If you are thinking of 'retrofitting' the FEC repair flow to=20 > an existing source packet protocol with existing NA(P)T=20 > traversal support then I think you would need to make the=20 > repair packets look like part of the same flow as the source=20 > packets from the NA(P)Ts point of view. This is easy, but the=20 > tradeoff is that you have to place some restrictions on the=20 > packet contents. You need to have somewhere in there to=20 > distinguish source from repair packets i.e. you swap some=20 > generality for backwards compatibility. >=20 > Regards, >=20 > Mark >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Caitlin Bestler > Sent: Wednesday, November 09, 2005 12:57 PM > To: fecframe@ietf.org > Subject: [Fecframe] PNAT? >=20 > Does the current proposal require that all middleboxes=20 > operate strictly at L3 and below? I don't see how this scheme=20 > would work if there are any middleboxes that modify the UDP=20 > port numbers as part of a PNAT/firewall function. If the=20 > packet had an error it would get tossed at that point, and=20 > there would be no chance to repair it later. >=20 > And doesn't requiring that there me no L4 aware middleboxes=20 > all but require this be IPv6? >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe >=20 >=20 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Nov 21 12:14:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFFn-0005Y7-Jq; Mon, 21 Nov 2005 12:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFFm-0005Xi-SU for fecframe@megatron.ietf.org; Mon, 21 Nov 2005 12:14:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15922 for ; Mon, 21 Nov 2005 12:14:16 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFY9-0001FK-SX for fecframe@ietf.org; Mon, 21 Nov 2005 12:34:01 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7D4774F0003 for ; Mon, 21 Nov 2005 18:14:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:13:36 +0100 Received: from [147.214.34.71] ([147.214.34.71]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:13:36 +0100 Message-ID: <43820040.8080008@ericsson.com> Date: Mon, 21 Nov 2005 18:13:36 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fecframe@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2005 17:13:36.0580 (UTC) FILETIME=[E8BCA040:01C5EEBE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [Fecframe] FECFrame WG Charter Proposal X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi, Here is an charter proposal as proposed by Me, Stephan Wenger and Mark Watson. Please read and comment. Cheers Magnus Westerlund Charter for FECFrame Working Group (Draft 051121) The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The group will build on the work of the RMT working group in the form of the FEC Building Block developed there to ensure that the framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. A primary objective of this framework is to support FEC for streaming media. Other usages will be considered and prioritized, if brought to the working groups attention during the development of the requirements. The group will coordinate closely with AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least, considering that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of IP flows over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. MILESTONES: April 06 - Working Group consensus on requirements and their prioritization for the FEC protocol framework August 06 - Completed selection of solution to develop and mature April 07 - FEC Streaming Framework submitted as Proposed Standard August 07 - Submit supporting specifications such as usage considerations, signalling interactions and requirements for publication. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Nov 22 14:38:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eedxw-0001fr-V2; Tue, 22 Nov 2005 14:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eedxv-0001e7-CM for fecframe@megatron.ietf.org; Tue, 22 Nov 2005 14:38:07 -0500 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01068 for ; Tue, 22 Nov 2005 14:37:27 -0500 (EST) Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Eedxt-0007SB-00 for fecframe@lists.ietf.org; Tue, 22 Nov 2005 20:38:05 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1Eedxt-0001Eb-00 for fecframe@lists.ietf.org; Tue, 22 Nov 2005 20:38:05 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 20:38:05 +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, 22 Nov 2005 14:37:33 -0500 Message-ID: Thread-Topic: IETF64 Fecframe BOF minutes Thread-Index: AcXvnC9vqjjLifT0Qpm7KlBsBOVKYQ== From: "Mark Watson" To: X-OriginalArrivalTime: 22 Nov 2005 19:38:05.0504 (UTC) FILETIME=[423B3400:01C5EF9C] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] IETF64 Fecframe BOF minutes X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org All, Draft minutes are available at: http://www3.ietf.org/proceedings/05nov/minutes/fecframe.txt Please provide comments by the end of next week (2 December). Best regards, Mark Watson _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Nov 22 15:31:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeenY-0001DA-7T; Tue, 22 Nov 2005 15:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeenW-0001D2-Ni for fecframe@megatron.ietf.org; Tue, 22 Nov 2005 15:31:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07336 for ; Tue, 22 Nov 2005 15:30:47 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eef6E-0002Ij-Cm for fecframe@ietf.org; Tue, 22 Nov 2005 15:50:47 -0500 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 22 Nov 2005 12:31:01 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com for ; Tue, 22 Nov 2005 12:31:01 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGE18983; Tue, 22 Nov 2005 12:30:54 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA21955 for ; Tue, 22 Nov 2005 12:30:54 -0800 ( PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jAMKUsov017123 for ; Tue, 22 Nov 2005 12:30:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Nov 2005 12:30:48 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1041B0E@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Why FEC? Thread-Index: AcXuv0Tx0Ic1FmCFTM+uXvCODa29lwA4+rGg From: "Caitlin Bestler" To: fecframe@ietf.org X-WSS-ID: 6F9D5F8F2JW754911-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] Why FEC? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org This is one of those fundamental questions that might have a simple answer, but even if it does it needs to be stated. >=20 > Charter for FECFrame Working Group (Draft 051121) >=20 > The object of this group is to develop specifications for > using forward error correction (FEC) codes with applications > in the Internet to provide protection against packet loss. > The question is, why FEC? Why not simple RAID striping? What is the benefit of FEC over striping, or even packet mirroring? The costs of FEC are increased complexity and greater processing power requirements. So what is the justification? _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Nov 22 16:47:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eefyv-0002T2-T4; Tue, 22 Nov 2005 16:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eefyu-0002RU-Nk for fecframe@megatron.ietf.org; Tue, 22 Nov 2005 16:47:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16528 for ; Tue, 22 Nov 2005 16:46:38 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EegHd-0006na-TW for fecframe@ietf.org; Tue, 22 Nov 2005 17:06:38 -0500 Received: from [212.227.126.203] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Eefyl-0002Zs-00; Tue, 22 Nov 2005 22:47:07 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1Eefyl-0000NO-00; Tue, 22 Nov 2005 22:47:07 +0100 Received: from NTXBEUS02.exchange.xchg ([172.23.129.5]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 22:47:07 +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 Subject: RE: [Fecframe] Why FEC? Date: Tue, 22 Nov 2005 16:46:35 -0500 Message-ID: Thread-Topic: [Fecframe] Why FEC? Thread-Index: AcXuv0Tx0Ic1FmCFTM+uXvCODa29lwA4+rGgAABNCEA= From: "Mark Watson" To: "Caitlin Bestler" , X-OriginalArrivalTime: 22 Nov 2005 21:47:07.0718 (UTC) FILETIME=[48F34E60:01C5EFAE] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Caitlin, To answer your question, I need to take a guess at what you mean by "RAID striping" and "packet mirroring", or more precisely how you would apply these to communication over a network with packet loss. I would guess that by "packet mirroring" you just mean sending duplicate copies of each packet, so that the chance of losing both copies becomes very low. I would guess that by "RAID Striping" you mean sending some packets which are the XOR of some previous packets, so that if you lose any one packet it can be recovered using the redundant XOR packet. If I guess right, then I would consider both those techniques to be FEC codes. In both cases you preemptively send additional data which allows the receiver to recover from the loss of packets en route. So, then your question becomes one about the merits of different FEC codes. Here there is a simple answer, in that different FEC codes have different properties in terms of the pattern and number of errors they can correct, the additional bandwidth they require, the computational complexity at sender and receiver and the flexibility of the code to adapt along these axes to different applications. Different applications and different networks have different requirements and constraints which mean there is a place for a variety of different FEC codes. Simple XOR and repetition codes such as described above tend to be computationally efficient but have a very high cost in terms of bandwidth (which is an ongoing cost compared to the one-off cost of CPU power) and are relatively weak in terms of error protection, in many cases being simply incapable of providing the protection needed, especially when looking at the kind of quality targets considered for IPTV. Regards, Mark Watson -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Caitlin Bestler Sent: Tuesday, November 22, 2005 12:31 PM To: fecframe@ietf.org Subject: [Fecframe] Why FEC? This is one of those fundamental questions that might have a simple answer, but even if it does it needs to be stated. >=20 > Charter for FECFrame Working Group (Draft 051121) >=20 > The object of this group is to develop specifications for > using forward error correction (FEC) codes with applications > in the Internet to provide protection against packet loss. > The question is, why FEC? Why not simple RAID striping? What is the benefit of FEC over striping, or even packet mirroring? The costs of FEC are increased complexity and greater processing power requirements. So what is the justification? _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe