From routing-discussion-admin@ietf.org Tue Apr 1 12:35:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02581 for ; Tue, 1 Apr 2003 12:35:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31He6K12079; Tue, 1 Apr 2003 12:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HcIK11502 for ; Tue, 1 Apr 2003 12:38:18 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00616 for ; Tue, 1 Apr 2003 12:13:57 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190PN2-000G0l-00 for routing-discussion@ietf.org; Tue, 01 Apr 2003 09:16:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <128279855040.20030331191752@psg.com> To: routing-discussion@ietf.org Subject: Anyone esle took notes at the meeting? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 19:17:52 -0800 Content-Transfer-Encoding: 7bit Guys- If anyone was taking notes at the meeting, and you believe you have them in a detailed form, and think you're good at it ;), please send them to me. Dimitry did a great job, but it was a way too active session for a single person to capture everything right. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 1 12:36:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02633 for ; Tue, 1 Apr 2003 12:36:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31I0Ud18774 for routing-discussion-archive@odin.ietf.org; Tue, 1 Apr 2003 13:00:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31He6K12079; Tue, 1 Apr 2003 12:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HcIK11502 for ; Tue, 1 Apr 2003 12:38:18 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00616 for ; Tue, 1 Apr 2003 12:13:57 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190PN2-000G0l-00 for routing-discussion@ietf.org; Tue, 01 Apr 2003 09:16:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <128279855040.20030331191752@psg.com> To: routing-discussion@ietf.org Subject: Anyone esle took notes at the meeting? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Mar 2003 19:17:52 -0800 Content-Transfer-Encoding: 7bit Guys- If anyone was taking notes at the meeting, and you believe you have them in a detailed form, and think you're good at it ;), please send them to me. Dimitry did a great job, but it was a way too active session for a single person to capture everything right. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Apr 1 21:02:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25249 for ; Tue, 1 Apr 2003 21:02:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h322AtK09049; Tue, 1 Apr 2003 21:10:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32294K08943 for ; Tue, 1 Apr 2003 21:09:05 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24629 for ; Tue, 1 Apr 2003 20:44:33 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190XLA-000Ohv-00; Tue, 01 Apr 2003 17:47:00 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8922313044.20030401174552@psg.com> To: routing-discussion@ietf.org CC: Susan Hares Subject: Volunteers for RTG-MIBS group MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Apr 2003 17:45:52 -0800 Content-Transfer-Encoding: 7bit Folks- We're looking for volunteers who would like to contribute their time to help with MIB work in the Routing area. Sue Hares, who suggested this idea, kindly agreed to coordinate this effort. If you would like to be in this group, please drop Sue and myself a message. Please also indicate if you have any prior experience with MIB design & development. Regards. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 1 21:03:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25269 for ; Tue, 1 Apr 2003 21:03:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h322Rd409721 for routing-discussion-archive@odin.ietf.org; Tue, 1 Apr 2003 21:27:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h322AtK09049; Tue, 1 Apr 2003 21:10:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32294K08943 for ; Tue, 1 Apr 2003 21:09:05 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24629 for ; Tue, 1 Apr 2003 20:44:33 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190XLA-000Ohv-00; Tue, 01 Apr 2003 17:47:00 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8922313044.20030401174552@psg.com> To: routing-discussion@ietf.org CC: Susan Hares Subject: Volunteers for RTG-MIBS group MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Apr 2003 17:45:52 -0800 Content-Transfer-Encoding: 7bit Folks- We're looking for volunteers who would like to contribute their time to help with MIB work in the Routing area. Sue Hares, who suggested this idea, kindly agreed to coordinate this effort. If you would like to be in this group, please drop Sue and myself a message. Please also indicate if you have any prior experience with MIB design & development. Regards. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 01:23:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16932 for ; Mon, 7 Apr 2003 01:23:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3751L829542; Mon, 7 Apr 2003 01:01:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374s1829301 for ; Mon, 7 Apr 2003 00:54:01 -0400 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15253 for ; Mon, 7 Apr 2003 00:49:27 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCY00B1OIULRZ@mailout2.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:51:57 +0900 (KST) Received: from ms.samsung.com (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCY004EKITIDE@mailout2.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:51:19 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCY00501ILLVC@ms.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:46:33 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCY00DNGILKX2@ms.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:46:32 +0900 (KST) Received: from [107.108.3.177] by ms.samsung.com (mshttpd); Mon, 07 Apr 2003 04:46:32 +0000 (GMT) From: Karthikeyan Subject: RFC 1583 compatibility support in OSPFv3 To: routing-discussion@ietf.org Message-id: <8393284e4b.84e4b83932@samsung.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.05 (built Nov 6 2002) Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 04:46:32 +0000 (GMT) Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dundefined=5F=5Fundefined20030407101856765 width=3D=22= 1=22 height=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3EHi=2C I would like to know whether OSPFv3 should incorporate the RFC 1583 = compatibility support=2E RFC 2740 (OSPFv3) does not speak about the = RFC 1583 compatibility support=2E As RFC 2740 is inherited from RFC 2328=2C= which in turn speaks about RFC 1583 compatibility=2E Can anybody mail me if OSPFv3 should support RFC 1583 compatibility features=3F Thanks in advance=2E with regards=2C S=2EKarthikeyan=2E=3C/font=3E=3C/pre=3E=3C/html=3E _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 01:24:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16948 for ; Mon, 7 Apr 2003 01:24:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h375SpG31179 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 01:28:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3751L829542; Mon, 7 Apr 2003 01:01:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h374s1829301 for ; Mon, 7 Apr 2003 00:54:01 -0400 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15253 for ; Mon, 7 Apr 2003 00:49:27 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCY00B1OIULRZ@mailout2.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:51:57 +0900 (KST) Received: from ms.samsung.com (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCY004EKITIDE@mailout2.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:51:19 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCY00501ILLVC@ms.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:46:33 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCY00DNGILKX2@ms.samsung.com> for routing-discussion@ietf.org; Mon, 07 Apr 2003 13:46:32 +0900 (KST) Received: from [107.108.3.177] by ms.samsung.com (mshttpd); Mon, 07 Apr 2003 04:46:32 +0000 (GMT) From: Karthikeyan Subject: RFC 1583 compatibility support in OSPFv3 To: routing-discussion@ietf.org Message-id: <8393284e4b.84e4b83932@samsung.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.05 (built Nov 6 2002) Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 04:46:32 +0000 (GMT) Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dundefined=5F=5Fundefined20030407101856765 width=3D=22= 1=22 height=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3EHi=2C I would like to know whether OSPFv3 should incorporate the RFC 1583 = compatibility support=2E RFC 2740 (OSPFv3) does not speak about the = RFC 1583 compatibility support=2E As RFC 2740 is inherited from RFC 2328=2C= which in turn speaks about RFC 1583 compatibility=2E Can anybody mail me if OSPFv3 should support RFC 1583 compatibility features=3F Thanks in advance=2E with regards=2C S=2EKarthikeyan=2E=3C/font=3E=3C/pre=3E=3C/html=3E _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 01:58:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19040 for ; Mon, 7 Apr 2003 01:58:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375aD831387; Mon, 7 Apr 2003 01:36:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375VR831274 for ; Mon, 7 Apr 2003 01:31:27 -0400 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17048 for ; Mon, 7 Apr 2003 01:26:52 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h375SpHP020139 for ; Sun, 6 Apr 2003 22:28:52 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA17552 for ; Sun, 6 Apr 2003 22:29:22 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CF6R>; Mon, 7 Apr 2003 01:28:26 -0400 Message-ID: From: "Manral, Vishwas" To: "'Karthikeyan'" , routing-discussion@ietf.org Subject: RE: RFC 1583 compatibility support in OSPFv3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FCC6.C94CE860" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 01:30:23 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FCC6.C94CE860 Content-Type: text/plain; charset="KS_C_5601-1987" Hi Karthikeyan, In my view there is no reason for OSPFv3 to support RFC1583 compatibility. Besides you can mail OSPF specific questions to the OSPF list. Details can be found at http://www.ietf.org/html.charters/ospf-charter.html Thanks, Vishwas -----Original Message----- From: Karthikeyan [mailto:karthiks@samsung.com] Sent: Monday, April 07, 2003 10:17 AM To: routing-discussion@ietf.org Subject: RFC 1583 compatibility support in OSPFv3 Hi, I would like to know whether OSPFv3 should incorporate the RFC 1583 compatibility support. RFC 2740 (OSPFv3) does not speak about the RFC 1583 compatibility support. As RFC 2740 is inherited from RFC 2328, which in turn speaks about RFC 1583 compatibility. Can anybody mail me if OSPFv3 should support RFC 1583 compatibility features? Thanks in advance. with regards, S.Karthikeyan. ------_=_NextPart_001_01C2FCC6.C94CE860 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi=20 Karthikeyan,
 
In my=20 view there is no reason for OSPFv3 to support RFC1583=20 compatibility.
 
Besides you can mail OSPF specific questions = to the=20 OSPF list. Details can be found at
http://www.= ietf.org/html.charters/ospf-charter.html
 
Thanks,
Vishwas
 
-----Original=20 Message-----
From: Karthikeyan=20 [mailto:karthiks@samsung.com]
Sent: Monday, April 07, 2003 = 10:17=20 AM
To: routing-discussion@ietf.org
Subject: RFC = 1583=20 compatibility support in OSPFv3

Hi,

  I would like to know whether OSPFv3 should = incorporate=20 the RFC 1583
compatibility support. RFC 2740 (OSPFv3) does not = speak about=20 the
RFC 1583 compatibility support. As RFC 2740 is inherited from = RFC 2328,=20 which
in turn speaks about RFC 1583=20 compatibility.

     Can anybody mail me if = OSPFv3=20 should support RFC 1583 compatibility
features?

Thanks in=20 advance.

with = regards,
S.Karthikeyan.
------_=_NextPart_001_01C2FCC6.C94CE860-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 01:59:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19074 for ; Mon, 7 Apr 2003 01:59:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3763Sb01675 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 02:03:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375aD831387; Mon, 7 Apr 2003 01:36:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375VR831274 for ; Mon, 7 Apr 2003 01:31:27 -0400 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17048 for ; Mon, 7 Apr 2003 01:26:52 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h375SpHP020139 for ; Sun, 6 Apr 2003 22:28:52 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA17552 for ; Sun, 6 Apr 2003 22:29:22 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CF6R>; Mon, 7 Apr 2003 01:28:26 -0400 Message-ID: From: "Manral, Vishwas" To: "'Karthikeyan'" , routing-discussion@ietf.org Subject: RE: RFC 1583 compatibility support in OSPFv3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FCC6.C94CE860" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 01:30:23 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FCC6.C94CE860 Content-Type: text/plain; charset="KS_C_5601-1987" Hi Karthikeyan, In my view there is no reason for OSPFv3 to support RFC1583 compatibility. Besides you can mail OSPF specific questions to the OSPF list. Details can be found at http://www.ietf.org/html.charters/ospf-charter.html Thanks, Vishwas -----Original Message----- From: Karthikeyan [mailto:karthiks@samsung.com] Sent: Monday, April 07, 2003 10:17 AM To: routing-discussion@ietf.org Subject: RFC 1583 compatibility support in OSPFv3 Hi, I would like to know whether OSPFv3 should incorporate the RFC 1583 compatibility support. RFC 2740 (OSPFv3) does not speak about the RFC 1583 compatibility support. As RFC 2740 is inherited from RFC 2328, which in turn speaks about RFC 1583 compatibility. Can anybody mail me if OSPFv3 should support RFC 1583 compatibility features? Thanks in advance. with regards, S.Karthikeyan. ------_=_NextPart_001_01C2FCC6.C94CE860 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi=20 Karthikeyan,
 
In my=20 view there is no reason for OSPFv3 to support RFC1583=20 compatibility.
 
Besides you can mail OSPF specific questions = to the=20 OSPF list. Details can be found at
http://www.= ietf.org/html.charters/ospf-charter.html
 
Thanks,
Vishwas
 
-----Original=20 Message-----
From: Karthikeyan=20 [mailto:karthiks@samsung.com]
Sent: Monday, April 07, 2003 = 10:17=20 AM
To: routing-discussion@ietf.org
Subject: RFC = 1583=20 compatibility support in OSPFv3

Hi,

  I would like to know whether OSPFv3 should = incorporate=20 the RFC 1583
compatibility support. RFC 2740 (OSPFv3) does not = speak about=20 the
RFC 1583 compatibility support. As RFC 2740 is inherited from = RFC 2328,=20 which
in turn speaks about RFC 1583=20 compatibility.

     Can anybody mail me if = OSPFv3=20 should support RFC 1583 compatibility
features?

Thanks in=20 advance.

with = regards,
S.Karthikeyan.
------_=_NextPart_001_01C2FCC6.C94CE860-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 06:35:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14167 for ; Mon, 7 Apr 2003 06:35:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37ADr829715; Mon, 7 Apr 2003 06:13:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AAP829582 for ; Mon, 7 Apr 2003 06:10:25 -0400 Received: from web20710.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13574 for ; Mon, 7 Apr 2003 06:05:45 -0400 (EDT) Message-ID: <20030407100815.11076.qmail@web20710.mail.yahoo.com> Received: from [210.118.108.254] by web20710.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 06:08:15 EDT From: Tulip Rasputin Subject: stateless and stateful To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 06:08:15 -0400 (EDT) Hello, What is the difference between the stateless restarts and stateful restarts in the routing protocols (the IGPs to be specific) Wishes, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 06:36:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14187 for ; Mon, 7 Apr 2003 06:36:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37AeWp31511 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 06:40:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37ADr829715; Mon, 7 Apr 2003 06:13:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AAP829582 for ; Mon, 7 Apr 2003 06:10:25 -0400 Received: from web20710.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13574 for ; Mon, 7 Apr 2003 06:05:45 -0400 (EDT) Message-ID: <20030407100815.11076.qmail@web20710.mail.yahoo.com> Received: from [210.118.108.254] by web20710.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 06:08:15 EDT From: Tulip Rasputin Subject: stateless and stateful To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 06:08:15 -0400 (EDT) Hello, What is the difference between the stateless restarts and stateful restarts in the routing protocols (the IGPs to be specific) Wishes, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 08:13:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18137 for ; Mon, 7 Apr 2003 08:13:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Bq3803894; Mon, 7 Apr 2003 07:52:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BmA803769 for ; Mon, 7 Apr 2003 07:48:10 -0400 Received: from naturesoft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17112 for ; Mon, 7 Apr 2003 07:43:25 -0400 (EDT) Received: from [192.168.0.15] (helo=vinay.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 192V0I-0007Rc-00; Mon, 07 Apr 2003 17:11:34 +0530 Subject: Re: stateless and stateful From: Vinay K Nallamothu To: Tulip Rasputin Cc: routing-discussion@ietf.org In-Reply-To: <20030407100815.11076.qmail@web20710.mail.yahoo.com> References: <20030407100815.11076.qmail@web20710.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1049716505.4609.67.camel@vinay.royalchallenge.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Apr 2003 17:25:05 +0530 Content-Transfer-Encoding: 7bit From what I understand On Mon, 2003-04-07 at 15:38, Tulip Rasputin wrote: > Hello, > What is the difference between the stateless restarts Whenever the protocol daemon (the management plane) is restarted either due to crash or planned upgrades, the route map database is lost and has to be rebuilt from the scratch. While this process takes some time for the route map to be in sync with the rest of the nodes. Stateless restarts cause route flaps causing routing instabilities such transient loops while the router takes time to resynchronize its the routing database with its neighbors and compute the optimal paths. > and stateful restarts in the routing protocols (the In Statefull/Gracefull restart, the routing database and few other information is retained across restart. To make this work, a graceful restart capable router indicates others its capability to do so and > IGPs to be specific) route flapping causes OSPF to recompute the paths a CPU intensive operation. http://www.saint2004.org/archives/wk4-ipv6/yasu_OSPF.pdf vinay _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 08:14:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18166 for ; Mon, 7 Apr 2003 08:14:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37CInN05774 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 08:18:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Bq3803894; Mon, 7 Apr 2003 07:52:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BmA803769 for ; Mon, 7 Apr 2003 07:48:10 -0400 Received: from naturesoft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17112 for ; Mon, 7 Apr 2003 07:43:25 -0400 (EDT) Received: from [192.168.0.15] (helo=vinay.royalchallenge.com) by naturesoft.net with esmtp (Exim 3.35 #1) id 192V0I-0007Rc-00; Mon, 07 Apr 2003 17:11:34 +0530 Subject: Re: stateless and stateful From: Vinay K Nallamothu To: Tulip Rasputin Cc: routing-discussion@ietf.org In-Reply-To: <20030407100815.11076.qmail@web20710.mail.yahoo.com> References: <20030407100815.11076.qmail@web20710.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1049716505.4609.67.camel@vinay.royalchallenge.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Apr 2003 17:25:05 +0530 Content-Transfer-Encoding: 7bit From what I understand On Mon, 2003-04-07 at 15:38, Tulip Rasputin wrote: > Hello, > What is the difference between the stateless restarts Whenever the protocol daemon (the management plane) is restarted either due to crash or planned upgrades, the route map database is lost and has to be rebuilt from the scratch. While this process takes some time for the route map to be in sync with the rest of the nodes. Stateless restarts cause route flaps causing routing instabilities such transient loops while the router takes time to resynchronize its the routing database with its neighbors and compute the optimal paths. > and stateful restarts in the routing protocols (the In Statefull/Gracefull restart, the routing database and few other information is retained across restart. To make this work, a graceful restart capable router indicates others its capability to do so and > IGPs to be specific) route flapping causes OSPF to recompute the paths a CPU intensive operation. http://www.saint2004.org/archives/wk4-ipv6/yasu_OSPF.pdf vinay _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 08:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18807 for ; Mon, 7 Apr 2003 08:57:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CZL806357; Mon, 7 Apr 2003 08:35:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CWu806269 for ; Mon, 7 Apr 2003 08:32:56 -0400 Received: from web20708.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18393 for ; Mon, 7 Apr 2003 08:28:12 -0400 (EDT) Message-ID: <20030407123044.10657.qmail@web20708.mail.yahoo.com> Received: from [210.118.108.254] by web20708.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 08:30:44 EDT From: Tulip Rasputin Subject: Re: stateless and stateful To: vinay-rc@naturesoft.net Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 08:30:44 -0400 (EDT) Vinay, You mean to say that the Graceful/Hitless Restart <==> Stateless Restart and the normal destructive restart <==> Stateful Restart. I dont think so because i remember reading somewhere that the graceful restart designs can come in 2 flavors - stateful and stateless. CPU intensive > operation. > http://www.saint2004.org/archives/wk4-ipv6/yasu_OSPF.pdf Yeah .. i saw the slides. It doesnt seem to talk of the graceful or non-graceful restarts at all. It basically studies the effect of persistent route flappings on OSPF. Any way i could get hold of the actual paper? Tulip. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 08:58:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18824 for ; Mon, 7 Apr 2003 08:58:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37D2Iu08264 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 09:02:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CZL806357; Mon, 7 Apr 2003 08:35:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37CWu806269 for ; Mon, 7 Apr 2003 08:32:56 -0400 Received: from web20708.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18393 for ; Mon, 7 Apr 2003 08:28:12 -0400 (EDT) Message-ID: <20030407123044.10657.qmail@web20708.mail.yahoo.com> Received: from [210.118.108.254] by web20708.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 08:30:44 EDT From: Tulip Rasputin Subject: Re: stateless and stateful To: vinay-rc@naturesoft.net Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 08:30:44 -0400 (EDT) Vinay, You mean to say that the Graceful/Hitless Restart <==> Stateless Restart and the normal destructive restart <==> Stateful Restart. I dont think so because i remember reading somewhere that the graceful restart designs can come in 2 flavors - stateful and stateless. CPU intensive > operation. > http://www.saint2004.org/archives/wk4-ipv6/yasu_OSPF.pdf Yeah .. i saw the slides. It doesnt seem to talk of the graceful or non-graceful restarts at all. It basically studies the effect of persistent route flappings on OSPF. Any way i could get hold of the actual paper? Tulip. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 12:41:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26746 for ; Mon, 7 Apr 2003 12:41:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GG4823746; Mon, 7 Apr 2003 12:16:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37G8x823344 for ; Mon, 7 Apr 2003 12:08:59 -0400 Received: from web41806.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24645 for ; Mon, 7 Apr 2003 12:04:11 -0400 (EDT) Message-ID: <20030407160641.47395.qmail@web41806.mail.yahoo.com> Received: from [65.213.193.49] by web41806.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:06:41 PDT From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1705966920-1049731601=:47165" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 09:06:41 -0700 (PDT) --0-1705966920-1049731601=:47165 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-1705966920-1049731601=:47165 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-1705966920-1049731601=:47165-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 12:42:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26844 for ; Mon, 7 Apr 2003 12:42:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37GkQJ26517 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 12:46:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GG4823746; Mon, 7 Apr 2003 12:16:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37G8x823344 for ; Mon, 7 Apr 2003 12:08:59 -0400 Received: from web41806.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24645 for ; Mon, 7 Apr 2003 12:04:11 -0400 (EDT) Message-ID: <20030407160641.47395.qmail@web41806.mail.yahoo.com> Received: from [65.213.193.49] by web41806.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:06:41 PDT From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1705966920-1049731601=:47165" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 09:06:41 -0700 (PDT) --0-1705966920-1049731601=:47165 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-1705966920-1049731601=:47165 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-1705966920-1049731601=:47165-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 15:11:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01996 for ; Mon, 7 Apr 2003 15:11:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IkF802632; Mon, 7 Apr 2003 14:46:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Iec802461 for ; Mon, 7 Apr 2003 14:40:38 -0400 Received: from keskus.tct.hut.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00195 for ; Mon, 7 Apr 2003 14:35:47 -0400 (EDT) Received: from keskus.tct.hut.fi (localhost [127.0.0.1]) by keskus.tct.hut.fi (8.12.8/8.12.8) with ESMTP id h37IcIgf025357 for ; Mon, 7 Apr 2003 21:38:18 +0300 (EET DST) Received: from localhost (wzhou@localhost) by keskus.tct.hut.fi (8.12.8/8.12.8/Submit) with ESMTP id h37IcIAL025354 for ; Mon, 7 Apr 2003 21:38:18 +0300 (EET DST) X-Authentication-Warning: keskus.tct.hut.fi: wzhou owned process doing -bs From: Wenpeng Zhou X-X-Sender: To: Subject: what questions can be discussed here? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 21:38:17 +0300 (EET DST) Hi, I am novice to this discusssion forum, What kind of questions can be discussed here? For real-time traffic, for instance, voice in networks, Can we use RED or methods similar to RED to prevent congestion? Wenpeng _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 15:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02106 for ; Mon, 7 Apr 2003 15:12:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37JGYV04778 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 15:16:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IkF802632; Mon, 7 Apr 2003 14:46:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Iec802461 for ; Mon, 7 Apr 2003 14:40:38 -0400 Received: from keskus.tct.hut.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00195 for ; Mon, 7 Apr 2003 14:35:47 -0400 (EDT) Received: from keskus.tct.hut.fi (localhost [127.0.0.1]) by keskus.tct.hut.fi (8.12.8/8.12.8) with ESMTP id h37IcIgf025357 for ; Mon, 7 Apr 2003 21:38:18 +0300 (EET DST) Received: from localhost (wzhou@localhost) by keskus.tct.hut.fi (8.12.8/8.12.8/Submit) with ESMTP id h37IcIAL025354 for ; Mon, 7 Apr 2003 21:38:18 +0300 (EET DST) X-Authentication-Warning: keskus.tct.hut.fi: wzhou owned process doing -bs From: Wenpeng Zhou X-X-Sender: To: Subject: what questions can be discussed here? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 21:38:17 +0300 (EET DST) Hi, I am novice to this discusssion forum, What kind of questions can be discussed here? For real-time traffic, for instance, voice in networks, Can we use RED or methods similar to RED to prevent congestion? Wenpeng _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 16:34:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05244 for ; Mon, 7 Apr 2003 16:34:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KEV809385; Mon, 7 Apr 2003 16:14:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37K83809129 for ; Mon, 7 Apr 2003 16:08:03 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04545 for ; Mon, 7 Apr 2003 16:03:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 192cs8-00064g-00; Mon, 07 Apr 2003 13:05:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <179141534105.20030407130415@psg.com> To: Wenpeng Zhou CC: routing-discussion@ietf.org Subject: Re: what questions can be discussed here? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 13:04:15 -0700 Content-Transfer-Encoding: 7bit Wenpeng, This mailing list is for technical discussions that are within the scope of IETF Routing Area (i.e., IP routing), as well as non-technical ones concerning the Routing Area itself. Questions specific to particular routing protocols are usually discussed on the mailing lists of corresponding Working Groups. We're pretty tolerant to slight off-topics as long as people do not abuse the list. Your particular question will probably fit better in the TSV area, I'd try the TSVWG: http://www.ietf.org/html.charters/tsvwg-charter.html Regards -- Alex http://www.psg.com/~zinin/ Monday, April 7, 2003, 11:38:17 AM, Wenpeng Zhou wrote: > Hi, > I am novice to this discusssion forum, What kind of questions can be > discussed here? > For real-time traffic, for instance, voice in networks, Can we use RED > or methods similar to RED to prevent congestion? > Wenpeng > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 16:35:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05291 for ; Mon, 7 Apr 2003 16:35:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37KduD11396 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 16:39:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KEV809385; Mon, 7 Apr 2003 16:14:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37K83809129 for ; Mon, 7 Apr 2003 16:08:03 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04545 for ; Mon, 7 Apr 2003 16:03:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 192cs8-00064g-00; Mon, 07 Apr 2003 13:05:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <179141534105.20030407130415@psg.com> To: Wenpeng Zhou CC: routing-discussion@ietf.org Subject: Re: what questions can be discussed here? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 13:04:15 -0700 Content-Transfer-Encoding: 7bit Wenpeng, This mailing list is for technical discussions that are within the scope of IETF Routing Area (i.e., IP routing), as well as non-technical ones concerning the Routing Area itself. Questions specific to particular routing protocols are usually discussed on the mailing lists of corresponding Working Groups. We're pretty tolerant to slight off-topics as long as people do not abuse the list. Your particular question will probably fit better in the TSV area, I'd try the TSVWG: http://www.ietf.org/html.charters/tsvwg-charter.html Regards -- Alex http://www.psg.com/~zinin/ Monday, April 7, 2003, 11:38:17 AM, Wenpeng Zhou wrote: > Hi, > I am novice to this discusssion forum, What kind of questions can be > discussed here? > For real-time traffic, for instance, voice in networks, Can we use RED > or methods similar to RED to prevent congestion? > Wenpeng > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 17:25:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06429 for ; Mon, 7 Apr 2003 17:25:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37L2I812861; Mon, 7 Apr 2003 17:02:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KxY812393 for ; Mon, 7 Apr 2003 16:59:34 -0400 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05747 for ; Mon, 7 Apr 2003 16:54:39 -0400 (EDT) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA92712; Mon, 7 Apr 2003 16:55:19 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200304072055.QAA92712@workhorse.fictitious.org> To: Wenpeng Zhou cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: what questions can be discussed here? In-reply-to: Your message of "Mon, 07 Apr 2003 21:38:17 +0300." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 16:55:19 -0400 In message , Wenpeng Zhou writes: > Hi, > I am novice to this discusssion forum, What kind of questions can be > discussed here? Newbie questions are not encouraged on any IETF list but tolerated. > For real-time traffic, for instance, voice in networks, Can we use RED > or methods similar to RED to prevent congestion? This is off topic for the routing area. Briefly - some real time encapsulations are congestion aware and reduce bandwidth of the encoding when loss is detected. In other cases where real time traffic is preferred over best effort, RED is introduced to reduce the demand of elastic traffic (ie TCP). For real time encodings that don't reduce bandwidth when loss is introduced by RED, adding a small amount of loss doesn't help. For more detail you'll have to go elsewhere. Try archives of int-serv and diff-serv mailing lists and the IRTF end2end-interest list. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 17:26:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06517 for ; Mon, 7 Apr 2003 17:26:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37LUpG14889 for routing-discussion-archive@odin.ietf.org; Mon, 7 Apr 2003 17:30:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37L2I812861; Mon, 7 Apr 2003 17:02:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KxY812393 for ; Mon, 7 Apr 2003 16:59:34 -0400 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05747 for ; Mon, 7 Apr 2003 16:54:39 -0400 (EDT) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA92712; Mon, 7 Apr 2003 16:55:19 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200304072055.QAA92712@workhorse.fictitious.org> To: Wenpeng Zhou cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: what questions can be discussed here? In-reply-to: Your message of "Mon, 07 Apr 2003 21:38:17 +0300." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 16:55:19 -0400 In message , Wenpeng Zhou writes: > Hi, > I am novice to this discusssion forum, What kind of questions can be > discussed here? Newbie questions are not encouraged on any IETF list but tolerated. > For real-time traffic, for instance, voice in networks, Can we use RED > or methods similar to RED to prevent congestion? This is off topic for the routing area. Briefly - some real time encapsulations are congestion aware and reduce bandwidth of the encoding when loss is detected. In other cases where real time traffic is preferred over best effort, RED is introduced to reduce the demand of elastic traffic (ie TCP). For real time encodings that don't reduce bandwidth when loss is introduced by RED, adding a small amount of loss doesn't help. For more detail you'll have to go elsewhere. Try archives of int-serv and diff-serv mailing lists and the IRTF end2end-interest list. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 23:55:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15955 for ; Mon, 7 Apr 2003 23:55:52 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383kO805910; Mon, 7 Apr 2003 23:46:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383gn805829 for ; Mon, 7 Apr 2003 23:42:49 -0400 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15640 for ; Mon, 7 Apr 2003 23:37:46 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HD000901A767Q@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:18 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HD0004IYA75ZT@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:18 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HD0007WRA73G9@mmp2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:17 +0900 (KST) From: Manav Bhatia Subject: Re: stateless and stateful To: Tulip Rasputin Cc: routing-discussion@ietf.org Reply-to: Manav Bhatia Message-id: <103a01c2fd80$3cc24100$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030407123044.10657.qmail@web20708.mail.yahoo.com> Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Apr 2003 09:07:51 +0530 Content-Transfer-Encoding: 7BIT Tulip, > Yeah .. i saw the slides. It doesnt seem to talk of > the graceful or non-graceful restarts at all. It > basically studies the effect of persistent route > flappings on OSPF. Right. > > Any way i could get hold of the actual paper? http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Regards, Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 7 23:56:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15980 for ; Mon, 7 Apr 2003 23:56:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38419e06422 for routing-discussion-archive@odin.ietf.org; Tue, 8 Apr 2003 00:01:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383kO805910; Mon, 7 Apr 2003 23:46:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383gn805829 for ; Mon, 7 Apr 2003 23:42:49 -0400 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15640 for ; Mon, 7 Apr 2003 23:37:46 -0400 (EDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HD000901A767Q@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:18 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HD0004IYA75ZT@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:18 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HD0007WRA73G9@mmp2.samsung.com> for routing-discussion@ietf.org; Tue, 08 Apr 2003 12:40:17 +0900 (KST) From: Manav Bhatia Subject: Re: stateless and stateful To: Tulip Rasputin Cc: routing-discussion@ietf.org Reply-to: Manav Bhatia Message-id: <103a01c2fd80$3cc24100$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030407123044.10657.qmail@web20708.mail.yahoo.com> Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Apr 2003 09:07:51 +0530 Content-Transfer-Encoding: 7BIT Tulip, > Yeah .. i saw the slides. It doesnt seem to talk of > the graceful or non-graceful restarts at all. It > basically studies the effect of persistent route > flappings on OSPF. Right. > > Any way i could get hold of the actual paper? http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Regards, Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 7 23:59:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16020 for ; Mon, 7 Apr 2003 23:59:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383rs806096; Mon, 7 Apr 2003 23:53:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383pL806020 for ; Mon, 7 Apr 2003 23:51:21 -0400 Received: from mail.melesat.net.id (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15773 for ; Mon, 7 Apr 2003 23:46:15 -0400 (EDT) Received: (qmail 3708 invoked by uid 505); 8 Apr 2003 10:34:34 +0700 Received: from rafdian@infokom.net by mail.melesat.net.id by uid 502 with qmail-scanner-b.27.tm (uvscan: v4.1.60/v4171. Clear:. Processed in 0.734558 secs); 08 Apr 2003 03:34:34 -0000 X-Qmail-Scanner-Mail-From: rafdian@infokom.net via mail.melesat.net.id X-Qmail-Scanner: b.27.tm (Clear:. Processed in 0.734558 secs) Received: from unknown (HELO RAFDIAN) (202.147.196.98) by 0 with SMTP; 8 Apr 2003 10:34:33 +0700 From: "Rafdian" To: "'Manav Bhatia'" , "'Tulip Rasputin'" Cc: Subject: RE: stateless and stateful Message-ID: <006501c2fd81$b9d863d0$8f08010a@RAFDIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <103a01c2fd80$3cc24100$b4036c6b@sisodomain.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 10:48:32 +0700 Content-Transfer-Encoding: 7bit Dear All, Would you help me please? I want to quit from routing-discussion@ietf.org mailing list, but I do not find the way to do it? Rgds, rafdian -----Original Message----- From: routing-discussion-admin@ietf.org [mailto:routing-discussion-admin@ietf.org] On Behalf Of Manav Bhatia Sent: Tuesday, April 08, 2003 10:38 AM To: Tulip Rasputin Cc: routing-discussion@ietf.org Subject: Re: stateless and stateful Tulip, > Yeah .. i saw the slides. It doesnt seem to talk of > the graceful or non-graceful restarts at all. It > basically studies the effect of persistent route > flappings on OSPF. Right. > > Any way i could get hold of the actual paper? http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Regards, Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 8 00:00:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16057 for ; Tue, 8 Apr 2003 00:00:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38455Z06535 for routing-discussion-archive@odin.ietf.org; Tue, 8 Apr 2003 00:05:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383rs806096; Mon, 7 Apr 2003 23:53:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h383pL806020 for ; Mon, 7 Apr 2003 23:51:21 -0400 Received: from mail.melesat.net.id (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15773 for ; Mon, 7 Apr 2003 23:46:15 -0400 (EDT) Received: (qmail 3708 invoked by uid 505); 8 Apr 2003 10:34:34 +0700 Received: from rafdian@infokom.net by mail.melesat.net.id by uid 502 with qmail-scanner-b.27.tm (uvscan: v4.1.60/v4171. Clear:. Processed in 0.734558 secs); 08 Apr 2003 03:34:34 -0000 X-Qmail-Scanner-Mail-From: rafdian@infokom.net via mail.melesat.net.id X-Qmail-Scanner: b.27.tm (Clear:. Processed in 0.734558 secs) Received: from unknown (HELO RAFDIAN) (202.147.196.98) by 0 with SMTP; 8 Apr 2003 10:34:33 +0700 From: "Rafdian" To: "'Manav Bhatia'" , "'Tulip Rasputin'" Cc: Subject: RE: stateless and stateful Message-ID: <006501c2fd81$b9d863d0$8f08010a@RAFDIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <103a01c2fd80$3cc24100$b4036c6b@sisodomain.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 10:48:32 +0700 Content-Transfer-Encoding: 7bit Dear All, Would you help me please? I want to quit from routing-discussion@ietf.org mailing list, but I do not find the way to do it? Rgds, rafdian -----Original Message----- From: routing-discussion-admin@ietf.org [mailto:routing-discussion-admin@ietf.org] On Behalf Of Manav Bhatia Sent: Tuesday, April 08, 2003 10:38 AM To: Tulip Rasputin Cc: routing-discussion@ietf.org Subject: Re: stateless and stateful Tulip, > Yeah .. i saw the slides. It doesnt seem to talk of > the graceful or non-graceful restarts at all. It > basically studies the effect of persistent route > flappings on OSPF. Right. > > Any way i could get hold of the actual paper? http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Regards, Manav _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Apr 8 00:12:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16187 for ; Tue, 8 Apr 2003 00:12:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38431806479; Tue, 8 Apr 2003 00:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3840a806398 for ; Tue, 8 Apr 2003 00:00:36 -0400 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15952 for ; Mon, 7 Apr 2003 23:55:33 -0400 (EDT) Received: from jersey.sghosh.org (bgp510508bgs.verona01.nj.comcast.net [68.38.20.121]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HD00057MB0ULK@mtaout09.icomcast.net> for routing-discussion@ietf.org; Mon, 07 Apr 2003 23:58:06 -0400 (EDT) Received: from calcutta.sghosh.org (calcutta.sghosh.org [192.168.0.5]) by jersey.sghosh.org (8.11.6/8.11.6) with ESMTP id h383w5O19789; Mon, 07 Apr 2003 23:58:05 -0400 Received: from localhost (sghosh@localhost) by calcutta.sghosh.org (8.11.6/8.11.6) with ESMTP id h383w5x26905; Mon, 07 Apr 2003 23:58:05 -0400 From: Subhendu Ghosh Subject: RE: stateless and stateful In-reply-to: <006501c2fd81$b9d863d0$8f08010a@RAFDIAN> To: Rafdian Cc: routing-discussion@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: calcutta.sghosh.org: sghosh owned process doing -bs Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 23:58:05 -0400 (EDT) Content-Transfer-Encoding: 7BIT Go to the url in either the footer or the header List-Unsubscribe: , On Tue, 8 Apr 2003, Rafdian wrote: > Dear All, > Would you help me please? I want to quit from > routing-discussion@ietf.org mailing list, but I do not find the way to > do it? > > Rgds, rafdian > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > -- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 8 00:12:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16204 for ; Tue, 8 Apr 2003 00:12:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h384HBP07662 for routing-discussion-archive@odin.ietf.org; Tue, 8 Apr 2003 00:17:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38431806479; Tue, 8 Apr 2003 00:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3840a806398 for ; Tue, 8 Apr 2003 00:00:36 -0400 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15952 for ; Mon, 7 Apr 2003 23:55:33 -0400 (EDT) Received: from jersey.sghosh.org (bgp510508bgs.verona01.nj.comcast.net [68.38.20.121]) by mtaout09.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HD00057MB0ULK@mtaout09.icomcast.net> for routing-discussion@ietf.org; Mon, 07 Apr 2003 23:58:06 -0400 (EDT) Received: from calcutta.sghosh.org (calcutta.sghosh.org [192.168.0.5]) by jersey.sghosh.org (8.11.6/8.11.6) with ESMTP id h383w5O19789; Mon, 07 Apr 2003 23:58:05 -0400 Received: from localhost (sghosh@localhost) by calcutta.sghosh.org (8.11.6/8.11.6) with ESMTP id h383w5x26905; Mon, 07 Apr 2003 23:58:05 -0400 From: Subhendu Ghosh Subject: RE: stateless and stateful In-reply-to: <006501c2fd81$b9d863d0$8f08010a@RAFDIAN> To: Rafdian Cc: routing-discussion@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: calcutta.sghosh.org: sghosh owned process doing -bs Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 23:58:05 -0400 (EDT) Content-Transfer-Encoding: 7BIT Go to the url in either the footer or the header List-Unsubscribe: , On Tue, 8 Apr 2003, Rafdian wrote: > Dear All, > Would you help me please? I want to quit from > routing-discussion@ietf.org mailing list, but I do not find the way to > do it? > > Rgds, rafdian > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > -- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Apr 8 00:58:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17024 for ; Tue, 8 Apr 2003 00:58:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384oo809566; Tue, 8 Apr 2003 00:50:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384lK809479 for ; Tue, 8 Apr 2003 00:47:20 -0400 Received: from mail.melesat.net.id (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16688 for ; Tue, 8 Apr 2003 00:42:15 -0400 (EDT) Received: (qmail 13590 invoked by uid 505); 8 Apr 2003 11:30:37 +0700 Received: from rafdian@infokom.net by mail.melesat.net.id by uid 502 with qmail-scanner-b.27.tm (uvscan: v4.1.60/v4171. Clear:. Processed in 0.350907 secs); 08 Apr 2003 04:30:37 -0000 X-Qmail-Scanner-Mail-From: rafdian@infokom.net via mail.melesat.net.id X-Qmail-Scanner: b.27.tm (Clear:. Processed in 0.350907 secs) Received: from unknown (HELO RAFDIAN) (202.147.196.98) by 0 with SMTP; 8 Apr 2003 11:30:36 +0700 From: "Rafdian" To: "'Subhendu Ghosh'" Cc: Subject: RE: stateless and stateful Message-ID: <006f01c2fd89$8ea39fb0$8f08010a@RAFDIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 11:44:36 +0700 Content-Transfer-Encoding: 7bit Dear Mr. Subhendu Ghosh, Thanks for the advise. I have followed it up and find error. The following is a detailed description of the problems. ***** unsubscribe >>>>> Usage: unsubscribe [] ***** Unsubscribe rafdian@infokom.net >>>>> You gave the wrong password. Unfortunately I don't know what is my password? Could you forward this enquery to the admin? Thanks in advance, rafdian -----Original Message----- From: Subhendu Ghosh [mailto:sghosh@sghosh.org] Sent: Tuesday, April 08, 2003 10:58 AM To: Rafdian Cc: routing-discussion@ietf.org Subject: RE: stateless and stateful Go to the url in either the footer or the header List-Unsubscribe: , On Tue, 8 Apr 2003, Rafdian wrote: > Dear All, > Would you help me please? I want to quit from > routing-discussion@ietf.org mailing list, but I do not find the way to > do it? > > Rgds, rafdian > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > -- --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 8 00:59:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17071 for ; Tue, 8 Apr 2003 00:59:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3853ZA09947 for routing-discussion-archive@odin.ietf.org; Tue, 8 Apr 2003 01:03:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384oo809566; Tue, 8 Apr 2003 00:50:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h384lK809479 for ; Tue, 8 Apr 2003 00:47:20 -0400 Received: from mail.melesat.net.id (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16688 for ; Tue, 8 Apr 2003 00:42:15 -0400 (EDT) Received: (qmail 13590 invoked by uid 505); 8 Apr 2003 11:30:37 +0700 Received: from rafdian@infokom.net by mail.melesat.net.id by uid 502 with qmail-scanner-b.27.tm (uvscan: v4.1.60/v4171. Clear:. Processed in 0.350907 secs); 08 Apr 2003 04:30:37 -0000 X-Qmail-Scanner-Mail-From: rafdian@infokom.net via mail.melesat.net.id X-Qmail-Scanner: b.27.tm (Clear:. Processed in 0.350907 secs) Received: from unknown (HELO RAFDIAN) (202.147.196.98) by 0 with SMTP; 8 Apr 2003 11:30:36 +0700 From: "Rafdian" To: "'Subhendu Ghosh'" Cc: Subject: RE: stateless and stateful Message-ID: <006f01c2fd89$8ea39fb0$8f08010a@RAFDIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 11:44:36 +0700 Content-Transfer-Encoding: 7bit Dear Mr. Subhendu Ghosh, Thanks for the advise. I have followed it up and find error. The following is a detailed description of the problems. ***** unsubscribe >>>>> Usage: unsubscribe [] ***** Unsubscribe rafdian@infokom.net >>>>> You gave the wrong password. Unfortunately I don't know what is my password? Could you forward this enquery to the admin? Thanks in advance, rafdian -----Original Message----- From: Subhendu Ghosh [mailto:sghosh@sghosh.org] Sent: Tuesday, April 08, 2003 10:58 AM To: Rafdian Cc: routing-discussion@ietf.org Subject: RE: stateless and stateful Go to the url in either the footer or the header List-Unsubscribe: , On Tue, 8 Apr 2003, Rafdian wrote: > Dear All, > Would you help me please? I want to quit from > routing-discussion@ietf.org mailing list, but I do not find the way to > do it? > > Rgds, rafdian > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > -- --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 10 04:16:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11499 for ; Thu, 10 Apr 2003 04:16:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A834818609; Thu, 10 Apr 2003 04:03:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7up818077 for ; Thu, 10 Apr 2003 03:56:51 -0400 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10882 for ; Thu, 10 Apr 2003 03:50:45 -0400 (EDT) Received: (qmail 2692 invoked by uid 510); 10 Apr 2003 07:50:55 -0000 Message-ID: <20030410075055.2691.qmail@webmail36.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 10 apr 2003 07:50:55 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Subject: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Apr 2003 07:50:55 -0000 Hello, Is there any draft or RFC available for multicast reliability in LAN? I have an multicast application which needs an reliable mechanism to send packets, so that other member in the group receive the packet without any packet loss. thanks, -karthik. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 10 04:17:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11536 for ; Thu, 10 Apr 2003 04:17:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A8Mcv20329 for routing-discussion-archive@odin.ietf.org; Thu, 10 Apr 2003 04:22:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A834818609; Thu, 10 Apr 2003 04:03:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7up818077 for ; Thu, 10 Apr 2003 03:56:51 -0400 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10882 for ; Thu, 10 Apr 2003 03:50:45 -0400 (EDT) Received: (qmail 2692 invoked by uid 510); 10 Apr 2003 07:50:55 -0000 Message-ID: <20030410075055.2691.qmail@webmail36.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 10 apr 2003 07:50:55 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Subject: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 10 Apr 2003 07:50:55 -0000 Hello, Is there any draft or RFC available for multicast reliability in LAN? I have an multicast application which needs an reliable mechanism to send packets, so that other member in the group receive the packet without any packet loss. thanks, -karthik. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 10 08:18:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17140 for ; Thu, 10 Apr 2003 08:18:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AC0q803139; Thu, 10 Apr 2003 08:00:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ABvY803023 for ; Thu, 10 Apr 2003 07:57:34 -0400 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15842 for ; Thu, 10 Apr 2003 07:51:22 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3ABrsu39237; Thu, 10 Apr 2003 04:53:54 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200304101153.h3ABrsu39237@merlot.juniper.net> To: "Karthikeyan Subramaniam" cc: routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: Reliability in LAN In-Reply-To: Message from "Karthikeyan Subramaniam" of "10 Apr 2003 07:50:55 -0000." <20030410075055.2691.qmail@webmail36.rediffmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12286.1049975634.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 04:53:54 -0700 There are several reliable IP multicast protocols that will do this. See http://www.ietf.org/html.charters/rmt-charter.html Tom In message <20030410075055.2691.qmail@webmail36.rediffmail.com> you write: >Hello, > > Is there any draft or RFC available for multicast reliability >in LAN? >I have an multicast application which needs an reliable mechanism >to send packets, so that other member in the group receive the >packet without any packet loss. > >thanks, >-karthik. > > > >_______________________________________________________________________ >Odomos - the only mosquito protection outside 4 walls - >Click here to know more! >http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 10 08:19:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17161 for ; Thu, 10 Apr 2003 08:19:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ACOvf05203 for routing-discussion-archive@odin.ietf.org; Thu, 10 Apr 2003 08:24:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AC0q803139; Thu, 10 Apr 2003 08:00:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ABvY803023 for ; Thu, 10 Apr 2003 07:57:34 -0400 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15842 for ; Thu, 10 Apr 2003 07:51:22 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3ABrsu39237; Thu, 10 Apr 2003 04:53:54 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200304101153.h3ABrsu39237@merlot.juniper.net> To: "Karthikeyan Subramaniam" cc: routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: Reliability in LAN In-Reply-To: Message from "Karthikeyan Subramaniam" of "10 Apr 2003 07:50:55 -0000." <20030410075055.2691.qmail@webmail36.rediffmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12286.1049975634.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 04:53:54 -0700 There are several reliable IP multicast protocols that will do this. See http://www.ietf.org/html.charters/rmt-charter.html Tom In message <20030410075055.2691.qmail@webmail36.rediffmail.com> you write: >Hello, > > Is there any draft or RFC available for multicast reliability >in LAN? >I have an multicast application which needs an reliable mechanism >to send packets, so that other member in the group receive the >packet without any packet loss. > >thanks, >-karthik. > > > >_______________________________________________________________________ >Odomos - the only mosquito protection outside 4 walls - >Click here to know more! >http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 10 13:56:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28201 for ; Thu, 10 Apr 2003 13:56:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHlG830296; Thu, 10 Apr 2003 13:47:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHh3830136 for ; Thu, 10 Apr 2003 13:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27611 for ; Thu, 10 Apr 2003 13:36:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fia-0002zl-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:20:08 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 193fiZ-0002zi-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:20:07 -0400 Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA11861; Thu, 10 Apr 2003 10:39:18 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id KAA04751; Thu, 10 Apr 2003 10:39:17 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3AHdGf17443; Thu, 10 Apr 2003 10:39:16 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Apr 2003 13:39:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcL/N0SitNmiUp6/RLG6X8J7PS9S5AAUGMIw From: "Manfredi, Albert E" To: "Karthikeyan Subramaniam" , X-OriginalArrivalTime: 10 Apr 2003 17:39:09.0951 (UTC) FILETIME=[17C978F0:01C2FF88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AHh3830137 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 13:39:09 -0400 Content-Transfer-Encoding: 8bit Yes. See RFCs 2357, 2887, and 3048. In short, you have to build the reliability mechanisms on top of UPD/IP. These sometimes mimick what had been done in XTP multicast years ago. Bert > -----Original Message----- > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > Sent: Thursday, April 10, 2003 3:51 AM > To: routing-discussion@ietf.org > Subject: Reliability in LAN > > > Hello, > > Is there any draft or RFC available for multicast reliability > in LAN? > I have an multicast application which needs an reliable mechanism > to send packets, so that other member in the group receive the > packet without any packet loss. > > thanks, > -karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 10 13:57:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28293 for ; Thu, 10 Apr 2003 13:57:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AI31331390 for routing-discussion-archive@odin.ietf.org; Thu, 10 Apr 2003 14:03:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHlG830296; Thu, 10 Apr 2003 13:47:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHh3830136 for ; Thu, 10 Apr 2003 13:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27611 for ; Thu, 10 Apr 2003 13:36:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fia-0002zl-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:20:08 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 193fiZ-0002zi-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:20:07 -0400 Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA11861; Thu, 10 Apr 2003 10:39:18 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id KAA04751; Thu, 10 Apr 2003 10:39:17 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3AHdGf17443; Thu, 10 Apr 2003 10:39:16 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Apr 2003 13:39:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcL/N0SitNmiUp6/RLG6X8J7PS9S5AAUGMIw From: "Manfredi, Albert E" To: "Karthikeyan Subramaniam" , X-OriginalArrivalTime: 10 Apr 2003 17:39:09.0951 (UTC) FILETIME=[17C978F0:01C2FF88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AHh3830137 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 13:39:09 -0400 Content-Transfer-Encoding: 8bit Yes. See RFCs 2357, 2887, and 3048. In short, you have to build the reliability mechanisms on top of UPD/IP. These sometimes mimick what had been done in XTP multicast years ago. Bert > -----Original Message----- > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > Sent: Thursday, April 10, 2003 3:51 AM > To: routing-discussion@ietf.org > Subject: Reliability in LAN > > > Hello, > > Is there any draft or RFC available for multicast reliability > in LAN? > I have an multicast application which needs an reliable mechanism > to send packets, so that other member in the group receive the > packet without any packet loss. > > thanks, > -karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 10 15:06:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01688 for ; Thu, 10 Apr 2003 15:06:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIwT803576; Thu, 10 Apr 2003 14:58:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIoH803183 for ; Thu, 10 Apr 2003 14:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00348 for ; Thu, 10 Apr 2003 14:43:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gld-0003UD-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 14:27:21 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 193glc-0003UA-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 14:27:20 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11442; Thu, 10 Apr 2003 11:46:27 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA15414; Thu, 10 Apr 2003 11:46:25 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3AIkOw03694; Thu, 10 Apr 2003 13:46:24 -0500 (CDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Apr 2003 14:46:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcL/jN+9ZyRyPbfiTA2cZG7NsyBl0gAA4kHw From: "Manfredi, Albert E" To: "Michael Luby" , "Karthikeyan Subramaniam" , X-OriginalArrivalTime: 10 Apr 2003 18:46:23.0889 (UTC) FILETIME=[7C339010:01C2FF91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AIoH803184 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 14:46:23 -0400 Content-Transfer-Encoding: 8bit True, but these all rely on forward error correction. FEC is a good way to add reliability, but it doesn't create an "error-free" communications link, at least as "error-free" has been defined in the past. To be "error-free," you need some way of re-delivering packets which were not correctly received or not received at all. I agree that scalability is an issue. The more reliable and error-free you want to be, the more the scalability problems will bite. In many applications of IP multicast, e.g. streaming media, you of course don't have to have true error-free comms, so FEC or simply accepting the occasional screw-up is perfectly acceptable. Bert > -----Original Message----- > From: Michael Luby [mailto:luby@digitalfountain.com] > Sent: Thursday, April 10, 2003 2:15 PM > To: Manfredi, Albert E; Karthikeyan Subramaniam; > routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > provide a > direct solution to adding reliability to multicast without losing any > scalability. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > Manfredi, Albert > > E > > Sent: Thursday, April 10, 2003 10:39 AM > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > the reliability mechanisms on top of UPD/IP. These sometimes > > mimick what had been done in XTP multicast years ago. > > > > Bert > > > > > > > -----Original Message----- > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > Sent: Thursday, April 10, 2003 3:51 AM > > > To: routing-discussion@ietf.org > > > Subject: Reliability in LAN > > > > > > > > > Hello, > > > > > > Is there any draft or RFC available for multicast reliability > > > in LAN? > > > I have an multicast application which needs an reliable mechanism > > > to send packets, so that other member in the group receive the > > > packet without any packet loss. > > > > > > thanks, > > > -karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 10 15:07:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01772 for ; Thu, 10 Apr 2003 15:07:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AJCox05140 for routing-discussion-archive@odin.ietf.org; Thu, 10 Apr 2003 15:12:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIwT803576; Thu, 10 Apr 2003 14:58:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIoH803183 for ; Thu, 10 Apr 2003 14:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00348 for ; Thu, 10 Apr 2003 14:43:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gld-0003UD-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 14:27:21 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 193glc-0003UA-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 14:27:20 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11442; Thu, 10 Apr 2003 11:46:27 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA15414; Thu, 10 Apr 2003 11:46:25 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3AIkOw03694; Thu, 10 Apr 2003 13:46:24 -0500 (CDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Apr 2003 14:46:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcL/jN+9ZyRyPbfiTA2cZG7NsyBl0gAA4kHw From: "Manfredi, Albert E" To: "Michael Luby" , "Karthikeyan Subramaniam" , X-OriginalArrivalTime: 10 Apr 2003 18:46:23.0889 (UTC) FILETIME=[7C339010:01C2FF91] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AIoH803184 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 14:46:23 -0400 Content-Transfer-Encoding: 8bit True, but these all rely on forward error correction. FEC is a good way to add reliability, but it doesn't create an "error-free" communications link, at least as "error-free" has been defined in the past. To be "error-free," you need some way of re-delivering packets which were not correctly received or not received at all. I agree that scalability is an issue. The more reliable and error-free you want to be, the more the scalability problems will bite. In many applications of IP multicast, e.g. streaming media, you of course don't have to have true error-free comms, so FEC or simply accepting the occasional screw-up is perfectly acceptable. Bert > -----Original Message----- > From: Michael Luby [mailto:luby@digitalfountain.com] > Sent: Thursday, April 10, 2003 2:15 PM > To: Manfredi, Albert E; Karthikeyan Subramaniam; > routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > provide a > direct solution to adding reliability to multicast without losing any > scalability. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > Manfredi, Albert > > E > > Sent: Thursday, April 10, 2003 10:39 AM > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > the reliability mechanisms on top of UPD/IP. These sometimes > > mimick what had been done in XTP multicast years ago. > > > > Bert > > > > > > > -----Original Message----- > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > Sent: Thursday, April 10, 2003 3:51 AM > > > To: routing-discussion@ietf.org > > > Subject: Reliability in LAN > > > > > > > > > Hello, > > > > > > Is there any draft or RFC available for multicast reliability > > > in LAN? > > > I have an multicast application which needs an reliable mechanism > > > to send packets, so that other member in the group receive the > > > packet without any packet loss. > > > > > > thanks, > > > -karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 10 23:45:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16845 for ; Thu, 10 Apr 2003 23:45:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B3RV807994; Thu, 10 Apr 2003 23:27:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B3Nu807871 for ; Thu, 10 Apr 2003 23:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16488 for ; Thu, 10 Apr 2003 23:17:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193omX-0006L1-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 23:00:49 -0400 Received: from [203.199.83.145] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 193omW-0006Ky-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 23:00:48 -0400 Received: (qmail 6964 invoked by uid 510); 11 Apr 2003 03:18:16 -0000 Message-ID: <20030411031816.6963.qmail@webmail23.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 11 apr 2003 03:18:16 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: "Michael Luby" Cc: "Manfredi,Albert E" , routing-discussion@ietf.org Subject: Re: RE: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Apr 2003 03:18:16 -0000 My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without losing >any >scalability. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of >Manfredi, Albert > > E > > Sent: Thursday, April 10, 2003 10:39 AM > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to >build > > the reliability mechanisms on top of UPD/IP. These sometimes > > mimick what had been done in XTP multicast years ago. > > > > Bert > > > > > > > -----Original Message----- > > > From: Karthikeyan Subramaniam >[mailto:keyans@rediffmail.com] > > > Sent: Thursday, April 10, 2003 3:51 AM > > > To: routing-discussion@ietf.org > > > Subject: Reliability in LAN > > > > > > > > > Hello, > > > > > > Is there any draft or RFC available for multicast >reliability > > > in LAN? > > > I have an multicast application which needs an reliable >mechanism > > > to send packets, so that other member in the group receive >the > > > packet without any packet loss. > > > > > > thanks, > > > -karthik. > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 10 23:45:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16867 for ; Thu, 10 Apr 2003 23:45:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3B3prl09472 for routing-discussion-archive@odin.ietf.org; Thu, 10 Apr 2003 23:51:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B3RV807994; Thu, 10 Apr 2003 23:27:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B3Nu807871 for ; Thu, 10 Apr 2003 23:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16488 for ; Thu, 10 Apr 2003 23:17:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193omX-0006L1-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 23:00:49 -0400 Received: from [203.199.83.145] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 193omW-0006Ky-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 23:00:48 -0400 Received: (qmail 6964 invoked by uid 510); 11 Apr 2003 03:18:16 -0000 Message-ID: <20030411031816.6963.qmail@webmail23.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 11 apr 2003 03:18:16 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: "Michael Luby" Cc: "Manfredi,Albert E" , routing-discussion@ietf.org Subject: Re: RE: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 11 Apr 2003 03:18:16 -0000 My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without losing >any >scalability. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of >Manfredi, Albert > > E > > Sent: Thursday, April 10, 2003 10:39 AM > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to >build > > the reliability mechanisms on top of UPD/IP. These sometimes > > mimick what had been done in XTP multicast years ago. > > > > Bert > > > > > > > -----Original Message----- > > > From: Karthikeyan Subramaniam >[mailto:keyans@rediffmail.com] > > > Sent: Thursday, April 10, 2003 3:51 AM > > > To: routing-discussion@ietf.org > > > Subject: Reliability in LAN > > > > > > > > > Hello, > > > > > > Is there any draft or RFC available for multicast >reliability > > > in LAN? > > > I have an multicast application which needs an reliable >mechanism > > > to send packets, so that other member in the group receive >the > > > packet without any packet loss. > > > > > > thanks, > > > -karthik. > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Apr 11 06:34:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06174 for ; Fri, 11 Apr 2003 06:34:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BAJU812879; Fri, 11 Apr 2003 06:19:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BABw812565 for ; Fri, 11 Apr 2003 06:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05502 for ; Fri, 11 Apr 2003 06:05:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193v9G-0000f0-00 for routing-discussion@ietf.org; Fri, 11 Apr 2003 05:48:42 -0400 Received: from [61.135.128.152] (helo=web15107.mail.bjs.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 193v9F-0000ei-00 for routing-discussion@ietf.org; Fri, 11 Apr 2003 05:48:41 -0400 Message-ID: <20030411100716.56114.qmail@web15107.mail.bjs.yahoo.com> Received: from [218.0.212.123] by web15107.mail.bjs.yahoo.com via HTTP; Fri, 11 Apr 2003 18:07:16 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: RE: Reliability in LAN To: Karthikeyan Subramaniam , Michael Luby Cc: "Manfredi,Albert E" , routing-discussion@ietf.org In-Reply-To: <20030411031816.6963.qmail@webmail23.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1651562698-1050055636=:55729" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Apr 2003 18:07:16 +0800 (CST) --0-1651562698-1050055636=:55729 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1651562698-1050055636=:55729 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ).

If focusing on application layer QoS,  it could construct application layer multicast tree without consideration on underlying networks.

 

 Karthikeyan Subramaniam <keyans@rediffmail.com> wrote:


My requirements are reliability mechanism based on UDP/IP. I
have to optimise the packet transaction in the LAN using SACK and
NACK effectively. One more thing as I have to build reliability on
LAN, I need not follow hierarchial approach of data recovery
(Method used to avoid overloading the sender). Is there any RFC or
draft avaiable for reliable multicast mechanism based on these
requirements?

Thanks
karthik
On Thu, 10 Apr 2003 Michael Luby wrote :
>One could also look at RFCs 3450, 3451, 3452 and 3453. These
>provide a
>direct solution to adding reliability to multicast without losing
>any
>scalability.
>


Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1651562698-1050055636=:55729-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Apr 11 06:35:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06270 for ; Fri, 11 Apr 2003 06:35:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BAfPG14677 for routing-discussion-archive@odin.ietf.org; Fri, 11 Apr 2003 06:41:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BAJU812879; Fri, 11 Apr 2003 06:19:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BABw812565 for ; Fri, 11 Apr 2003 06:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05502 for ; Fri, 11 Apr 2003 06:05:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193v9G-0000f0-00 for routing-discussion@ietf.org; Fri, 11 Apr 2003 05:48:42 -0400 Received: from [61.135.128.152] (helo=web15107.mail.bjs.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 193v9F-0000ei-00 for routing-discussion@ietf.org; Fri, 11 Apr 2003 05:48:41 -0400 Message-ID: <20030411100716.56114.qmail@web15107.mail.bjs.yahoo.com> Received: from [218.0.212.123] by web15107.mail.bjs.yahoo.com via HTTP; Fri, 11 Apr 2003 18:07:16 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: RE: Reliability in LAN To: Karthikeyan Subramaniam , Michael Luby Cc: "Manfredi,Albert E" , routing-discussion@ietf.org In-Reply-To: <20030411031816.6963.qmail@webmail23.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1651562698-1050055636=:55729" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Apr 2003 18:07:16 +0800 (CST) --0-1651562698-1050055636=:55729 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1651562698-1050055636=:55729 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ).

If focusing on application layer QoS,  it could construct application layer multicast tree without consideration on underlying networks.

 

 Karthikeyan Subramaniam <keyans@rediffmail.com> wrote:


My requirements are reliability mechanism based on UDP/IP. I
have to optimise the packet transaction in the LAN using SACK and
NACK effectively. One more thing as I have to build reliability on
LAN, I need not follow hierarchial approach of data recovery
(Method used to avoid overloading the sender). Is there any RFC or
draft avaiable for reliable multicast mechanism based on these
requirements?

Thanks
karthik
On Thu, 10 Apr 2003 Michael Luby wrote :
>One could also look at RFCs 3450, 3451, 3452 and 3453. These
>provide a
>direct solution to adding reliability to multicast without losing
>any
>scalability.
>


Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1651562698-1050055636=:55729-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 14 19:51:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27255 for ; Mon, 14 Apr 2003 19:51:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENoB802237; Mon, 14 Apr 2003 19:50:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIHZ800760 for ; Thu, 10 Apr 2003 14:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28976 for ; Thu, 10 Apr 2003 14:11:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gFz-0003G4-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:54:39 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 193gFz-0003Fd-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:54:39 -0400 Received: (qmail 9089 invoked from network); 10 Apr 2003 18:13:16 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 10 Apr 2003 18:13:16 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3AID8Z1010730; Thu, 10 Apr 2003 11:13:08 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 11:15:21 -0700 Content-Transfer-Encoding: 7bit One could also look at RFCs 3450, 3451, 3452 and 3453. These provide a direct solution to adding reliability to multicast without losing any scalability. > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > E > Sent: Thursday, April 10, 2003 10:39 AM > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > the reliability mechanisms on top of UPD/IP. These sometimes > mimick what had been done in XTP multicast years ago. > > Bert > > > > -----Original Message----- > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > Sent: Thursday, April 10, 2003 3:51 AM > > To: routing-discussion@ietf.org > > Subject: Reliability in LAN > > > > > > Hello, > > > > Is there any draft or RFC available for multicast reliability > > in LAN? > > I have an multicast application which needs an reliable mechanism > > to send packets, so that other member in the group receive the > > packet without any packet loss. > > > > thanks, > > -karthik. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 14 19:52:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27279 for ; Mon, 14 Apr 2003 19:52:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ENxrv02872 for routing-discussion-archive@odin.ietf.org; Mon, 14 Apr 2003 19:59:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENoB802237; Mon, 14 Apr 2003 19:50:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIHZ800760 for ; Thu, 10 Apr 2003 14:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28976 for ; Thu, 10 Apr 2003 14:11:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gFz-0003G4-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:54:39 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 193gFz-0003Fd-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 13:54:39 -0400 Received: (qmail 9089 invoked from network); 10 Apr 2003 18:13:16 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 10 Apr 2003 18:13:16 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3AID8Z1010730; Thu, 10 Apr 2003 11:13:08 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 11:15:21 -0700 Content-Transfer-Encoding: 7bit One could also look at RFCs 3450, 3451, 3452 and 3453. These provide a direct solution to adding reliability to multicast without losing any scalability. > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > E > Sent: Thursday, April 10, 2003 10:39 AM > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > the reliability mechanisms on top of UPD/IP. These sometimes > mimick what had been done in XTP multicast years ago. > > Bert > > > > -----Original Message----- > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > Sent: Thursday, April 10, 2003 3:51 AM > > To: routing-discussion@ietf.org > > Subject: Reliability in LAN > > > > > > Hello, > > > > Is there any draft or RFC available for multicast reliability > > in LAN? > > I have an multicast application which needs an reliable mechanism > > to send packets, so that other member in the group receive the > > packet without any packet loss. > > > > thanks, > > -karthik. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Apr 14 19:57:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27372 for ; Mon, 14 Apr 2003 19:57:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENqR802346; Mon, 14 Apr 2003 19:52:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ANed825754 for ; Thu, 10 Apr 2003 19:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12037 for ; Thu, 10 Apr 2003 19:34:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lIX-0005K3-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 19:17:37 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 193lIW-0005Jv-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 19:17:36 -0400 Received: (qmail 12360 invoked from network); 10 Apr 2003 23:36:14 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 10 Apr 2003 23:36:14 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3ANa6Z1019373; Thu, 10 Apr 2003 16:36:06 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 16:35:52 -0700 Content-Transfer-Encoding: 7bit The approach in these RFCs is to use FEC beyond what you are imagining: when delivering data reliably you keep sending FEC packets until enough have arrived to recreate the data, and thus there is no need ever to redeliver lost packets or incorrectly received packets, you just receive some more and stop receiving when you have enough, where enough is the length of the original data. This essentially does create a virtual error-free communications link with maximum bandwidth utilization, even if the actual communications link is not error-free and does lose and/or corrupt packets. For streaming applications there are also benefits to using FEC, but this is outside the scope of these RFCs. Mike > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, April 10, 2003 11:46 AM > To: Michael Luby; Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > True, but these all rely on forward error correction. FEC is a > good way to add reliability, but it doesn't create an > "error-free" communications link, at least as "error-free" has > been defined in the past. To be "error-free," you need some way > of re-delivering packets which were not correctly received or not > received at all. > > I agree that scalability is an issue. The more reliable and > error-free you want to be, the more the scalability problems will bite. > > In many applications of IP multicast, e.g. streaming media, you > of course don't have to have true error-free comms, so FEC or > simply accepting the occasional screw-up is perfectly acceptable. > > Bert > > > > -----Original Message----- > > From: Michael Luby [mailto:luby@digitalfountain.com] > > Sent: Thursday, April 10, 2003 2:15 PM > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > provide a > > direct solution to adding reliability to multicast without losing any > > scalability. > > > > > -----Original Message----- > > > From: routing-discussion-admin@ietf.org > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > Manfredi, Albert > > > E > > > Sent: Thursday, April 10, 2003 10:39 AM > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > mimick what had been done in XTP multicast years ago. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > To: routing-discussion@ietf.org > > > > Subject: Reliability in LAN > > > > > > > > > > > > Hello, > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > in LAN? > > > > I have an multicast application which needs an reliable mechanism > > > > to send packets, so that other member in the group receive the > > > > packet without any packet loss. > > > > > > > > thanks, > > > > -karthik. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Apr 14 19:58:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27400 for ; Mon, 14 Apr 2003 19:58:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F06QJ03096 for routing-discussion-archive@odin.ietf.org; Mon, 14 Apr 2003 20:06:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENqR802346; Mon, 14 Apr 2003 19:52:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ANed825754 for ; Thu, 10 Apr 2003 19:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12037 for ; Thu, 10 Apr 2003 19:34:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lIX-0005K3-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 19:17:37 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 193lIW-0005Jv-00 for routing-discussion@ietf.org; Thu, 10 Apr 2003 19:17:36 -0400 Received: (qmail 12360 invoked from network); 10 Apr 2003 23:36:14 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 10 Apr 2003 23:36:14 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3ANa6Z1019373; Thu, 10 Apr 2003 16:36:06 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 16:35:52 -0700 Content-Transfer-Encoding: 7bit The approach in these RFCs is to use FEC beyond what you are imagining: when delivering data reliably you keep sending FEC packets until enough have arrived to recreate the data, and thus there is no need ever to redeliver lost packets or incorrectly received packets, you just receive some more and stop receiving when you have enough, where enough is the length of the original data. This essentially does create a virtual error-free communications link with maximum bandwidth utilization, even if the actual communications link is not error-free and does lose and/or corrupt packets. For streaming applications there are also benefits to using FEC, but this is outside the scope of these RFCs. Mike > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Thursday, April 10, 2003 11:46 AM > To: Michael Luby; Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > True, but these all rely on forward error correction. FEC is a > good way to add reliability, but it doesn't create an > "error-free" communications link, at least as "error-free" has > been defined in the past. To be "error-free," you need some way > of re-delivering packets which were not correctly received or not > received at all. > > I agree that scalability is an issue. The more reliable and > error-free you want to be, the more the scalability problems will bite. > > In many applications of IP multicast, e.g. streaming media, you > of course don't have to have true error-free comms, so FEC or > simply accepting the occasional screw-up is perfectly acceptable. > > Bert > > > > -----Original Message----- > > From: Michael Luby [mailto:luby@digitalfountain.com] > > Sent: Thursday, April 10, 2003 2:15 PM > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > provide a > > direct solution to adding reliability to multicast without losing any > > scalability. > > > > > -----Original Message----- > > > From: routing-discussion-admin@ietf.org > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > Manfredi, Albert > > > E > > > Sent: Thursday, April 10, 2003 10:39 AM > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > mimick what had been done in XTP multicast years ago. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > To: routing-discussion@ietf.org > > > > Subject: Reliability in LAN > > > > > > > > > > > > Hello, > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > in LAN? > > > > I have an multicast application which needs an reliable mechanism > > > > to send packets, so that other member in the group receive the > > > > packet without any packet loss. > > > > > > > > thanks, > > > > -karthik. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Apr 15 02:59:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17443 for ; Tue, 15 Apr 2003 02:59:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6xG808285; Tue, 15 Apr 2003 02:59:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6u0808171 for ; Tue, 15 Apr 2003 02:56:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16966 for ; Tue, 15 Apr 2003 02:47:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195KGX-0000VI-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 02:50:01 -0400 Received: from [203.199.83.245] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 195KGW-0000VE-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 02:50:00 -0400 Received: (qmail 27807 invoked by uid 510); 15 Apr 2003 06:47:54 -0000 Message-ID: <20030415064754.27806.qmail@mailweb33.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 15 apr 2003 06:47:54 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Cc: jshen_cad@yahoo.com.cn, luby@digitalfountain.com, albert.e.manfredi@boeing.com Subject: Re: Re: RE: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Apr 2003 06:47:54 -0000 Yes, my requirement can be considered as a simplified model of reliable multicast with only one hop. The requirement is to build generic reliable layer which any application can use to send data. Is there any RFC/draft designed for this? -karthik. I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without >losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 15 03:00:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17487 for ; Tue, 15 Apr 2003 03:00:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F78aM09785 for routing-discussion-archive@odin.ietf.org; Tue, 15 Apr 2003 03:08:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6xG808285; Tue, 15 Apr 2003 02:59:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F6u0808171 for ; Tue, 15 Apr 2003 02:56:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16966 for ; Tue, 15 Apr 2003 02:47:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195KGX-0000VI-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 02:50:01 -0400 Received: from [203.199.83.245] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 195KGW-0000VE-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 02:50:00 -0400 Received: (qmail 27807 invoked by uid 510); 15 Apr 2003 06:47:54 -0000 Message-ID: <20030415064754.27806.qmail@mailweb33.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 15 apr 2003 06:47:54 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Cc: jshen_cad@yahoo.com.cn, luby@digitalfountain.com, albert.e.manfredi@boeing.com Subject: Re: Re: RE: Reliability in LAN Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 15 Apr 2003 06:47:54 -0000 Yes, my requirement can be considered as a simplified model of reliable multicast with only one hop. The requirement is to build generic reliable layer which any application can use to send data. Is there any RFC/draft designed for this? -karthik. I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without >losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Apr 15 09:54:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27515 for ; Tue, 15 Apr 2003 09:54:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDjT804634; Tue, 15 Apr 2003 09:45:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDgZ804536 for ; Tue, 15 Apr 2003 09:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27091 for ; Tue, 15 Apr 2003 09:33:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Qbs-0002bG-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 09:36:28 -0400 Received: from web15209.mail.bjs.yahoo.com ([202.3.77.139]) by ietf-mx with smtp (Exim 4.12) id 195Qbp-0002aW-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 09:36:26 -0400 Message-ID: <20030415133441.18578.qmail@web15209.mail.bjs.yahoo.com> Received: from [61.174.154.4] by web15209.mail.bjs.yahoo.com via HTTP; Tue, 15 Apr 2003 21:34:41 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: Reliability in LAN To: Karthikeyan Subramaniam , routing-discussion@ietf.org Cc: jshen_cad@yahoo.com.cn, luby@digitalfountain.com, albert.e.manfredi@boeing.com In-Reply-To: <20030415064754.27806.qmail@mailweb33.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1162567087-1050413681=:18122" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Apr 2003 21:34:41 +0800 (CST) --0-1162567087-1050413681=:18122 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I don't know any RFC on this. Maybe following work could do some help: http://www.cs.umd.edu/users/suman/pubs/sigcomm02.pdf http://www.euronetlab.com/seminar/seminar-templemore-LIP6.pdf Karthikeyan Subramaniam wrote: Yes, my requirement can be considered as a simplified model of reliable multicast with only one hop. The requirement is to build generic reliable layer which any application can use to send data. Is there any RFC/draft designed for this? -karthik. I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without >losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢ÑûÄã²ÎÓëCCTV-2¶Ô»°½ÚÄ¿µ÷²é£ºÒƶ¯¡¢ÁªÍ¨¡¢Áéͨ£¬ÒªËµ°®Äã²»ÈÝÒ× --0-1162567087-1050413681=:18122 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

I don't know any RFC on this. Maybe following work could do some

help:

http://www.cs.umd.edu/users/suman/pubs/sigcomm02.pdf

http://www.euronetlab.com/seminar/seminar-templemore-LIP6.pdf

 Karthikeyan Subramaniam <keyans@rediffmail.com> wrote:


Yes, my requirement can be considered as a simplified model of
reliable multicast with only one hop. The requirement is to build
generic reliable layer which any application can use to send
data.

Is there any RFC/draft designed for this?

-karthik.

I don't understand what's the difference between them, because
your condition could be considered as a simplified model of
reliable multicast with only one hop ( or maybe that covers a VLAN
).

If focusing on application layer QoS, it could construct
application layer multicast tree without consideration on
underlying networks.



Karthikeyan Subramaniam wrote:


My requirements are reliability mechanism based on UDP/IP. I
have to optimise the packet transaction in the LAN using SACK
and
NACK effectively. One more thing as I have ! to build reliability
on
LAN, I need not follow hierarchial approach of data recovery
(Method used to avoid overloading the sender). Is there any RFC
or
draft avaiable for reliable multicast mechanism based on these
requirements?

Thanks
karthik
On Thu, 10 Apr 2003 Michael Luby wrote :
>One could also look at RFCs 3450, 3451, 3452 and 3453. These
>provide a
>direct solution to adding reliability to multicast without
>losing
>any
>scalability.
>



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China







_______________________________________________________________________
Odomos - the only mosquito protection outside 4 walls -
Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn

_____________________________! __________________
routing-discussion mailing list
routing-discu ssion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion


Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢ÑûÄã²ÎÓëCCTV-2¶Ô»°½ÚÄ¿µ÷²é£ºÒƶ¯¡¢ÁªÍ¨¡¢Áéͨ£¬ÒªËµ°®Äã²»ÈÝÒ× --0-1162567087-1050413681=:18122-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Apr 15 09:54:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27536 for ; Tue, 15 Apr 2003 09:54:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FE35E05359 for routing-discussion-archive@odin.ietf.org; Tue, 15 Apr 2003 10:03:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDjT804634; Tue, 15 Apr 2003 09:45:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDgZ804536 for ; Tue, 15 Apr 2003 09:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27091 for ; Tue, 15 Apr 2003 09:33:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Qbs-0002bG-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 09:36:28 -0400 Received: from web15209.mail.bjs.yahoo.com ([202.3.77.139]) by ietf-mx with smtp (Exim 4.12) id 195Qbp-0002aW-00 for routing-discussion@ietf.org; Tue, 15 Apr 2003 09:36:26 -0400 Message-ID: <20030415133441.18578.qmail@web15209.mail.bjs.yahoo.com> Received: from [61.174.154.4] by web15209.mail.bjs.yahoo.com via HTTP; Tue, 15 Apr 2003 21:34:41 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: Reliability in LAN To: Karthikeyan Subramaniam , routing-discussion@ietf.org Cc: jshen_cad@yahoo.com.cn, luby@digitalfountain.com, albert.e.manfredi@boeing.com In-Reply-To: <20030415064754.27806.qmail@mailweb33.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1162567087-1050413681=:18122" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 15 Apr 2003 21:34:41 +0800 (CST) --0-1162567087-1050413681=:18122 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I don't know any RFC on this. Maybe following work could do some help: http://www.cs.umd.edu/users/suman/pubs/sigcomm02.pdf http://www.euronetlab.com/seminar/seminar-templemore-LIP6.pdf Karthikeyan Subramaniam wrote: Yes, my requirement can be considered as a simplified model of reliable multicast with only one hop. The requirement is to build generic reliable layer which any application can use to send data. Is there any RFC/draft designed for this? -karthik. I don't understand what's the difference between them, because your condition could be considered as a simplified model of reliable multicast with only one hop ( or maybe that covers a VLAN ). If focusing on application layer QoS, it could construct application layer multicast tree without consideration on underlying networks. Karthikeyan Subramaniam wrote: My requirements are reliability mechanism based on UDP/IP. I have to optimise the packet transaction in the LAN using SACK and NACK effectively. One more thing as I have to build reliability on LAN, I need not follow hierarchial approach of data recovery (Method used to avoid overloading the sender). Is there any RFC or draft avaiable for reliable multicast mechanism based on these requirements? Thanks karthik On Thu, 10 Apr 2003 Michael Luby wrote : >One could also look at RFCs 3450, 3451, 3452 and 3453. These >provide a >direct solution to adding reliability to multicast without >losing >any >scalability. > Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢ÑûÄã²ÎÓëCCTV-2¶Ô»°½ÚÄ¿µ÷²é£ºÒƶ¯¡¢ÁªÍ¨¡¢Áéͨ£¬ÒªËµ°®Äã²»ÈÝÒ× --0-1162567087-1050413681=:18122 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

I don't know any RFC on this. Maybe following work could do some

help:

http://www.cs.umd.edu/users/suman/pubs/sigcomm02.pdf

http://www.euronetlab.com/seminar/seminar-templemore-LIP6.pdf

 Karthikeyan Subramaniam <keyans@rediffmail.com> wrote:


Yes, my requirement can be considered as a simplified model of
reliable multicast with only one hop. The requirement is to build
generic reliable layer which any application can use to send
data.

Is there any RFC/draft designed for this?

-karthik.

I don't understand what's the difference between them, because
your condition could be considered as a simplified model of
reliable multicast with only one hop ( or maybe that covers a VLAN
).

If focusing on application layer QoS, it could construct
application layer multicast tree without consideration on
underlying networks.



Karthikeyan Subramaniam wrote:


My requirements are reliability mechanism based on UDP/IP. I
have to optimise the packet transaction in the LAN using SACK
and
NACK effectively. One more thing as I have ! to build reliability
on
LAN, I need not follow hierarchial approach of data recovery
(Method used to avoid overloading the sender). Is there any RFC
or
draft avaiable for reliable multicast mechanism based on these
requirements?

Thanks
karthik
On Thu, 10 Apr 2003 Michael Luby wrote :
>One could also look at RFCs 3450, 3451, 3452 and 3453. These
>provide a
>direct solution to adding reliability to multicast without
>losing
>any
>scalability.
>



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China







_______________________________________________________________________
Odomos - the only mosquito protection outside 4 walls -
Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn

_____________________________! __________________
routing-discussion mailing list
routing-discu ssion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion


Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢ÑûÄã²ÎÓëCCTV-2¶Ô»°½ÚÄ¿µ÷²é£ºÒƶ¯¡¢ÁªÍ¨¡¢Áéͨ£¬ÒªËµ°®Äã²»ÈÝÒ× --0-1162567087-1050413681=:18122-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Apr 16 09:58:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01435 for ; Wed, 16 Apr 2003 09:58:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDnC821984; Wed, 16 Apr 2003 09:49:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDjh821859 for ; Wed, 16 Apr 2003 09:45:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00811 for ; Wed, 16 Apr 2003 09:36:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195n7w-0001ZX-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 09:39:04 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 195n7w-0001ZT-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 09:39:04 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 195n1L-0006bz-00; Wed, 16 Apr 2003 14:32:15 +0100 Date: Wed, 16 Apr 2003 14:32:10 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: Michael Luby , Karthikeyan Subramaniam , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-133.1 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *195n1L-0006bz-00*vvsfocDn.g.* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > True, but these all rely on forward error correction. FEC is a good > way to add reliability, but it doesn't create an "error-free" > communications link, at least as "error-free" has been defined in > the past. To be "error-free," you need some way of re-delivering > packets which were not correctly received or not received at all. Thus, FEC does NOT add reliability. Perhaps it adds robustness... L. > > I agree that scalability is an issue. The more reliable and > error-free you want to be, the more the scalability problems will > bite. > > In many applications of IP multicast, e.g. streaming media, you of > course don't have to have true error-free comms, so FEC or simply > accepting the occasional screw-up is perfectly acceptable. > > Bert > > > > -----Original Message----- > > From: Michael Luby [mailto:luby@digitalfountain.com] > > Sent: Thursday, April 10, 2003 2:15 PM > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > provide a > > direct solution to adding reliability to multicast without losing any > > scalability. > > > > > -----Original Message----- > > > From: routing-discussion-admin@ietf.org > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > Manfredi, Albert > > > E > > > Sent: Thursday, April 10, 2003 10:39 AM > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > mimick what had been done in XTP multicast years ago. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > To: routing-discussion@ietf.org > > > > Subject: Reliability in LAN > > > > > > > > > > > > Hello, > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > in LAN? > > > > I have an multicast application which needs an reliable mechanism > > > > to send packets, so that other member in the group receive the > > > > packet without any packet loss. > > > > > > > > thanks, > > > > -karthik. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Apr 16 09:59:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01474 for ; Wed, 16 Apr 2003 09:59:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GE7rS23727 for routing-discussion-archive@odin.ietf.org; Wed, 16 Apr 2003 10:07:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDnC821984; Wed, 16 Apr 2003 09:49:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GDjh821859 for ; Wed, 16 Apr 2003 09:45:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00811 for ; Wed, 16 Apr 2003 09:36:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195n7w-0001ZX-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 09:39:04 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 195n7w-0001ZT-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 09:39:04 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 195n1L-0006bz-00; Wed, 16 Apr 2003 14:32:15 +0100 Date: Wed, 16 Apr 2003 14:32:10 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: Michael Luby , Karthikeyan Subramaniam , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-133.1 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *195n1L-0006bz-00*vvsfocDn.g.* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > True, but these all rely on forward error correction. FEC is a good > way to add reliability, but it doesn't create an "error-free" > communications link, at least as "error-free" has been defined in > the past. To be "error-free," you need some way of re-delivering > packets which were not correctly received or not received at all. Thus, FEC does NOT add reliability. Perhaps it adds robustness... L. > > I agree that scalability is an issue. The more reliable and > error-free you want to be, the more the scalability problems will > bite. > > In many applications of IP multicast, e.g. streaming media, you of > course don't have to have true error-free comms, so FEC or simply > accepting the occasional screw-up is perfectly acceptable. > > Bert > > > > -----Original Message----- > > From: Michael Luby [mailto:luby@digitalfountain.com] > > Sent: Thursday, April 10, 2003 2:15 PM > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > provide a > > direct solution to adding reliability to multicast without losing any > > scalability. > > > > > -----Original Message----- > > > From: routing-discussion-admin@ietf.org > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > Manfredi, Albert > > > E > > > Sent: Thursday, April 10, 2003 10:39 AM > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > mimick what had been done in XTP multicast years ago. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > To: routing-discussion@ietf.org > > > > Subject: Reliability in LAN > > > > > > > > > > > > Hello, > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > in LAN? > > > > I have an multicast application which needs an reliable mechanism > > > > to send packets, so that other member in the group receive the > > > > packet without any packet loss. > > > > > > > > thanks, > > > > -karthik. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 17 00:02:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25994 for ; Thu, 17 Apr 2003 00:02:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H430818155; Thu, 17 Apr 2003 00:03:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H3x4817984 for ; Wed, 16 Apr 2003 23:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25648 for ; Wed, 16 Apr 2003 23:49:38 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1960RU-0004zl-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 23:52:08 -0400 Received: from [203.199.83.247] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1960RT-0004zi-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 23:52:08 -0400 Received: (qmail 8321 invoked by uid 510); 17 Apr 2003 03:49:45 -0000 Message-ID: <20030417034945.8320.qmail@mailweb34.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 17 apr 2003 03:49:45 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Subject: OSPFv3 link local address in Routing table Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 17 Apr 2003 03:49:45 -0000 Hi, From the RFC it is clear that nexthop address should be the link local address of all other routers attached to its links. And also these addresses are used as nexthop information during packet forwarding. But I have a doubt in the following scenario. Router R1 is connected to Router R2 through Link L1. Router R2 is inturn connected to Router R3 through Link L2. Let us assume Router R1 originated Route 1 for area 1. Also assume R1->L1 link local address as A, R2->L1 link local address as B, R2->L2 link local address as C, R3->L2 link local address as D. All the routers are in Area 1 I want to know the nexthop information for Route1 in R3. Will the nexthop information will be A (Link local address)which originated the packet. If so, How Router 3 gets to know about the link information of Router 1 because link local address are not propagated beyond the link ?Otherwise, what will be nexthop information for Route1 does the Router3 will hold. thanks, karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 17 00:03:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26009 for ; Thu, 17 Apr 2003 00:03:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H4C3J19363 for routing-discussion-archive@odin.ietf.org; Thu, 17 Apr 2003 00:12:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H430818155; Thu, 17 Apr 2003 00:03:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H3x4817984 for ; Wed, 16 Apr 2003 23:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25648 for ; Wed, 16 Apr 2003 23:49:38 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1960RU-0004zl-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 23:52:08 -0400 Received: from [203.199.83.247] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1960RT-0004zi-00 for routing-discussion@ietf.org; Wed, 16 Apr 2003 23:52:08 -0400 Received: (qmail 8321 invoked by uid 510); 17 Apr 2003 03:49:45 -0000 Message-ID: <20030417034945.8320.qmail@mailweb34.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 17 apr 2003 03:49:45 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: routing-discussion@ietf.org Subject: OSPFv3 link local address in Routing table Content-type: text/plain; format=flowed Content-Disposition: inline Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 17 Apr 2003 03:49:45 -0000 Hi, From the RFC it is clear that nexthop address should be the link local address of all other routers attached to its links. And also these addresses are used as nexthop information during packet forwarding. But I have a doubt in the following scenario. Router R1 is connected to Router R2 through Link L1. Router R2 is inturn connected to Router R3 through Link L2. Let us assume Router R1 originated Route 1 for area 1. Also assume R1->L1 link local address as A, R2->L1 link local address as B, R2->L2 link local address as C, R3->L2 link local address as D. All the routers are in Area 1 I want to know the nexthop information for Route1 in R3. Will the nexthop information will be A (Link local address)which originated the packet. If so, How Router 3 gets to know about the link information of Router 1 because link local address are not propagated beyond the link ?Otherwise, what will be nexthop information for Route1 does the Router3 will hold. thanks, karthik. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 17 11:03:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24504 for ; Thu, 17 Apr 2003 11:03:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF3q809374; Thu, 17 Apr 2003 11:03:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF05809052 for ; Thu, 17 Apr 2003 11:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23995 for ; Thu, 17 Apr 2003 10:50:25 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Akv-0000TU-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 10:52:53 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 196Aku-0000TQ-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 10:52:52 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 196Akl-0007Sy-00; Thu, 17 Apr 2003 15:52:43 +0100 Date: Thu, 17 Apr 2003 15:52:35 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Michael Luby cc: "Manfredi, Albert E" , Karthikeyan Subramaniam , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-133.1 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *196Akl-0007Sy-00*cYacKFHDNe.* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, 16 Apr 2003, Michael Luby wrote: > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > > > True, but these all rely on forward error correction. FEC is a good > > > way to add reliability, but it doesn't create an "error-free" > > > communications link, at least as "error-free" has been defined in > > > the past. To be "error-free," you need some way of re-delivering > > > packets which were not correctly received or not received at all. > > > > Thus, FEC does NOT add reliability. > > I'd be curious to understand how your definition of reliability differs so > drastically from what is defined in the RMT working group charter and the > general working group RFCs, and in particular from what is in RFC 3453 and > RFC 3452 which show how FEC can provide reliability for data delivery. FEC reduces the probability of corruption leading to frame loss at the receiver. It cannot, by itself, provide reliability. (My view is in section 1.1 of RFC3366, which, unlike the RFCs you cite, is BCP.) The RMT charter correctly indicates that FEC is but one 'building block', and that use of FEC alone is open-loop. TCP is reliable; TCP is closed-loop. For me, reliability implies a closed loop with error handling/notification, and RFC 3452 and 3453 show no such thing. Basically, we've spent more time talking to wireless link designers about coding etc. I'm not convinced that FEC belongs up the stack, and I wouldn't call 'reliable' multicast using only FEC reliable either. 'less unreliable', perhaps; more robust, definitely. But still quite uncertain. L. > If you get a chance, it would be interesting if you read those 3-4 > RFCs so that you can clearly differentiate what you have in your > head in terms of what reliability means versus what is in these > docs. > > > Perhaps it adds robustness... > > > > L. > > > > > > > > I agree that scalability is an issue. The more reliable and > > > error-free you want to be, the more the scalability problems will > > > bite. > > > > > > In many applications of IP multicast, e.g. streaming media, you of > > > course don't have to have true error-free comms, so FEC or simply > > > accepting the occasional screw-up is perfectly acceptable. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > > Sent: Thursday, April 10, 2003 2:15 PM > > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > > routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > > provide a > > > > direct solution to adding reliability to multicast without losing any > > > > scalability. > > > > > > > > > -----Original Message----- > > > > > From: routing-discussion-admin@ietf.org > > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > > Manfredi, Albert > > > > > E > > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > > > Bert > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > > To: routing-discussion@ietf.org > > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > > > in LAN? > > > > > > I have an multicast application which needs an reliable mechanism > > > > > > to send packets, so that other member in the group receive the > > > > > > packet without any packet loss. > > > > > > > > > > > > thanks, > > > > > > -karthik. > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 17 11:04:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24535 for ; Thu, 17 Apr 2003 11:04:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HFDdv10689 for routing-discussion-archive@odin.ietf.org; Thu, 17 Apr 2003 11:13:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF3q809374; Thu, 17 Apr 2003 11:03:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF05809052 for ; Thu, 17 Apr 2003 11:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23995 for ; Thu, 17 Apr 2003 10:50:25 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Akv-0000TU-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 10:52:53 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 196Aku-0000TQ-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 10:52:52 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 196Akl-0007Sy-00; Thu, 17 Apr 2003 15:52:43 +0100 Date: Thu, 17 Apr 2003 15:52:35 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Michael Luby cc: "Manfredi, Albert E" , Karthikeyan Subramaniam , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-133.1 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *196Akl-0007Sy-00*cYacKFHDNe.* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, 16 Apr 2003, Michael Luby wrote: > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > > > True, but these all rely on forward error correction. FEC is a good > > > way to add reliability, but it doesn't create an "error-free" > > > communications link, at least as "error-free" has been defined in > > > the past. To be "error-free," you need some way of re-delivering > > > packets which were not correctly received or not received at all. > > > > Thus, FEC does NOT add reliability. > > I'd be curious to understand how your definition of reliability differs so > drastically from what is defined in the RMT working group charter and the > general working group RFCs, and in particular from what is in RFC 3453 and > RFC 3452 which show how FEC can provide reliability for data delivery. FEC reduces the probability of corruption leading to frame loss at the receiver. It cannot, by itself, provide reliability. (My view is in section 1.1 of RFC3366, which, unlike the RFCs you cite, is BCP.) The RMT charter correctly indicates that FEC is but one 'building block', and that use of FEC alone is open-loop. TCP is reliable; TCP is closed-loop. For me, reliability implies a closed loop with error handling/notification, and RFC 3452 and 3453 show no such thing. Basically, we've spent more time talking to wireless link designers about coding etc. I'm not convinced that FEC belongs up the stack, and I wouldn't call 'reliable' multicast using only FEC reliable either. 'less unreliable', perhaps; more robust, definitely. But still quite uncertain. L. > If you get a chance, it would be interesting if you read those 3-4 > RFCs so that you can clearly differentiate what you have in your > head in terms of what reliability means versus what is in these > docs. > > > Perhaps it adds robustness... > > > > L. > > > > > > > > I agree that scalability is an issue. The more reliable and > > > error-free you want to be, the more the scalability problems will > > > bite. > > > > > > In many applications of IP multicast, e.g. streaming media, you of > > > course don't have to have true error-free comms, so FEC or simply > > > accepting the occasional screw-up is perfectly acceptable. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > > Sent: Thursday, April 10, 2003 2:15 PM > > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > > routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > > provide a > > > > direct solution to adding reliability to multicast without losing any > > > > scalability. > > > > > > > > > -----Original Message----- > > > > > From: routing-discussion-admin@ietf.org > > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > > Manfredi, Albert > > > > > E > > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > > > Bert > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > > To: routing-discussion@ietf.org > > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > > > in LAN? > > > > > > I have an multicast application which needs an reliable mechanism > > > > > > to send packets, so that other member in the group receive the > > > > > > packet without any packet loss. > > > > > > > > > > > > thanks, > > > > > > -karthik. > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 17 15:13:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03644 for ; Thu, 17 Apr 2003 15:13:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HJCZ832296; Thu, 17 Apr 2003 15:12:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HJ9i832151 for ; Thu, 17 Apr 2003 15:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02427 for ; Thu, 17 Apr 2003 15:00:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196EeQ-00020X-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 15:02:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 196EeQ-00020U-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 15:02:26 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA16854; Thu, 17 Apr 2003 12:02:16 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA13927; Thu, 17 Apr 2003 12:02:35 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3HJ2Yf24317; Thu, 17 Apr 2003 12:02:34 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Apr 2003 14:59:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcMEm9EQtT0dIzAvRhqrWJv7DCocaAAdhc5w From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: X-OriginalArrivalTime: 17 Apr 2003 18:59:14.0745 (UTC) FILETIME=[708F1A90:01C30513] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HJ9i832152 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 14:59:14 -0400 Content-Transfer-Encoding: 8bit Guys, I think we are digressing into meaningless semantic nit-picking. Adding "reliability" simply means that information is correctly received MORE OFTEN. That certainly fits the mission statement of any form of forward error correction. The FEC can compensate for some degree of packet corruption, so without having to add any protocol complexity, the data packets are delivered error free more often. Not always, just more often. Being error-free means that the information is "always perfect," when received by the application. If it's screwed up, one of the ISO layers below the application layer fixes the problem. If the transfer occurs only once in a blue moon, then error free is a must, or you might simply miss the data packet entirely. If the information is transferred continuously and an occasional corrupted packet can be ignored, then FEC alone with UDP/IP is acceptable. I originally used streaming media as AN EXAMPLE of this type of transfer. Data can also fit this model, depending how the system is designed. Thus, FEC certainly DOES increase reliability. It just doesn't guarantee error-free reception of every packet. Bert > -----Original Message----- > From: Michael Luby [mailto:luby@digitalfountain.com] > Sent: Thursday, April 17, 2003 12:45 AM > To: Lloyd Wood; Manfredi, Albert E > Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > > -----Original Message----- > > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > Sent: Wednesday, April 16, 2003 6:32 AM > > To: Manfredi, Albert E > > Cc: Michael Luby; Karthikeyan Subramaniam; > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > > > True, but these all rely on forward error correction. FEC > is a good > > > way to add reliability, but it doesn't create an "error-free" > > > communications link, at least as "error-free" has been defined in > > > the past. To be "error-free," you need some way of re-delivering > > > packets which were not correctly received or not received at all. > > > > Thus, FEC does NOT add reliability. > > I'd be curious to understand how your definition of > reliability differs so > drastically from what is defined in the RMT working group > charter and the > general working group RFCs, and in particular from what is in > RFC 3453 and > RFC 3452 which show how FEC can provide reliability for data > delivery. If > you get a chance, it would be interesting if you read those > 3-4 RFCs so that > you can clearly differentiate what you have in your head in > terms of what > reliability means versus what is in these docs. > > > > > Perhaps it adds robustness... > > > > L. > > > > > > > > I agree that scalability is an issue. The more reliable and > > > error-free you want to be, the more the scalability problems will > > > bite. > > > > > > In many applications of IP multicast, e.g. streaming media, you of > > > course don't have to have true error-free comms, so FEC or simply > > > accepting the occasional screw-up is perfectly acceptable. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > > Sent: Thursday, April 10, 2003 2:15 PM > > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > > routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > > provide a > > > > direct solution to adding reliability to multicast > without losing any > > > > scalability. > > > > > > > > > -----Original Message----- > > > > > From: routing-discussion-admin@ietf.org > > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > > Manfredi, Albert > > > > > E > > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you > have to build > > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > > > Bert > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > > To: routing-discussion@ietf.org > > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > Is there any draft or RFC available for > multicast reliability > > > > > > in LAN? > > > > > > I have an multicast application which needs an > reliable mechanism > > > > > > to send packets, so that other member in the group > receive the > > > > > > packet without any packet loss. > > > > > > > > > > > > thanks, > > > > > > -karthik. > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > > > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 17 15:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03749 for ; Thu, 17 Apr 2003 15:13:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HJN1N32720 for routing-discussion-archive@odin.ietf.org; Thu, 17 Apr 2003 15:23:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HJCZ832296; Thu, 17 Apr 2003 15:12:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HJ9i832151 for ; Thu, 17 Apr 2003 15:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02427 for ; Thu, 17 Apr 2003 15:00:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196EeQ-00020X-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 15:02:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 196EeQ-00020U-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 15:02:26 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA16854; Thu, 17 Apr 2003 12:02:16 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA13927; Thu, 17 Apr 2003 12:02:35 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3HJ2Yf24317; Thu, 17 Apr 2003 12:02:34 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Apr 2003 14:59:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcMEm9EQtT0dIzAvRhqrWJv7DCocaAAdhc5w From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: X-OriginalArrivalTime: 17 Apr 2003 18:59:14.0745 (UTC) FILETIME=[708F1A90:01C30513] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HJ9i832152 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 14:59:14 -0400 Content-Transfer-Encoding: 8bit Guys, I think we are digressing into meaningless semantic nit-picking. Adding "reliability" simply means that information is correctly received MORE OFTEN. That certainly fits the mission statement of any form of forward error correction. The FEC can compensate for some degree of packet corruption, so without having to add any protocol complexity, the data packets are delivered error free more often. Not always, just more often. Being error-free means that the information is "always perfect," when received by the application. If it's screwed up, one of the ISO layers below the application layer fixes the problem. If the transfer occurs only once in a blue moon, then error free is a must, or you might simply miss the data packet entirely. If the information is transferred continuously and an occasional corrupted packet can be ignored, then FEC alone with UDP/IP is acceptable. I originally used streaming media as AN EXAMPLE of this type of transfer. Data can also fit this model, depending how the system is designed. Thus, FEC certainly DOES increase reliability. It just doesn't guarantee error-free reception of every packet. Bert > -----Original Message----- > From: Michael Luby [mailto:luby@digitalfountain.com] > Sent: Thursday, April 17, 2003 12:45 AM > To: Lloyd Wood; Manfredi, Albert E > Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > > -----Original Message----- > > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > Sent: Wednesday, April 16, 2003 6:32 AM > > To: Manfredi, Albert E > > Cc: Michael Luby; Karthikeyan Subramaniam; > routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > > > True, but these all rely on forward error correction. FEC > is a good > > > way to add reliability, but it doesn't create an "error-free" > > > communications link, at least as "error-free" has been defined in > > > the past. To be "error-free," you need some way of re-delivering > > > packets which were not correctly received or not received at all. > > > > Thus, FEC does NOT add reliability. > > I'd be curious to understand how your definition of > reliability differs so > drastically from what is defined in the RMT working group > charter and the > general working group RFCs, and in particular from what is in > RFC 3453 and > RFC 3452 which show how FEC can provide reliability for data > delivery. If > you get a chance, it would be interesting if you read those > 3-4 RFCs so that > you can clearly differentiate what you have in your head in > terms of what > reliability means versus what is in these docs. > > > > > Perhaps it adds robustness... > > > > L. > > > > > > > > I agree that scalability is an issue. The more reliable and > > > error-free you want to be, the more the scalability problems will > > > bite. > > > > > > In many applications of IP multicast, e.g. streaming media, you of > > > course don't have to have true error-free comms, so FEC or simply > > > accepting the occasional screw-up is perfectly acceptable. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > > Sent: Thursday, April 10, 2003 2:15 PM > > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > > routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > > provide a > > > > direct solution to adding reliability to multicast > without losing any > > > > scalability. > > > > > > > > > -----Original Message----- > > > > > From: routing-discussion-admin@ietf.org > > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > > Manfredi, Albert > > > > > E > > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you > have to build > > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > > > Bert > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > > To: routing-discussion@ietf.org > > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > Is there any draft or RFC available for > multicast reliability > > > > > > in LAN? > > > > > > I have an multicast application which needs an > reliable mechanism > > > > > > to send packets, so that other member in the group > receive the > > > > > > packet without any packet loss. > > > > > > > > > > > > thanks, > > > > > > -karthik. > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > > > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 17 16:20:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06228 for ; Thu, 17 Apr 2003 16:20:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKGI804386; Thu, 17 Apr 2003 16:16:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKBS804177 for ; Thu, 17 Apr 2003 16:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05627 for ; Thu, 17 Apr 2003 16:01:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Fc9-0002GO-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 16:04:09 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 196Fc9-0002GK-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 16:04:09 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3HK2ju47778; Thu, 17 Apr 2003 13:02:46 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200304172002.h3HK2ju47778@merlot.juniper.net> To: "Manfredi, Albert E" cc: "Lloyd Wood" , routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: Reliability in LAN In-Reply-To: Message from "Manfredi, Albert E" of "Thu, 17 Apr 2003 14:59:14 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98273.1050609765.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 13:02:45 -0700 I think Mike's point is being missed though. The algorithms he cites from RMT are more than simple FEC. They do provide error free delivery over time. By simply continuting to listen to the stream, the original data can be reproduced exactly everytime. You'll need to read the papers to see how this works. Tom In message you write: >Guys, > >I think we are digressing into meaningless semantic nit-picking. Adding "relia >bility" simply means that information is correctly received MORE OFTEN. That c >ertainly fits the mission statement of any form of forward error correction. T >he FEC can compensate for some degree of packet corruption, so without having >to add any protocol complexity, the data packets are delivered error free more > often. Not always, just more often. > >Being error-free means that the information is "always perfect," when received > by the application. If it's screwed up, one of the ISO layers below the appli >cation layer fixes the problem. > >If the transfer occurs only once in a blue moon, then error free is a must, or > you might simply miss the data packet entirely. If the information is transfe >rred continuously and an occasional corrupted packet can be ignored, then FEC >alone with UDP/IP is acceptable. > >I originally used streaming media as AN EXAMPLE of this type of transfer. Data > can also fit this model, depending how the system is designed. > >Thus, FEC certainly DOES increase reliability. It just doesn't guarantee error >-free reception of every packet. > >Bert > > >> -----Original Message----- >> From: Michael Luby [mailto:luby@digitalfountain.com] >> Sent: Thursday, April 17, 2003 12:45 AM >> To: Lloyd Wood; Manfredi, Albert E >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org >> Subject: RE: Reliability in LAN >> >> >> > -----Original Message----- >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >> > Sent: Wednesday, April 16, 2003 6:32 AM >> > To: Manfredi, Albert E >> > Cc: Michael Luby; Karthikeyan Subramaniam; >> routing-discussion@ietf.org >> > Subject: RE: Reliability in LAN >> > >> > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: >> > >> > > True, but these all rely on forward error correction. FEC >> is a good >> > > way to add reliability, but it doesn't create an "error-free" >> > > communications link, at least as "error-free" has been defined in >> > > the past. To be "error-free," you need some way of re-delivering >> > > packets which were not correctly received or not received at all. >> > >> > Thus, FEC does NOT add reliability. >> >> I'd be curious to understand how your definition of >> reliability differs so >> drastically from what is defined in the RMT working group >> charter and the >> general working group RFCs, and in particular from what is in >> RFC 3453 and >> RFC 3452 which show how FEC can provide reliability for data >> delivery. If >> you get a chance, it would be interesting if you read those >> 3-4 RFCs so that >> you can clearly differentiate what you have in your head in >> terms of what >> reliability means versus what is in these docs. >> >> > >> > Perhaps it adds robustness... >> > >> > L. >> > >> > > >> > > I agree that scalability is an issue. The more reliable and >> > > error-free you want to be, the more the scalability problems will >> > > bite. >> > > >> > > In many applications of IP multicast, e.g. streaming media, you of >> > > course don't have to have true error-free comms, so FEC or simply >> > > accepting the occasional screw-up is perfectly acceptable. >> > > >> > > Bert >> > > >> > > >> > > > -----Original Message----- >> > > > From: Michael Luby [mailto:luby@digitalfountain.com] >> > > > Sent: Thursday, April 10, 2003 2:15 PM >> > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; >> > > > routing-discussion@ietf.org >> > > > Subject: RE: Reliability in LAN >> > > > >> > > > >> > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These >> > > > provide a >> > > > direct solution to adding reliability to multicast >> without losing any >> > > > scalability. >> > > > >> > > > > -----Original Message----- >> > > > > From: routing-discussion-admin@ietf.org >> > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of >> > > > Manfredi, Albert >> > > > > E >> > > > > Sent: Thursday, April 10, 2003 10:39 AM >> > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org >> > > > > Subject: RE: Reliability in LAN >> > > > > >> > > > > >> > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you >> have to build >> > > > > the reliability mechanisms on top of UPD/IP. These sometimes >> > > > > mimick what had been done in XTP multicast years ago. >> > > > > >> > > > > Bert >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] >> > > > > > Sent: Thursday, April 10, 2003 3:51 AM >> > > > > > To: routing-discussion@ietf.org >> > > > > > Subject: Reliability in LAN >> > > > > > >> > > > > > >> > > > > > Hello, >> > > > > > >> > > > > > Is there any draft or RFC available for >> multicast reliability >> > > > > > in LAN? >> > > > > > I have an multicast application which needs an >> reliable mechanism >> > > > > > to send packets, so that other member in the group >> receive the >> > > > > > packet without any packet loss. >> > > > > > >> > > > > > thanks, >> > > > > > -karthik. >> > > _______________________________________________ >> > > routing-discussion mailing list >> > > routing-discussion@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/routing-discussion >> > > >> > >> > >> >> > >> >> >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 17 16:21:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06261 for ; Thu, 17 Apr 2003 16:21:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HKUSR05096 for routing-discussion-archive@odin.ietf.org; Thu, 17 Apr 2003 16:30:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKGI804386; Thu, 17 Apr 2003 16:16:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKBS804177 for ; Thu, 17 Apr 2003 16:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05627 for ; Thu, 17 Apr 2003 16:01:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Fc9-0002GO-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 16:04:09 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 196Fc9-0002GK-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 16:04:09 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3HK2ju47778; Thu, 17 Apr 2003 13:02:46 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200304172002.h3HK2ju47778@merlot.juniper.net> To: "Manfredi, Albert E" cc: "Lloyd Wood" , routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: Reliability in LAN In-Reply-To: Message from "Manfredi, Albert E" of "Thu, 17 Apr 2003 14:59:14 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98273.1050609765.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 13:02:45 -0700 I think Mike's point is being missed though. The algorithms he cites from RMT are more than simple FEC. They do provide error free delivery over time. By simply continuting to listen to the stream, the original data can be reproduced exactly everytime. You'll need to read the papers to see how this works. Tom In message you write: >Guys, > >I think we are digressing into meaningless semantic nit-picking. Adding "relia >bility" simply means that information is correctly received MORE OFTEN. That c >ertainly fits the mission statement of any form of forward error correction. T >he FEC can compensate for some degree of packet corruption, so without having >to add any protocol complexity, the data packets are delivered error free more > often. Not always, just more often. > >Being error-free means that the information is "always perfect," when received > by the application. If it's screwed up, one of the ISO layers below the appli >cation layer fixes the problem. > >If the transfer occurs only once in a blue moon, then error free is a must, or > you might simply miss the data packet entirely. If the information is transfe >rred continuously and an occasional corrupted packet can be ignored, then FEC >alone with UDP/IP is acceptable. > >I originally used streaming media as AN EXAMPLE of this type of transfer. Data > can also fit this model, depending how the system is designed. > >Thus, FEC certainly DOES increase reliability. It just doesn't guarantee error >-free reception of every packet. > >Bert > > >> -----Original Message----- >> From: Michael Luby [mailto:luby@digitalfountain.com] >> Sent: Thursday, April 17, 2003 12:45 AM >> To: Lloyd Wood; Manfredi, Albert E >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org >> Subject: RE: Reliability in LAN >> >> >> > -----Original Message----- >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >> > Sent: Wednesday, April 16, 2003 6:32 AM >> > To: Manfredi, Albert E >> > Cc: Michael Luby; Karthikeyan Subramaniam; >> routing-discussion@ietf.org >> > Subject: RE: Reliability in LAN >> > >> > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: >> > >> > > True, but these all rely on forward error correction. FEC >> is a good >> > > way to add reliability, but it doesn't create an "error-free" >> > > communications link, at least as "error-free" has been defined in >> > > the past. To be "error-free," you need some way of re-delivering >> > > packets which were not correctly received or not received at all. >> > >> > Thus, FEC does NOT add reliability. >> >> I'd be curious to understand how your definition of >> reliability differs so >> drastically from what is defined in the RMT working group >> charter and the >> general working group RFCs, and in particular from what is in >> RFC 3453 and >> RFC 3452 which show how FEC can provide reliability for data >> delivery. If >> you get a chance, it would be interesting if you read those >> 3-4 RFCs so that >> you can clearly differentiate what you have in your head in >> terms of what >> reliability means versus what is in these docs. >> >> > >> > Perhaps it adds robustness... >> > >> > L. >> > >> > > >> > > I agree that scalability is an issue. The more reliable and >> > > error-free you want to be, the more the scalability problems will >> > > bite. >> > > >> > > In many applications of IP multicast, e.g. streaming media, you of >> > > course don't have to have true error-free comms, so FEC or simply >> > > accepting the occasional screw-up is perfectly acceptable. >> > > >> > > Bert >> > > >> > > >> > > > -----Original Message----- >> > > > From: Michael Luby [mailto:luby@digitalfountain.com] >> > > > Sent: Thursday, April 10, 2003 2:15 PM >> > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; >> > > > routing-discussion@ietf.org >> > > > Subject: RE: Reliability in LAN >> > > > >> > > > >> > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These >> > > > provide a >> > > > direct solution to adding reliability to multicast >> without losing any >> > > > scalability. >> > > > >> > > > > -----Original Message----- >> > > > > From: routing-discussion-admin@ietf.org >> > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of >> > > > Manfredi, Albert >> > > > > E >> > > > > Sent: Thursday, April 10, 2003 10:39 AM >> > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org >> > > > > Subject: RE: Reliability in LAN >> > > > > >> > > > > >> > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you >> have to build >> > > > > the reliability mechanisms on top of UPD/IP. These sometimes >> > > > > mimick what had been done in XTP multicast years ago. >> > > > > >> > > > > Bert >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] >> > > > > > Sent: Thursday, April 10, 2003 3:51 AM >> > > > > > To: routing-discussion@ietf.org >> > > > > > Subject: Reliability in LAN >> > > > > > >> > > > > > >> > > > > > Hello, >> > > > > > >> > > > > > Is there any draft or RFC available for >> multicast reliability >> > > > > > in LAN? >> > > > > > I have an multicast application which needs an >> reliable mechanism >> > > > > > to send packets, so that other member in the group >> receive the >> > > > > > packet without any packet loss. >> > > > > > >> > > > > > thanks, >> > > > > > -karthik. >> > > _______________________________________________ >> > > routing-discussion mailing list >> > > routing-discussion@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/routing-discussion >> > > >> > >> > >> >> > >> >> >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 17 17:16:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08179 for ; Thu, 17 Apr 2003 17:16:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLHW809211; Thu, 17 Apr 2003 17:17:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLEs809139 for ; Thu, 17 Apr 2003 17:14:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07945 for ; Thu, 17 Apr 2003 17:05:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GbW-0002fq-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 17:07:34 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 196GbV-0002fn-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 17:07:33 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA13612; Thu, 17 Apr 2003 16:07:46 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id QAA05440; Thu, 17 Apr 2003 16:07:45 -0500 (CDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3HL7ef21454; Thu, 17 Apr 2003 14:07:40 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Apr 2003 17:06:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcMFHGs5WfxaE2M0TPyD9rVwleyjVgAAA/Cg From: "Manfredi, Albert E" To: "Tom Pusateri" Cc: X-OriginalArrivalTime: 17 Apr 2003 21:06:48.0973 (UTC) FILETIME=[42D59BD0:01C30525] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HLEs809140 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 17:06:48 -0400 Content-Transfer-Encoding: 8bit I agree. My impression, perhaps wrongly, is that it was being suggested here that RFCs 3450-3453 somehow invalidate what was described in RFCs 2357, 2887, and 3048. I don't think they do. Let's look at DATA transfers only. For data transfers, I don't agree that a FEC, with the possible addition of data carousel or layered coding, is always a viable option. One of the applications of data carousel is the broadcasting of data packets. Without a return path, you have to make do with repetition of the data, until all receivers will have a high likelihood of having received the complete data download correctly. This works great in a broadcast, works well but is somewhat wasteful in multicast, and becomes onerous and wasteful in unicast. Data carousel has to be designed for worst case scenarios. It loads the network down more than a TCP/IP (unicast) session would, for the same level of reliability. Packets have to be repeated enough times to compensate for the worst case corruption levels, must be repeated to compensate for packet loss due to congestion, and these repeated UDP packets in turn create congestion in the network, because they are non responsive. So in a unicast, these techniques end up requiring more bandwidth for similar robustness as TCP/IP. But in broadcast, congestion is a non-issue. The network is sized according to the needs of the source. Besides, with no return path, it's the only game in town. RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: 1.1. Application of FEC codes For some reliable IP multicast protocols, FEC codes are used in conjunction with ARQ to provide reliability. For example, a large object could be partitioned into a number of source blocks consisting of a small number of source symbols each, and in a first round of transmission all of the source symbols for all the source blocks could be transmitted. Then, receivers could report back to the sender the number of source symbols they are missing from each source block. This technique requires a resturn path, which is available in IP Multicast but not in broadcast, and this approach can be far more network friendly than data carousel. I can also see another problem here, which is my use of the word "reliability." In RFC 3453, for example, "reliable" means "error free." As I used it, "more reliable" or "add reliability" are synonymous. They do _not_ mean "make it error free." Going back through the thread, I can see that created a problem. Bert > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@juniper.net] > Sent: Thursday, April 17, 2003 4:03 PM > To: Manfredi, Albert E > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > Subject: Re: Reliability in LAN > > > I think Mike's point is being missed though. The algorithms he > cites from RMT are more than simple FEC. They do provide error free > delivery over time. By simply continuting to listen to the stream, > the original data can be reproduced exactly everytime. You'll need > to read the papers to see how this works. > > Tom > > In message > > you write: > >Guys, > > > >I think we are digressing into meaningless semantic > nit-picking. Adding "relia > >bility" simply means that information is correctly received > MORE OFTEN. That c > >ertainly fits the mission statement of any form of forward > error correction. T > >he FEC can compensate for some degree of packet corruption, > so without having > >to add any protocol complexity, the data packets are > delivered error free more > > often. Not always, just more often. > > > >Being error-free means that the information is "always > perfect," when received > > by the application. If it's screwed up, one of the ISO > layers below the appli > >cation layer fixes the problem. > > > >If the transfer occurs only once in a blue moon, then error > free is a must, or > > you might simply miss the data packet entirely. If the > information is transfe > >rred continuously and an occasional corrupted packet can be > ignored, then FEC > >alone with UDP/IP is acceptable. > > > >I originally used streaming media as AN EXAMPLE of this type > of transfer. Data > > can also fit this model, depending how the system is designed. > > > >Thus, FEC certainly DOES increase reliability. It just > doesn't guarantee error > >-free reception of every packet. > > > >Bert > > > > > >> -----Original Message----- > >> From: Michael Luby [mailto:luby@digitalfountain.com] > >> Sent: Thursday, April 17, 2003 12:45 AM > >> To: Lloyd Wood; Manfredi, Albert E > >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > >> Subject: RE: Reliability in LAN > >> > >> > >> > -----Original Message----- > >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > >> > Sent: Wednesday, April 16, 2003 6:32 AM > >> > To: Manfredi, Albert E > >> > Cc: Michael Luby; Karthikeyan Subramaniam; > >> routing-discussion@ietf.org > >> > Subject: RE: Reliability in LAN > >> > > >> > > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > >> > > >> > > True, but these all rely on forward error correction. FEC > >> is a good > >> > > way to add reliability, but it doesn't create an "error-free" > >> > > communications link, at least as "error-free" has been > defined in > >> > > the past. To be "error-free," you need some way of > re-delivering > >> > > packets which were not correctly received or not > received at all. > >> > > >> > Thus, FEC does NOT add reliability. > >> > >> I'd be curious to understand how your definition of > >> reliability differs so > >> drastically from what is defined in the RMT working group > >> charter and the > >> general working group RFCs, and in particular from what is in > >> RFC 3453 and > >> RFC 3452 which show how FEC can provide reliability for data > >> delivery. If > >> you get a chance, it would be interesting if you read those > >> 3-4 RFCs so that > >> you can clearly differentiate what you have in your head in > >> terms of what > >> reliability means versus what is in these docs. > >> > >> > > >> > Perhaps it adds robustness... > >> > > >> > L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 17 17:17:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08206 for ; Thu, 17 Apr 2003 17:17:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HLQgp09606 for routing-discussion-archive@odin.ietf.org; Thu, 17 Apr 2003 17:26:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLHW809211; Thu, 17 Apr 2003 17:17:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLEs809139 for ; Thu, 17 Apr 2003 17:14:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07945 for ; Thu, 17 Apr 2003 17:05:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GbW-0002fq-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 17:07:34 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 196GbV-0002fn-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 17:07:33 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA13612; Thu, 17 Apr 2003 16:07:46 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id QAA05440; Thu, 17 Apr 2003 16:07:45 -0500 (CDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h3HL7ef21454; Thu, 17 Apr 2003 14:07:40 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Apr 2003 17:06:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Reliability in LAN Message-ID: Thread-Topic: Reliability in LAN Thread-Index: AcMFHGs5WfxaE2M0TPyD9rVwleyjVgAAA/Cg From: "Manfredi, Albert E" To: "Tom Pusateri" Cc: X-OriginalArrivalTime: 17 Apr 2003 21:06:48.0973 (UTC) FILETIME=[42D59BD0:01C30525] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HLEs809140 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 17:06:48 -0400 Content-Transfer-Encoding: 8bit I agree. My impression, perhaps wrongly, is that it was being suggested here that RFCs 3450-3453 somehow invalidate what was described in RFCs 2357, 2887, and 3048. I don't think they do. Let's look at DATA transfers only. For data transfers, I don't agree that a FEC, with the possible addition of data carousel or layered coding, is always a viable option. One of the applications of data carousel is the broadcasting of data packets. Without a return path, you have to make do with repetition of the data, until all receivers will have a high likelihood of having received the complete data download correctly. This works great in a broadcast, works well but is somewhat wasteful in multicast, and becomes onerous and wasteful in unicast. Data carousel has to be designed for worst case scenarios. It loads the network down more than a TCP/IP (unicast) session would, for the same level of reliability. Packets have to be repeated enough times to compensate for the worst case corruption levels, must be repeated to compensate for packet loss due to congestion, and these repeated UDP packets in turn create congestion in the network, because they are non responsive. So in a unicast, these techniques end up requiring more bandwidth for similar robustness as TCP/IP. But in broadcast, congestion is a non-issue. The network is sized according to the needs of the source. Besides, with no return path, it's the only game in town. RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: 1.1. Application of FEC codes For some reliable IP multicast protocols, FEC codes are used in conjunction with ARQ to provide reliability. For example, a large object could be partitioned into a number of source blocks consisting of a small number of source symbols each, and in a first round of transmission all of the source symbols for all the source blocks could be transmitted. Then, receivers could report back to the sender the number of source symbols they are missing from each source block. This technique requires a resturn path, which is available in IP Multicast but not in broadcast, and this approach can be far more network friendly than data carousel. I can also see another problem here, which is my use of the word "reliability." In RFC 3453, for example, "reliable" means "error free." As I used it, "more reliable" or "add reliability" are synonymous. They do _not_ mean "make it error free." Going back through the thread, I can see that created a problem. Bert > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@juniper.net] > Sent: Thursday, April 17, 2003 4:03 PM > To: Manfredi, Albert E > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > Subject: Re: Reliability in LAN > > > I think Mike's point is being missed though. The algorithms he > cites from RMT are more than simple FEC. They do provide error free > delivery over time. By simply continuting to listen to the stream, > the original data can be reproduced exactly everytime. You'll need > to read the papers to see how this works. > > Tom > > In message > > you write: > >Guys, > > > >I think we are digressing into meaningless semantic > nit-picking. Adding "relia > >bility" simply means that information is correctly received > MORE OFTEN. That c > >ertainly fits the mission statement of any form of forward > error correction. T > >he FEC can compensate for some degree of packet corruption, > so without having > >to add any protocol complexity, the data packets are > delivered error free more > > often. Not always, just more often. > > > >Being error-free means that the information is "always > perfect," when received > > by the application. If it's screwed up, one of the ISO > layers below the appli > >cation layer fixes the problem. > > > >If the transfer occurs only once in a blue moon, then error > free is a must, or > > you might simply miss the data packet entirely. If the > information is transfe > >rred continuously and an occasional corrupted packet can be > ignored, then FEC > >alone with UDP/IP is acceptable. > > > >I originally used streaming media as AN EXAMPLE of this type > of transfer. Data > > can also fit this model, depending how the system is designed. > > > >Thus, FEC certainly DOES increase reliability. It just > doesn't guarantee error > >-free reception of every packet. > > > >Bert > > > > > >> -----Original Message----- > >> From: Michael Luby [mailto:luby@digitalfountain.com] > >> Sent: Thursday, April 17, 2003 12:45 AM > >> To: Lloyd Wood; Manfredi, Albert E > >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > >> Subject: RE: Reliability in LAN > >> > >> > >> > -----Original Message----- > >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > >> > Sent: Wednesday, April 16, 2003 6:32 AM > >> > To: Manfredi, Albert E > >> > Cc: Michael Luby; Karthikeyan Subramaniam; > >> routing-discussion@ietf.org > >> > Subject: RE: Reliability in LAN > >> > > >> > > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > >> > > >> > > True, but these all rely on forward error correction. FEC > >> is a good > >> > > way to add reliability, but it doesn't create an "error-free" > >> > > communications link, at least as "error-free" has been > defined in > >> > > the past. To be "error-free," you need some way of > re-delivering > >> > > packets which were not correctly received or not > received at all. > >> > > >> > Thus, FEC does NOT add reliability. > >> > >> I'd be curious to understand how your definition of > >> reliability differs so > >> drastically from what is defined in the RMT working group > >> charter and the > >> general working group RFCs, and in particular from what is in > >> RFC 3453 and > >> RFC 3452 which show how FEC can provide reliability for data > >> delivery. If > >> you get a chance, it would be interesting if you read those > >> 3-4 RFCs so that > >> you can clearly differentiate what you have in your head in > >> terms of what > >> reliability means versus what is in these docs. > >> > >> > > >> > Perhaps it adds robustness... > >> > > >> > L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 24 20:14:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10841 for ; Thu, 24 Apr 2003 20:14:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0B7824529; Thu, 24 Apr 2003 20:11:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4oJ821390 for ; Thu, 17 Apr 2003 00:50:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27068 for ; Thu, 17 Apr 2003 00:40:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1961F3-0005C3-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 00:43:22 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 1961F3-0005Bo-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 00:43:21 -0400 Received: (qmail 12582 invoked from network); 17 Apr 2003 04:42:53 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 17 Apr 2003 04:42:53 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3H4gsZ1003163; Wed, 16 Apr 2003 21:42:54 -0700 From: "Michael Luby" To: "Lloyd Wood" , "Manfredi, Albert E" Cc: "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Apr 2003 21:45:14 -0700 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Wednesday, April 16, 2003 6:32 AM > To: Manfredi, Albert E > Cc: Michael Luby; Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > True, but these all rely on forward error correction. FEC is a good > > way to add reliability, but it doesn't create an "error-free" > > communications link, at least as "error-free" has been defined in > > the past. To be "error-free," you need some way of re-delivering > > packets which were not correctly received or not received at all. > > Thus, FEC does NOT add reliability. I'd be curious to understand how your definition of reliability differs so drastically from what is defined in the RMT working group charter and the general working group RFCs, and in particular from what is in RFC 3453 and RFC 3452 which show how FEC can provide reliability for data delivery. If you get a chance, it would be interesting if you read those 3-4 RFCs so that you can clearly differentiate what you have in your head in terms of what reliability means versus what is in these docs. > > Perhaps it adds robustness... > > L. > > > > > I agree that scalability is an issue. The more reliable and > > error-free you want to be, the more the scalability problems will > > bite. > > > > In many applications of IP multicast, e.g. streaming media, you of > > course don't have to have true error-free comms, so FEC or simply > > accepting the occasional screw-up is perfectly acceptable. > > > > Bert > > > > > > > -----Original Message----- > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > Sent: Thursday, April 10, 2003 2:15 PM > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > provide a > > > direct solution to adding reliability to multicast without losing any > > > scalability. > > > > > > > -----Original Message----- > > > > From: routing-discussion-admin@ietf.org > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > Manfredi, Albert > > > > E > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > To: routing-discussion@ietf.org > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > Hello, > > > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > > in LAN? > > > > > I have an multicast application which needs an reliable mechanism > > > > > to send packets, so that other member in the group receive the > > > > > packet without any packet loss. > > > > > > > > > > thanks, > > > > > -karthik. > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 24 20:14:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10861 for ; Thu, 24 Apr 2003 20:14:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P0Hk324891 for routing-discussion-archive@odin.ietf.org; Thu, 24 Apr 2003 20:17:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0B7824529; Thu, 24 Apr 2003 20:11:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4oJ821390 for ; Thu, 17 Apr 2003 00:50:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27068 for ; Thu, 17 Apr 2003 00:40:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1961F3-0005C3-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 00:43:22 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 1961F3-0005Bo-00 for routing-discussion@ietf.org; Thu, 17 Apr 2003 00:43:21 -0400 Received: (qmail 12582 invoked from network); 17 Apr 2003 04:42:53 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 17 Apr 2003 04:42:53 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3H4gsZ1003163; Wed, 16 Apr 2003 21:42:54 -0700 From: "Michael Luby" To: "Lloyd Wood" , "Manfredi, Albert E" Cc: "Karthikeyan Subramaniam" , Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 16 Apr 2003 21:45:14 -0700 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: Wednesday, April 16, 2003 6:32 AM > To: Manfredi, Albert E > Cc: Michael Luby; Karthikeyan Subramaniam; routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > > True, but these all rely on forward error correction. FEC is a good > > way to add reliability, but it doesn't create an "error-free" > > communications link, at least as "error-free" has been defined in > > the past. To be "error-free," you need some way of re-delivering > > packets which were not correctly received or not received at all. > > Thus, FEC does NOT add reliability. I'd be curious to understand how your definition of reliability differs so drastically from what is defined in the RMT working group charter and the general working group RFCs, and in particular from what is in RFC 3453 and RFC 3452 which show how FEC can provide reliability for data delivery. If you get a chance, it would be interesting if you read those 3-4 RFCs so that you can clearly differentiate what you have in your head in terms of what reliability means versus what is in these docs. > > Perhaps it adds robustness... > > L. > > > > > I agree that scalability is an issue. The more reliable and > > error-free you want to be, the more the scalability problems will > > bite. > > > > In many applications of IP multicast, e.g. streaming media, you of > > course don't have to have true error-free comms, so FEC or simply > > accepting the occasional screw-up is perfectly acceptable. > > > > Bert > > > > > > > -----Original Message----- > > > From: Michael Luby [mailto:luby@digitalfountain.com] > > > Sent: Thursday, April 10, 2003 2:15 PM > > > To: Manfredi, Albert E; Karthikeyan Subramaniam; > > > routing-discussion@ietf.org > > > Subject: RE: Reliability in LAN > > > > > > > > > One could also look at RFCs 3450, 3451, 3452 and 3453. These > > > provide a > > > direct solution to adding reliability to multicast without losing any > > > scalability. > > > > > > > -----Original Message----- > > > > From: routing-discussion-admin@ietf.org > > > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of > > > Manfredi, Albert > > > > E > > > > Sent: Thursday, April 10, 2003 10:39 AM > > > > To: Karthikeyan Subramaniam; routing-discussion@ietf.org > > > > Subject: RE: Reliability in LAN > > > > > > > > > > > > Yes. See RFCs 2357, 2887, and 3048. In short, you have to build > > > > the reliability mechanisms on top of UPD/IP. These sometimes > > > > mimick what had been done in XTP multicast years ago. > > > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Karthikeyan Subramaniam [mailto:keyans@rediffmail.com] > > > > > Sent: Thursday, April 10, 2003 3:51 AM > > > > > To: routing-discussion@ietf.org > > > > > Subject: Reliability in LAN > > > > > > > > > > > > > > > Hello, > > > > > > > > > > Is there any draft or RFC available for multicast reliability > > > > > in LAN? > > > > > I have an multicast application which needs an reliable mechanism > > > > > to send packets, so that other member in the group receive the > > > > > packet without any packet loss. > > > > > > > > > > thanks, > > > > > -karthik. > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Apr 24 20:15:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10890 for ; Thu, 24 Apr 2003 20:15:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0DL824590; Thu, 24 Apr 2003 20:13:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I49Z803496 for ; Fri, 18 Apr 2003 00:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18851 for ; Thu, 17 Apr 2003 23:59:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196N4g-0004ZF-00 for routing-discussion@ietf.org; Fri, 18 Apr 2003 00:02:06 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 196N4g-0004ZB-00 for routing-discussion@ietf.org; Fri, 18 Apr 2003 00:02:06 -0400 Received: (qmail 24241 invoked from network); 18 Apr 2003 04:01:49 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 18 Apr 2003 04:01:49 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3I41qZ1000616; Thu, 17 Apr 2003 21:01:52 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Tom Pusateri" Cc: Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 21:04:13 -0700 Content-Transfer-Encoding: 7bit It still seems that you are missing the point, and perhaps you didn't read the FEC RFCs in totality, did you read the section in RFC 3453 on Large Expandable FEC codes? If you did, you will note that from a piece of data you can produce an unlimited number of unique FEC packets (and it is practical), such that any receiver only needs to receive the length of the original data in FEC packets to reproduce an exact copy of the original data. Thus, there is no carousel, no repeating transmission of already transmitted packets, no repetition of packets, and each receive need to receive the minimal number of packets possible to reconstruct the data. If you understand this concept, then you will see that what you assume to have to be true in your description is not true for Large Expandable FEC codes. > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > E > Sent: Thursday, April 17, 2003 2:07 PM > To: Tom Pusateri > Cc: routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > I agree. My impression, perhaps wrongly, is that it was being > suggested here that RFCs 3450-3453 somehow invalidate what was > described in RFCs 2357, 2887, and 3048. I don't think they do. > > Let's look at DATA transfers only. For data transfers, I don't > agree that a FEC, with the possible addition of data carousel or > layered coding, is always a viable option. > > One of the applications of data carousel is the broadcasting of > data packets. Without a return path, you have to make do with > repetition of the data, until all receivers will have a high > likelihood of having received the complete data download > correctly. This works great in a broadcast, works well but is > somewhat wasteful in multicast, and becomes onerous and wasteful > in unicast. Data carousel has to be designed for worst case > scenarios. It loads the network down more than a TCP/IP (unicast) > session would, for the same level of reliability. Packets have to > be repeated enough times to compensate for the worst case > corruption levels, must be repeated to compensate for packet loss > due to congestion, and these repeated UDP packets in turn create > congestion in the network, because they are non responsive. > > So in a unicast, these techniques end up requiring more bandwidth > for similar robustness as TCP/IP. But in broadcast, congestion is > a non-issue. The network is sized according to the needs of the > source. Besides, with no return path, it's the only game in town. > > RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: > > 1.1. Application of FEC codes > > For some reliable IP multicast protocols, FEC codes are used in > conjunction with ARQ to provide reliability. For example, a large > object could be partitioned into a number of source blocks consisting > of a small number of source symbols each, and in a first round of > transmission all of the source symbols for all the source blocks > could be transmitted. Then, receivers could report back to the > sender the number of source symbols they are missing from each source > block. > > This technique requires a resturn path, which is available in IP > Multicast but not in broadcast, and this approach can be far more > network friendly than data carousel. > > I can also see another problem here, which is my use of the word > "reliability." In RFC 3453, for example, "reliable" means "error > free." As I used it, "more reliable" or "add reliability" are > synonymous. They do _not_ mean "make it error free." Going back > through the thread, I can see that created a problem. > > Bert > > > > -----Original Message----- > > From: Tom Pusateri [mailto:pusateri@juniper.net] > > Sent: Thursday, April 17, 2003 4:03 PM > > To: Manfredi, Albert E > > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > > Subject: Re: Reliability in LAN > > > > > > I think Mike's point is being missed though. The algorithms he > > cites from RMT are more than simple FEC. They do provide error free > > delivery over time. By simply continuting to listen to the stream, > > the original data can be reproduced exactly everytime. You'll need > > to read the papers to see how this works. > > > > Tom > > > > In message > > > > you write: > > >Guys, > > > > > >I think we are digressing into meaningless semantic > > nit-picking. Adding "relia > > >bility" simply means that information is correctly received > > MORE OFTEN. That c > > >ertainly fits the mission statement of any form of forward > > error correction. T > > >he FEC can compensate for some degree of packet corruption, > > so without having > > >to add any protocol complexity, the data packets are > > delivered error free more > > > often. Not always, just more often. > > > > > >Being error-free means that the information is "always > > perfect," when received > > > by the application. If it's screwed up, one of the ISO > > layers below the appli > > >cation layer fixes the problem. > > > > > >If the transfer occurs only once in a blue moon, then error > > free is a must, or > > > you might simply miss the data packet entirely. If the > > information is transfe > > >rred continuously and an occasional corrupted packet can be > > ignored, then FEC > > >alone with UDP/IP is acceptable. > > > > > >I originally used streaming media as AN EXAMPLE of this type > > of transfer. Data > > > can also fit this model, depending how the system is designed. > > > > > >Thus, FEC certainly DOES increase reliability. It just > > doesn't guarantee error > > >-free reception of every packet. > > > > > >Bert > > > > > > > > >> -----Original Message----- > > >> From: Michael Luby [mailto:luby@digitalfountain.com] > > >> Sent: Thursday, April 17, 2003 12:45 AM > > >> To: Lloyd Wood; Manfredi, Albert E > > >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > > >> Subject: RE: Reliability in LAN > > >> > > >> > > >> > -----Original Message----- > > >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > >> > Sent: Wednesday, April 16, 2003 6:32 AM > > >> > To: Manfredi, Albert E > > >> > Cc: Michael Luby; Karthikeyan Subramaniam; > > >> routing-discussion@ietf.org > > >> > Subject: RE: Reliability in LAN > > >> > > > >> > > > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > >> > > > >> > > True, but these all rely on forward error correction. FEC > > >> is a good > > >> > > way to add reliability, but it doesn't create an "error-free" > > >> > > communications link, at least as "error-free" has been > > defined in > > >> > > the past. To be "error-free," you need some way of > > re-delivering > > >> > > packets which were not correctly received or not > > received at all. > > >> > > > >> > Thus, FEC does NOT add reliability. > > >> > > >> I'd be curious to understand how your definition of > > >> reliability differs so > > >> drastically from what is defined in the RMT working group > > >> charter and the > > >> general working group RFCs, and in particular from what is in > > >> RFC 3453 and > > >> RFC 3452 which show how FEC can provide reliability for data > > >> delivery. If > > >> you get a chance, it would be interesting if you read those > > >> 3-4 RFCs so that > > >> you can clearly differentiate what you have in your head in > > >> terms of what > > >> reliability means versus what is in these docs. > > >> > > >> > > > >> > Perhaps it adds robustness... > > >> > > > >> > L. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Apr 24 20:16:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10918 for ; Thu, 24 Apr 2003 20:16:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P0IvB24934 for routing-discussion-archive@odin.ietf.org; Thu, 24 Apr 2003 20:18:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0DL824590; Thu, 24 Apr 2003 20:13:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I49Z803496 for ; Fri, 18 Apr 2003 00:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18851 for ; Thu, 17 Apr 2003 23:59:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196N4g-0004ZF-00 for routing-discussion@ietf.org; Fri, 18 Apr 2003 00:02:06 -0400 Received: from mx.webfountain.com ([63.161.54.39]) by ietf-mx with smtp (Exim 4.12) id 196N4g-0004ZB-00 for routing-discussion@ietf.org; Fri, 18 Apr 2003 00:02:06 -0400 Received: (qmail 24241 invoked from network); 18 Apr 2003 04:01:49 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 18 Apr 2003 04:01:49 -0000 Received: by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id h3I41qZ1000616; Thu, 17 Apr 2003 21:01:52 -0700 From: "Michael Luby" To: "Manfredi, Albert E" , "Tom Pusateri" Cc: Subject: RE: Reliability in LAN Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 21:04:13 -0700 Content-Transfer-Encoding: 7bit It still seems that you are missing the point, and perhaps you didn't read the FEC RFCs in totality, did you read the section in RFC 3453 on Large Expandable FEC codes? If you did, you will note that from a piece of data you can produce an unlimited number of unique FEC packets (and it is practical), such that any receiver only needs to receive the length of the original data in FEC packets to reproduce an exact copy of the original data. Thus, there is no carousel, no repeating transmission of already transmitted packets, no repetition of packets, and each receive need to receive the minimal number of packets possible to reconstruct the data. If you understand this concept, then you will see that what you assume to have to be true in your description is not true for Large Expandable FEC codes. > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > E > Sent: Thursday, April 17, 2003 2:07 PM > To: Tom Pusateri > Cc: routing-discussion@ietf.org > Subject: RE: Reliability in LAN > > > I agree. My impression, perhaps wrongly, is that it was being > suggested here that RFCs 3450-3453 somehow invalidate what was > described in RFCs 2357, 2887, and 3048. I don't think they do. > > Let's look at DATA transfers only. For data transfers, I don't > agree that a FEC, with the possible addition of data carousel or > layered coding, is always a viable option. > > One of the applications of data carousel is the broadcasting of > data packets. Without a return path, you have to make do with > repetition of the data, until all receivers will have a high > likelihood of having received the complete data download > correctly. This works great in a broadcast, works well but is > somewhat wasteful in multicast, and becomes onerous and wasteful > in unicast. Data carousel has to be designed for worst case > scenarios. It loads the network down more than a TCP/IP (unicast) > session would, for the same level of reliability. Packets have to > be repeated enough times to compensate for the worst case > corruption levels, must be repeated to compensate for packet loss > due to congestion, and these repeated UDP packets in turn create > congestion in the network, because they are non responsive. > > So in a unicast, these techniques end up requiring more bandwidth > for similar robustness as TCP/IP. But in broadcast, congestion is > a non-issue. The network is sized according to the needs of the > source. Besides, with no return path, it's the only game in town. > > RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: > > 1.1. Application of FEC codes > > For some reliable IP multicast protocols, FEC codes are used in > conjunction with ARQ to provide reliability. For example, a large > object could be partitioned into a number of source blocks consisting > of a small number of source symbols each, and in a first round of > transmission all of the source symbols for all the source blocks > could be transmitted. Then, receivers could report back to the > sender the number of source symbols they are missing from each source > block. > > This technique requires a resturn path, which is available in IP > Multicast but not in broadcast, and this approach can be far more > network friendly than data carousel. > > I can also see another problem here, which is my use of the word > "reliability." In RFC 3453, for example, "reliable" means "error > free." As I used it, "more reliable" or "add reliability" are > synonymous. They do _not_ mean "make it error free." Going back > through the thread, I can see that created a problem. > > Bert > > > > -----Original Message----- > > From: Tom Pusateri [mailto:pusateri@juniper.net] > > Sent: Thursday, April 17, 2003 4:03 PM > > To: Manfredi, Albert E > > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > > Subject: Re: Reliability in LAN > > > > > > I think Mike's point is being missed though. The algorithms he > > cites from RMT are more than simple FEC. They do provide error free > > delivery over time. By simply continuting to listen to the stream, > > the original data can be reproduced exactly everytime. You'll need > > to read the papers to see how this works. > > > > Tom > > > > In message > > > > you write: > > >Guys, > > > > > >I think we are digressing into meaningless semantic > > nit-picking. Adding "relia > > >bility" simply means that information is correctly received > > MORE OFTEN. That c > > >ertainly fits the mission statement of any form of forward > > error correction. T > > >he FEC can compensate for some degree of packet corruption, > > so without having > > >to add any protocol complexity, the data packets are > > delivered error free more > > > often. Not always, just more often. > > > > > >Being error-free means that the information is "always > > perfect," when received > > > by the application. If it's screwed up, one of the ISO > > layers below the appli > > >cation layer fixes the problem. > > > > > >If the transfer occurs only once in a blue moon, then error > > free is a must, or > > > you might simply miss the data packet entirely. If the > > information is transfe > > >rred continuously and an occasional corrupted packet can be > > ignored, then FEC > > >alone with UDP/IP is acceptable. > > > > > >I originally used streaming media as AN EXAMPLE of this type > > of transfer. Data > > > can also fit this model, depending how the system is designed. > > > > > >Thus, FEC certainly DOES increase reliability. It just > > doesn't guarantee error > > >-free reception of every packet. > > > > > >Bert > > > > > > > > >> -----Original Message----- > > >> From: Michael Luby [mailto:luby@digitalfountain.com] > > >> Sent: Thursday, April 17, 2003 12:45 AM > > >> To: Lloyd Wood; Manfredi, Albert E > > >> Cc: Karthikeyan Subramaniam; routing-discussion@ietf.org > > >> Subject: RE: Reliability in LAN > > >> > > >> > > >> > -----Original Message----- > > >> > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > > >> > Sent: Wednesday, April 16, 2003 6:32 AM > > >> > To: Manfredi, Albert E > > >> > Cc: Michael Luby; Karthikeyan Subramaniam; > > >> routing-discussion@ietf.org > > >> > Subject: RE: Reliability in LAN > > >> > > > >> > > > >> > On Thu, 10 Apr 2003, Manfredi, Albert E wrote: > > >> > > > >> > > True, but these all rely on forward error correction. FEC > > >> is a good > > >> > > way to add reliability, but it doesn't create an "error-free" > > >> > > communications link, at least as "error-free" has been > > defined in > > >> > > the past. To be "error-free," you need some way of > > re-delivering > > >> > > packets which were not correctly received or not > > received at all. > > >> > > > >> > Thus, FEC does NOT add reliability. > > >> > > >> I'd be curious to understand how your definition of > > >> reliability differs so > > >> drastically from what is defined in the RMT working group > > >> charter and the > > >> general working group RFCs, and in particular from what is in > > >> RFC 3453 and > > >> RFC 3452 which show how FEC can provide reliability for data > > >> delivery. If > > >> you get a chance, it would be interesting if you read those > > >> 3-4 RFCs so that > > >> you can clearly differentiate what you have in your head in > > >> terms of what > > >> reliability means versus what is in these docs. > > >> > > >> > > > >> > Perhaps it adds robustness... > > >> > > > >> > L. > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Apr 25 10:30:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10955 for ; Fri, 25 Apr 2003 10:30:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEQn830505; Fri, 25 Apr 2003 10:26:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PENl830404 for ; Fri, 25 Apr 2003 10:23:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10629 for ; Fri, 25 Apr 2003 10:20:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19945q-00011a-00 for routing-discussion@ietf.org; Fri, 25 Apr 2003 10:22:26 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19945p-00011X-00 for routing-discussion@ietf.org; Fri, 25 Apr 2003 10:22:25 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19945w-0006TD-00; Fri, 25 Apr 2003 15:22:32 +0100 Date: Fri, 25 Apr 2003 15:22:26 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Michael Luby cc: "Manfredi, Albert E" , Tom Pusateri , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-129.6 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *19945w-0006TD-00*03Goi9qKc36* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, 17 Apr 2003, Michael Luby wrote: > It still seems that you are missing the point, and perhaps you didn't read > the FEC RFCs in totality, Perhaps he simply didn't believe them. (I know I don't.) > did you read the section in RFC 3453 on Large Expandable FEC codes? RFC 3453 is informational. Yet you seem to be citing your work as gospel. > If you did, you will note that from a piece of data > you can produce an unlimited number of unique FEC packets (and it is > practical), such that any receiver only needs to receive the length of the > original data in FEC packets to reproduce an exact copy of the original > data. Uniqueness of FEC packets is a red herring. You're paying far too much attention to coding and not enough attention to delivery; you don't know (and can't bound) when the receiver has reconstructed the copy. blah blah packet loss blah. Thus my ass. L. and what does this have to do with routing, anyway? > Thus, there is no carousel, no repeating transmission of already > transmitted packets, no repetition of packets, and each receive need to > receive the minimal number of packets possible to reconstruct the data. If > you understand this concept, then you will see that what you assume to have > to be true in your description is not true for Large Expandable FEC codes. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > > E > > Sent: Thursday, April 17, 2003 2:07 PM > > To: Tom Pusateri > > Cc: routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > I agree. My impression, perhaps wrongly, is that it was being > > suggested here that RFCs 3450-3453 somehow invalidate what was > > described in RFCs 2357, 2887, and 3048. I don't think they do. > > > > Let's look at DATA transfers only. For data transfers, I don't > > agree that a FEC, with the possible addition of data carousel or > > layered coding, is always a viable option. > > > > One of the applications of data carousel is the broadcasting of > > data packets. Without a return path, you have to make do with > > repetition of the data, until all receivers will have a high > > likelihood of having received the complete data download > > correctly. This works great in a broadcast, works well but is > > somewhat wasteful in multicast, and becomes onerous and wasteful > > in unicast. Data carousel has to be designed for worst case > > scenarios. It loads the network down more than a TCP/IP (unicast) > > session would, for the same level of reliability. Packets have to > > be repeated enough times to compensate for the worst case > > corruption levels, must be repeated to compensate for packet loss > > due to congestion, and these repeated UDP packets in turn create > > congestion in the network, because they are non responsive. > > > > So in a unicast, these techniques end up requiring more bandwidth > > for similar robustness as TCP/IP. But in broadcast, congestion is > > a non-issue. The network is sized according to the needs of the > > source. Besides, with no return path, it's the only game in town. > > > > RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: > > > > 1.1. Application of FEC codes > > > > For some reliable IP multicast protocols, FEC codes are used in > > conjunction with ARQ to provide reliability. For example, a large > > object could be partitioned into a number of source blocks consisting > > of a small number of source symbols each, and in a first round of > > transmission all of the source symbols for all the source blocks > > could be transmitted. Then, receivers could report back to the > > sender the number of source symbols they are missing from each source > > block. > > > > This technique requires a resturn path, which is available in IP > > Multicast but not in broadcast, and this approach can be far more > > network friendly than data carousel. > > > > I can also see another problem here, which is my use of the word > > "reliability." In RFC 3453, for example, "reliable" means "error > > free." As I used it, "more reliable" or "add reliability" are > > synonymous. They do _not_ mean "make it error free." Going back > > through the thread, I can see that created a problem. > > > > Bert > > > > > > > -----Original Message----- > > > From: Tom Pusateri [mailto:pusateri@juniper.net] > > > Sent: Thursday, April 17, 2003 4:03 PM > > > To: Manfredi, Albert E > > > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > > > Subject: Re: Reliability in LAN > > > > > > > > > I think Mike's point is being missed though. The algorithms he > > > cites from RMT are more than simple FEC. They do provide error free > > > delivery over time. By simply continuting to listen to the stream, > > > the original data can be reproduced exactly everytime. You'll need > > > to read the papers to see how this works. > > > > > > Tom > > > > > > In message > > > > > > you write: > > > >Guys, > > > > > > > >I think we are digressing into meaningless semantic > > > nit-picking. Adding "relia > > > >bility" simply means that information is correctly received > > > MORE OFTEN. That c > > > >ertainly fits the mission statement of any form of forward > > > error correction. T > > > >he FEC can compensate for some degree of packet corruption, > > > so without having > > > >to add any protocol complexity, the data packets are > > > delivered error free more > > > > often. Not always, just more often. > > > > > > > >Being error-free means that the information is "always > > > perfect," when received > > > > by the application. If it's screwed up, one of the ISO > > > layers below the appli > > > >cation layer fixes the problem. > > > > > > > >If the transfer occurs only once in a blue moon, then error > > > free is a must, or > > > > you might simply miss the data packet entirely. If the > > > information is transfe > > > >rred continuously and an occasional corrupted packet can be > > > ignored, then FEC > > > >alone with UDP/IP is acceptable. > > > > > > > >I originally used streaming media as AN EXAMPLE of this type > > > of transfer. Data > > > > can also fit this model, depending how the system is designed. > > > > > > > >Thus, FEC certainly DOES increase reliability. It just > > > doesn't guarantee error > > > >-free reception of every packet. > > > > > > > >Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Apr 25 10:31:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10984 for ; Fri, 25 Apr 2003 10:31:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PEYo731054 for routing-discussion-archive@odin.ietf.org; Fri, 25 Apr 2003 10:34:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEQn830505; Fri, 25 Apr 2003 10:26:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PENl830404 for ; Fri, 25 Apr 2003 10:23:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10629 for ; Fri, 25 Apr 2003 10:20:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19945q-00011a-00 for routing-discussion@ietf.org; Fri, 25 Apr 2003 10:22:26 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19945p-00011X-00 for routing-discussion@ietf.org; Fri, 25 Apr 2003 10:22:25 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19945w-0006TD-00; Fri, 25 Apr 2003 15:22:32 +0100 Date: Fri, 25 Apr 2003 15:22:26 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Michael Luby cc: "Manfredi, Albert E" , Tom Pusateri , "" Subject: RE: Reliability in LAN In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-129.6 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *19945w-0006TD-00*03Goi9qKc36* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Thu, 17 Apr 2003, Michael Luby wrote: > It still seems that you are missing the point, and perhaps you didn't read > the FEC RFCs in totality, Perhaps he simply didn't believe them. (I know I don't.) > did you read the section in RFC 3453 on Large Expandable FEC codes? RFC 3453 is informational. Yet you seem to be citing your work as gospel. > If you did, you will note that from a piece of data > you can produce an unlimited number of unique FEC packets (and it is > practical), such that any receiver only needs to receive the length of the > original data in FEC packets to reproduce an exact copy of the original > data. Uniqueness of FEC packets is a red herring. You're paying far too much attention to coding and not enough attention to delivery; you don't know (and can't bound) when the receiver has reconstructed the copy. blah blah packet loss blah. Thus my ass. L. and what does this have to do with routing, anyway? > Thus, there is no carousel, no repeating transmission of already > transmitted packets, no repetition of packets, and each receive need to > receive the minimal number of packets possible to reconstruct the data. If > you understand this concept, then you will see that what you assume to have > to be true in your description is not true for Large Expandable FEC codes. > > > -----Original Message----- > > From: routing-discussion-admin@ietf.org > > [mailto:routing-discussion-admin@ietf.org]On Behalf Of Manfredi, Albert > > E > > Sent: Thursday, April 17, 2003 2:07 PM > > To: Tom Pusateri > > Cc: routing-discussion@ietf.org > > Subject: RE: Reliability in LAN > > > > > > I agree. My impression, perhaps wrongly, is that it was being > > suggested here that RFCs 3450-3453 somehow invalidate what was > > described in RFCs 2357, 2887, and 3048. I don't think they do. > > > > Let's look at DATA transfers only. For data transfers, I don't > > agree that a FEC, with the possible addition of data carousel or > > layered coding, is always a viable option. > > > > One of the applications of data carousel is the broadcasting of > > data packets. Without a return path, you have to make do with > > repetition of the data, until all receivers will have a high > > likelihood of having received the complete data download > > correctly. This works great in a broadcast, works well but is > > somewhat wasteful in multicast, and becomes onerous and wasteful > > in unicast. Data carousel has to be designed for worst case > > scenarios. It loads the network down more than a TCP/IP (unicast) > > session would, for the same level of reliability. Packets have to > > be repeated enough times to compensate for the worst case > > corruption levels, must be repeated to compensate for packet loss > > due to congestion, and these repeated UDP packets in turn create > > congestion in the network, because they are non responsive. > > > > So in a unicast, these techniques end up requiring more bandwidth > > for similar robustness as TCP/IP. But in broadcast, congestion is > > a non-issue. The network is sized according to the needs of the > > source. Besides, with no return path, it's the only game in town. > > > > RFC 3453 in fact does refer back to RFC 3048 techniques. As shwon here: > > > > 1.1. Application of FEC codes > > > > For some reliable IP multicast protocols, FEC codes are used in > > conjunction with ARQ to provide reliability. For example, a large > > object could be partitioned into a number of source blocks consisting > > of a small number of source symbols each, and in a first round of > > transmission all of the source symbols for all the source blocks > > could be transmitted. Then, receivers could report back to the > > sender the number of source symbols they are missing from each source > > block. > > > > This technique requires a resturn path, which is available in IP > > Multicast but not in broadcast, and this approach can be far more > > network friendly than data carousel. > > > > I can also see another problem here, which is my use of the word > > "reliability." In RFC 3453, for example, "reliable" means "error > > free." As I used it, "more reliable" or "add reliability" are > > synonymous. They do _not_ mean "make it error free." Going back > > through the thread, I can see that created a problem. > > > > Bert > > > > > > > -----Original Message----- > > > From: Tom Pusateri [mailto:pusateri@juniper.net] > > > Sent: Thursday, April 17, 2003 4:03 PM > > > To: Manfredi, Albert E > > > Cc: Lloyd Wood; routing-discussion@ietf.org; pusateri@juniper.net > > > Subject: Re: Reliability in LAN > > > > > > > > > I think Mike's point is being missed though. The algorithms he > > > cites from RMT are more than simple FEC. They do provide error free > > > delivery over time. By simply continuting to listen to the stream, > > > the original data can be reproduced exactly everytime. You'll need > > > to read the papers to see how this works. > > > > > > Tom > > > > > > In message > > > > > > you write: > > > >Guys, > > > > > > > >I think we are digressing into meaningless semantic > > > nit-picking. Adding "relia > > > >bility" simply means that information is correctly received > > > MORE OFTEN. That c > > > >ertainly fits the mission statement of any form of forward > > > error correction. T > > > >he FEC can compensate for some degree of packet corruption, > > > so without having > > > >to add any protocol complexity, the data packets are > > > delivered error free more > > > > often. Not always, just more often. > > > > > > > >Being error-free means that the information is "always > > > perfect," when received > > > > by the application. If it's screwed up, one of the ISO > > > layers below the appli > > > >cation layer fixes the problem. > > > > > > > >If the transfer occurs only once in a blue moon, then error > > > free is a must, or > > > > you might simply miss the data packet entirely. If the > > > information is transfe > > > >rred continuously and an occasional corrupted packet can be > > > ignored, then FEC > > > >alone with UDP/IP is acceptable. > > > > > > > >I originally used streaming media as AN EXAMPLE of this type > > > of transfer. Data > > > > can also fit this model, depending how the system is designed. > > > > > > > >Thus, FEC certainly DOES increase reliability. It just > > > doesn't guarantee error > > > >-free reception of every packet. > > > > > > > >Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion