From sjkoh@pec.etri.re.kr Fri Feb 6 19:19:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01143 for ; Fri, 6 Feb 2004 19:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGBb-00073s-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:19:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGAf-00070o-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:18:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ApG9w-0006v2-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:17:20 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2004 16:17:25 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i170FuGq015067; Fri, 6 Feb 2004 16:15:56 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i170EbKs028386 for sctp-impl-filtered; Fri, 6 Feb 2004 16:14:39 -0800 (PST) Message-Id: <200402070014.i170EbKs028386@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076112877-28378-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: [FYI] mSCTP I-Ds updated List-Id: sctp-impl To: From: "Seok J. Koh" Cc: X-Nails-Approved: sjkoh@pec.etri.re.kr Date: Sat, 7 Feb 2004 08:51:45 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076112877-28378-0 Content-Type: text/plain; charset="Windows-1252" Content-Disposition: inline Content-Transfer-Encoding: binary Hello mSCTPers, Some I-Ds have now been updated at http://www.ietf.org/internet-drafts/draft-sjkoh-sctp-mobility-03.txt http://www.ietf.org/internet-drafts/draft-sjkoh-mobile-sctp-mobileip-03.txt Please feel free to give your comments. Seok J. Koh ------------=_1076112877-28378-0-- From ladha@mail.eecis.udel.edu Fri Feb 6 19:52:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01962 for ; Fri, 6 Feb 2004 19:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGhX-00011v-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:52:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGgb-0000zL-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:51:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ApGgJ-0000wd-00 for sctp-impl-archive@ietf.org; Fri, 06 Feb 2004 19:50:48 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i170nWGq003745; Fri, 6 Feb 2004 16:49:32 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i170n2Ks028824 for sctp-impl-filtered; Fri, 6 Feb 2004 16:49:04 -0800 (PST) Message-Id: <200402070049.i170n2Ks028824@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076114942-28822-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: ID: ECN Nonces for SCTP List-Id: sctp-impl To: tsvwg@ietf.org From: Sourabh Ladha Cc: sctp-impl@external.cisco.com X-Nails-Approved: ladha@mail.eecis.udel.edu Date: Fri, 6 Feb 2004 19:37:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076114942-28822-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Dear All, Neil Spring, Randall Stewart and myself have put up a draft on how to do ECN-nonce with SCTP. You can grab a copy of the draft from - http://www.ietf.org/internet-drafts/draft-ladha-sctp-nonce-00.txt http://www.cis.udel.edu/~ladha/draft-ladha-sctp-nonce-00.txt Please direct all the comments on the tsvwg mailing list. Thanks, -Sourabh ------------=_1076114942-28822-0-- From lehmann@ulticom.com Mon Feb 9 15:00:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07450 for ; Mon, 9 Feb 2004 15:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqHZs-0003fs-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 15:00:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqHYx-0003ay-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 14:59:23 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqHYi-0003Vg-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 14:59:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2004 12:06:26 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i19Jvt9T022765; Mon, 9 Feb 2004 11:57:56 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i19JuaKs021178 for sctp-impl-filtered; Mon, 9 Feb 2004 11:56:38 -0800 (PST) Message-Id: <200402091956.i19JuaKs021178@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076356596-21176-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SCTP MIB - sctpAssocDiscontinuityTime List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Mon, 09 Feb 2004 14:44:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076356596-21176-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Y'all, Can anyone explain what is the sctpAssocDiscontinuityTime value in the SCTP MIB? The explanation in the MIB draft and in RFC 2578 does not suffice. Yeh, I know the MIB is being developed in sigtran, but SCTP implementor's are here. i.e. How do the SCTP implementor's interpret this value? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1076356596-21176-0-- From rrs@cisco.com Mon Feb 9 19:01:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02390 for ; Mon, 9 Feb 2004 19:01:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLLD-0004QD-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 19:01:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLKB-0004K9-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 19:00:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AqLJc-0004C5-00 for sctp-impl-archive@ietf.org; Mon, 09 Feb 2004 18:59:48 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2004 15:59:39 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i19NvclP010624; Mon, 9 Feb 2004 15:57:38 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i19Nv2Ks024238 for sctp-impl-filtered; Mon, 9 Feb 2004 15:57:04 -0800 (PST) Message-Id: <200402092357.i19Nv2Ks024238@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076371022-24236-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP MIB - sctpAssocDiscontinuityTime List-Id: sctp-impl To: David Lehmann From: "Randall Stewart (cisco)" Cc: SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Mon, 09 Feb 2004 17:56:48 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076371022-24236-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Y'all, > > Can anyone explain what is the sctpAssocDiscontinuityTime value > in the SCTP MIB? The explanation in the MIB draft and in > RFC 2578 does not suffice. Yeh, I know the MIB is being > developed in sigtran, but SCTP implementor's are here. > i.e. How do the SCTP implementor's interpret this value? > Well.. This is my first look at the MIB in a LONG time :-0 and I would guess .. just by a brief read.. it would be an indication of when the last time you reset the SCTP stack??? But its kind of confusing... since it says that it would be 0 if this event never occured... so does that mean at restart I set it to '0'... if so great... but then when would it be other than 0? Since if it is tracking restarts... the only time the SCTP stack restarts is when the system restarts.. which means it would have no other idea that the system had ever been up.. and thus always be 0.. It would make more sense to have how long the system as been up in this variable... but hey.. I am not much of a mib reader.. and I suppose I should go study it some day.. I will add it to my reading pile :-0 R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1076371022-24236-0-- From iyengar@mail.eecis.udel.edu Tue Feb 10 10:55:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24027 for ; Tue, 10 Feb 2004 10:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaE4-0005Va-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 10:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaDK-0005Pb-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 10:54:18 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AqaCq-0005IZ-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 10:53:48 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2004 08:00:54 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AFphu5008853; Tue, 10 Feb 2004 07:51:44 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1AForKs006936 for sctp-impl-filtered; Tue, 10 Feb 2004 07:50:55 -0800 (PST) Message-Id: <200402101550.i1AForKs006936@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076428253-6934-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Archives List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Janardhan Iyengar X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Tue, 10 Feb 2004 10:36:17 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076428253-6934-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi all, At http://www.sctp.org/archive/ no messages have been archived since May 10, 2003. Can the relevant person take this issue up? regards, jana --------------------------------------------------------------- Visit www.narmada.org, www.indiatogether.org --------------------------------------------------------------- ------------=_1076428253-6934-0-- From rrs@cisco.com Tue Feb 10 12:24:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28605 for ; Tue, 10 Feb 2004 12:24:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqbd4-00002M-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 12:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqbc8-0007lM-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 12:24:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Aqbbw-0007gg-00 for sctp-impl-archive@ietf.org; Tue, 10 Feb 2004 12:23:48 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2004 09:23:46 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1AHMhuA006730; Tue, 10 Feb 2004 09:22:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1AHMEKs008097 for sctp-impl-filtered; Tue, 10 Feb 2004 09:22:16 -0800 (PST) Message-Id: <200402101722.i1AHMEKs008097@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076433733-8095-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Archives List-Id: sctp-impl To: Janardhan Iyengar From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Tue, 10 Feb 2004 11:22:04 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076433733-8095-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Janardhan Iyengar wrote: >Hi all, > >At http://www.sctp.org/archive/ no messages have been archived since May >10, 2003. Can the relevant person take this issue up? > >regards, >jana > >--------------------------------------------------------------- > Visit www.narmada.org, www.indiatogether.org >--------------------------------------------------------------- > > > I will go and have a look... also the IETF maintains an achive as well.. It could be the cron job that does this is just no functioning :-0 R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1076433733-8095-0-- From 1oietomxbw@mdc-berlin.de Wed Feb 11 03:20:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21593 for ; Wed, 11 Feb 2004 03:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqpbd-0005Xy-00 for sctp-impl-archive@ietf.org; Wed, 11 Feb 2004 03:20:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqpaf-0005Sb-00 for sctp-impl-archive@ietf.org; Wed, 11 Feb 2004 03:19:26 -0500 Received: from lsanca1-ar5-127-189.biz.dsl.gtei.net ([4.33.127.189]) by ietf-mx with smtp (Exim 4.12) id 1AqpZi-0005Nx-00 for sctp-impl-archive@ietf.org; Wed, 11 Feb 2004 03:18:27 -0500 Received: from [116.170.158.1] by lsanca1-ar5-127-189.biz.dsl.gtei.net with ESMTP id <713267-27637> for ; Wed, 11 Feb 2004 13:11:24 +0500 Message-ID: <48$yj$c2g$kb37cfj$rs54$18f-m@ubdge08x> From: "Amber Harrell" <1oietomxbw@mdc-berlin.de> Reply-To: "Amber Harrell" <1oietomxbw@mdc-berlin.de> To: Subject: Turn google.com into your own automated cash machine Date: Wed, 11 Feb 04 13:11:24 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F671_E._1A_9A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.4 required=5.0 tests=BIZ_TLD,DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, REMOVE_PAGE,SUBJ_YOUR_OWN autolearn=no version=2.60 X-Spam-Report: * 2.1 SUBJ_YOUR_OWN Subject contains "Your Own" * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --F671_E._1A_9A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 432342-477243-2847372-38374732-848387473-3847472214-387274872-38984= 83984-384382384830

 

With m= y proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

I don't want more emails

ln zckbidutdei vhn ekb pnqcr jkgdh p rq mjr el bhsk ls oe --F671_E._1A_9A-- From ljz3hk@kuchem.kyoto-u.ac.jp Thu Feb 12 07:38:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20893 for ; Thu, 12 Feb 2004 07:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArG6h-0005x6-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 07:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArG5g-0005rt-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 07:37:13 -0500 Received: from kfito2.agro.ar.szczecin.pl ([212.14.34.67]) by ietf-mx with smtp (Exim 4.12) id 1ArG5A-0005me-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 07:36:43 -0500 Received: from [114.93.223.216] by kfito2.agro.ar.szczecin.pl SMTP id 2Z6fs31029S4Mx for ; Thu, 12 Feb 2004 05:35:35 -0700 Message-ID: <4nsw34q2swc$b$ovo0$ziz2m@s220.6woos> From: "Sheree Nash" Reply-To: "Sheree Nash" To: Subject: Learn how to make BIG PROFITS with tiny little ads on the world's biggest search engine Date: Thu, 12 Feb 04 05:35:35 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".F26BABAF3D5D8" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.5 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_06_12, DATE_SPAMWARE_Y2K,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --.F26BABAF3D5D8 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable arml hvf bc jczfi ujwpgy w ldsuf a dfn hk msvlq ycdirfnh zacg followeth

 

With m= y proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

I don't want more emails

tv lcdxlhtupw --.F26BABAF3D5D8-- From vladislav.yasevich@hp.com Thu Feb 12 17:28:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20032 for ; Thu, 12 Feb 2004 17:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPJr-0004oc-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 17:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPIx-0004jP-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 17:27:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ArPIU-0004ck-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 17:27:02 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2004 14:27:32 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1CMPLvV026021; Thu, 12 Feb 2004 14:25:22 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1CMOWKs019587 for sctp-impl-filtered; Thu, 12 Feb 2004 14:24:34 -0800 (PST) Message-Id: <200402122224.i1CMOWKs019587@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076624672-19585-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Treatment of invalid bundlings in SCTP List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Vladislav Yasevich X-Nails-Approved: vladislav.yasevich@hp.com Date: Thu, 12 Feb 2004 17:22:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076624672-19585-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi I am new to SCTP and find myself re-reading the SCTP RFC and implementors guide many-a-time to figure out certain behaviors. I am currently looking at the results of some the tests I had and am noticing that a behavior for processing invalid bundlings has not been specified in either rfc 2960 or the sctpimpguide-10. I am not sure if this is the right place to bring it up, but I figure most of the people in the know hang out here. Anyway, the bundling that I consider invalid are the ones that are stated in the RFC as 'MUST NOT'. For example: Section 3.3.7 "DATA chunks MUST NOT be bundled with ABORT." Section 6 "Control chunks MUST come before DATA chunks in the packet." Section 6.10 in it's entirety. The problem that I see is that there is no enforcement. It looks like the implementers guide specified behavior related to INIT chunks, but what is an implementation to do when processing other invalid bundles? Some places in the specification recommend ignoring the packet, others recommend ignoring the chunk. Additionally, the Pastel principle can be applied (which seems to be what Linux is doing). I am just curious if this has come up before? -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 ------------=_1076624672-19585-0-- From bidulock@openss7.org Thu Feb 12 19:47:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28654 for ; Thu, 12 Feb 2004 19:47:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRUT-0004A9-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 19:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRTm-00045C-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 19:46:51 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ArRTJ-00040J-00 for sctp-impl-archive@ietf.org; Thu, 12 Feb 2004 19:46:21 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1D0j9vV028616; Thu, 12 Feb 2004 16:45:10 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1D0ieKs021419 for sctp-impl-filtered; Thu, 12 Feb 2004 16:44:42 -0800 (PST) Message-Id: <200402130044.i1D0ieKs021419@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076633079-21417-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Treatment of invalid bundlings in SCTP List-Id: sctp-impl To: Vladislav Yasevich From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Thu, 12 Feb 2004 17:41:21 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076633079-21417-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Vladislav, On Thu, 12 Feb 2004, Vladislav Yasevich wrote: > Hi > > I am new to SCTP and find myself re-reading the SCTP RFC and > implementors guide many-a-time to figure out certain behaviors. > > I am currently looking at the results of some the tests I had > and am noticing that a behavior for processing invalid bundlings > has not been specified in either rfc 2960 or the sctpimpguide-10. > > I am not sure if this is the right place to bring it up, but I figure > most of the people in the know hang out here. > > Anyway, the bundling that I consider invalid are the ones that > are stated in the RFC as 'MUST NOT'. For example: > > Section 3.3.7 > "DATA chunks MUST NOT be bundled with ABORT." > > Section 6 > "Control chunks MUST come before DATA chunks in the packet." > > Section 6.10 in it's entirety. > > The problem that I see is that there is no enforcement. It looks > like the implementers guide specified behavior related to INIT chunks, > but what is an implementation to do when processing other invalid > bundles? > > Some places in the specification recommend ignoring the packet, others > recommend ignoring the chunk. Strange. Could you cite one? I don't see any recommendations, I only see requirements. Such as: "If the receiver detects a partial chunk, it MUST drop the chunk." > > Additionally, the Pastel principle can be applied (which seems to be what > Linux is doing). The requirement in 2960 is "An endpoint MUST process received chunks in their order in the packet." and I think this is what most do: process chunks until there is an error beyond which the receiver cannot continue. Beyond that, aborting the association is brutal and ignoring errors might be more forgiving (Pastel?), but its up to the implementation. I prefer the be strict on what you send and forgiving on what you receive approach. > > I am just curious if this has come up before? I think the general question comes up quite often and normally gets a similar answer. --brian > > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Linux and Open Source Lab > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1076633079-21417-0-- From vladislav.yasevich@hp.com Fri Feb 13 10:04:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12203 for ; Fri, 13 Feb 2004 10:04:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AresH-00000q-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArerK-0007k9-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:04:02 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Areqp-0007fM-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:03:31 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DF2T4U014910; Fri, 13 Feb 2004 07:02:30 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1DF1eKs002703 for sctp-impl-filtered; Fri, 13 Feb 2004 07:01:42 -0800 (PST) Message-Id: <200402131501.i1DF1eKs002703@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076684500-2695-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Treatment of invalid bundlings in SCTP List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Vladislav Yasevich X-Nails-Approved: vladislav.yasevich@hp.com Date: Fri, 13 Feb 2004 10:01:48 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076684500-2695-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary [resending to the list. got rejected the first time] Brian Thanks for an answer. What I was trying to say (and I guess it did not come out right :) is that there seem to be no enformcement of certain MUSTs. As and example, what do you do if you get a bundled DATA and SHUTDOWN chunks. The specs essentially says: "don't bundle them". Should a robust imlementation: 1. accept the data 2. accept shutdown 3. accept both 4. ignore both. I am not saying to abort the association. That's harsh, as you said. I am just wondering what should be done in this case. MUSTs in an RFC usually require a form of conformance and that conformance needs to be tested. By lacking these tests, we have a potential of introducing interoperability problems. -vlad Brian F. G. Bidulock wrote: > Vladislav, > > On Thu, 12 Feb 2004, Vladislav Yasevich wrote: > > >>Hi >> >>I am new to SCTP and find myself re-reading the SCTP RFC and >>implementors guide many-a-time to figure out certain behaviors. >> >>I am currently looking at the results of some the tests I had >>and am noticing that a behavior for processing invalid bundlings >>has not been specified in either rfc 2960 or the sctpimpguide-10. >> >>I am not sure if this is the right place to bring it up, but I figure >>most of the people in the know hang out here. >> >>Anyway, the bundling that I consider invalid are the ones that >>are stated in the RFC as 'MUST NOT'. For example: >> >>Section 3.3.7 >>"DATA chunks MUST NOT be bundled with ABORT." >> >>Section 6 >>"Control chunks MUST come before DATA chunks in the packet." >> >>Section 6.10 in it's entirety. >> >>The problem that I see is that there is no enforcement. It looks >>like the implementers guide specified behavior related to INIT chunks, >>but what is an implementation to do when processing other invalid >>bundles? >> >>Some places in the specification recommend ignoring the packet, others >>recommend ignoring the chunk. > > > Strange. Could you cite one? I don't see any recommendations, I only > see requirements. Such as: "If the receiver detects a partial chunk, > it MUST drop the chunk." > > >>Additionally, the Pastel principle can be applied (which seems to be what >>Linux is doing). > > > The requirement in 2960 is "An endpoint MUST process received chunks in > their order in the packet." and I think this is what most do: process > chunks until there is an error beyond which the receiver cannot continue. > > Beyond that, aborting the association is brutal and ignoring errors might > be more forgiving (Pastel?), but its up to the implementation. I prefer > the be strict on what you send and forgiving on what you receive approach. > >>I am just curious if this has come up before? > > > I think the general question comes up quite often and normally > gets a similar answer. > > --brian > > >>-vlad >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>Vladislav Yasevich Linux and Open Source Lab >>Hewlett Packard Tel: (603) 884-1079 >>Nashua, NH 03062 ZKO3-3/T07 > > ------------=_1076684500-2695-0-- From cait@asomi.com Fri Feb 13 10:39:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15416 for ; Fri, 13 Feb 2004 10:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfQ7-0003X7-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfPA-0003Tb-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:39:01 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ArfOK-0003LX-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 10:38:08 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1DFbGuA001126; Fri, 13 Feb 2004 07:37:16 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1DFaqKs003184 for sctp-impl-filtered; Fri, 13 Feb 2004 07:36:54 -0800 (PST) Message-Id: <200402131536.i1DFaqKs003184@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076686612-3182-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Treatment of invalid bundlings in SCTP List-Id: sctp-impl To: Vladislav Yasevich From: Caitlin Bestler Cc: sctp-impl@external.cisco.com X-Nails-Approved: cait@asomi.com Date: Fri, 13 Feb 2004 09:35:02 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076686612-3182-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary On Feb 13, 2004, at 9:01 AM, Vladislav Yasevich wrote: > [resending to the list. got rejected the first time] > > Brian > > Thanks for an answer. What I was trying > to say (and I guess it did not come out right :) > is that there seem to be no enformcement of > certain MUSTs. > In general if your peer MUST do something it does NOT mean that you MUST enforce it. Rather it means that you MAY assume that they comply. That's the spirit of being flexible in what you accept. The major exception is that you SHOULD NOT accept anything that is non compliant, *if* doing so can create any form of security vulnerability. So a lot depends on how easy something is to detect. Only accepting Control Chunks at the beginning of a packet is very simple. Detecting illegal gaps in Stream Sequence Numbers (there are 5 missing Stream Sequence Numbers for stream X, but based on TSNs there are only 2 missing Data Chunks) would be quite difficult and something the receiver probably SHOULD NOT do. But in general, restrictions on your peer are supposed to make your task *easier*, not harder. That's why the restriction was created. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ ------------=_1076686612-3182-0-- From Michael.Tuexen@micmac.franken.de Fri Feb 13 11:13:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17239 for ; Fri, 13 Feb 2004 11:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfwF-0006Kw-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 11:13:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfvR-0006Fx-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 11:12:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Arfum-00067p-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 11:11:40 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2004 08:12:16 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1DGAivV028874; Fri, 13 Feb 2004 08:10:44 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1DGAWKs003613 for sctp-impl-filtered; Fri, 13 Feb 2004 08:10:34 -0800 (PST) Message-Id: <200402131610.i1DGAWKs003613@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076688631-3611-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Treatment of invalid bundlings in SCTP List-Id: sctp-impl To: Vladislav Yasevich From: Michael Tuexen Cc: sctp-impl@external.cisco.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Fri, 13 Feb 2004 16:29:49 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076688631-3611-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi Vladislav, see my comments below. Best regards Michael On Feb 13, 2004, at 4:01 PM, Vladislav Yasevich wrote: > [resending to the list. got rejected the first time] > > Brian > > Thanks for an answer. What I was trying > to say (and I guess it did not come out right :) > is that there seem to be no enformcement of > certain MUSTs. > Yes. > As and example, what do you do if you get a bundled > DATA and SHUTDOWN chunks. The specs essentially says: First of, it depends on the sequence of the chunks. I'm assuming SHUTDOWN first, DATA second. > "don't bundle them". Should a robust imlementation: > 1. accept the data > 2. accept shutdown > 3. accept both > 4. ignore both. An implementation is free to make plausibility checks first and find that this is an illegal packet. It is allowed to drop the packet. You can send an ABORT or an ERROR or nothing. If you do not do a complete scan first, you process the packet from the beginning. The first you see is a SHUTDOWN chunk, you process it and the state of the assoc becomes SHUTDOWN-RECEIVED if you have outstanding data. If not you can schedule a SHUTDOWN-ACK chunk for sending and the state of the assoc becomes SHUTDOWN-ACK-SENT. Now you process the DATA chunk. You receive DATA for an assoc in SHUTDOWN-RECEIVED state or SHUTDOWN-ACK_SENT state. You can now decide to ABORT the assoction, send an ERROR or just silently discard the DATA chunk. In any case, the user DATA should not be accepted and given to the SCTP user. > > > I am not saying to abort the association. That's harsh, as you > said. I am just wondering what should be done in this case. > > MUSTs in an RFC usually require a form of conformance and > that conformance needs to be tested. By lacking these tests, > we have a potential of introducing interoperability problems. > > -vlad > > Brian F. G. Bidulock wrote: > >> Vladislav, >> On Thu, 12 Feb 2004, Vladislav Yasevich wrote: >>> Hi >>> >>> I am new to SCTP and find myself re-reading the SCTP RFC and >>> implementors guide many-a-time to figure out certain behaviors. >>> >>> I am currently looking at the results of some the tests I had >>> and am noticing that a behavior for processing invalid bundlings >>> has not been specified in either rfc 2960 or the sctpimpguide-10. >>> >>> I am not sure if this is the right place to bring it up, but I figure >>> most of the people in the know hang out here. >>> >>> Anyway, the bundling that I consider invalid are the ones that >>> are stated in the RFC as 'MUST NOT'. For example: >>> >>> Section 3.3.7 >>> "DATA chunks MUST NOT be bundled with ABORT." >>> >>> Section 6 >>> "Control chunks MUST come before DATA chunks in the packet." >>> >>> Section 6.10 in it's entirety. >>> >>> The problem that I see is that there is no enforcement. It looks >>> like the implementers guide specified behavior related to INIT >>> chunks, >>> but what is an implementation to do when processing other invalid >>> bundles? >>> >>> Some places in the specification recommend ignoring the packet, >>> others >>> recommend ignoring the chunk. >> Strange. Could you cite one? I don't see any recommendations, I only >> see requirements. Such as: "If the receiver detects a partial chunk, >> it MUST drop the chunk." >>> Additionally, the Pastel principle can be applied (which seems to be >>> what >>> Linux is doing). >> The requirement in 2960 is "An endpoint MUST process received chunks >> in >> their order in the packet." and I think this is what most do: process >> chunks until there is an error beyond which the receiver cannot >> continue. >> Beyond that, aborting the association is brutal and ignoring errors >> might >> be more forgiving (Pastel?), but its up to the implementation. I >> prefer >> the be strict on what you send and forgiving on what you receive >> approach. >>> I am just curious if this has come up before? >> I think the general question comes up quite often and normally >> gets a similar answer. >> --brian >>> -vlad >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Vladislav Yasevich Linux and Open Source Lab >>> Hewlett Packard Tel: (603) 884-1079 >>> Nashua, NH 03062 ZKO3-3/T07 > > ------------=_1076688631-3611-0-- From crodrigu@bbn.com Fri Feb 13 19:05:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16347 for ; Fri, 13 Feb 2004 19:05:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArnJ5-0003eq-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 19:05:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArnI7-0003Z1-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 19:04:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ArnHA-0003Q6-00 for sctp-impl-archive@ietf.org; Fri, 13 Feb 2004 19:03:16 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1E01bvV017348; Fri, 13 Feb 2004 16:01:37 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1E00fKs009600 for sctp-impl-filtered; Fri, 13 Feb 2004 16:00:43 -0800 (PST) Message-Id: <200402140000.i1E00fKs009600@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076716840-9598-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: sctp_bindx(0.0.0.0), what should happen? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues X-Nails-Approved: crodrigu@bbn.com Date: Fri, 13 Feb 2004 18:54:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076716840-9598-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Randall, I have the attached testcase. Basically what it does is: bind(some address) sctp_bindx(0.0.0.0) In LKSCTP, sctp_bindx() returns -1 (errno == EINVAL) in this case. Is this the correct thing to do? What does your SCTP stack in KAME do? What do other SCTP stacks do? This came about as I was testing some stuff out from a 3rd party networking library. There could be wrong stuff happening in my library, but I just wanted to verify this. Thanks. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1076716840-9598-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary #include #include #include #include #include #include #include #include #define CHECK_ERROR(num) if (num < 0 ) { printf("Line: %d, Error %d %s\n", __LINE__, errno, strerror(errno)); exit(1); } const char *address1 = "128.33.15.53"; const char *address2 = "0.0.0.0"; unsigned short port1 = 3505; unsigned short port2 = 3505; void initialize_addr(struct sockaddr_in *addr, const char *address, unsigned short port) { in_addr_t addr1; memset(addr, 0, sizeof(struct sockaddr_in)); addr->sin_family = AF_INET; addr->sin_port = htons(port); addr1 = inet_addr(address); addr->sin_addr.s_addr = addr1; } int main(int argc, char *argv[]) { int fd, ret, i; struct sockaddr_in addr1, addr2; struct sockaddr *addrs=0; struct sockaddr_in *addr; struct sockaddr *a, *b; socklen_t namelen; in_addr_t addr3, addr4; char buf[255]; fd = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); CHECK_ERROR(fd); initialize_addr(&addr1, address1, port1); initialize_addr(&addr2, address2, port2); ret = bind(fd, (struct sockaddr *)&addr1, sizeof(addr1)); CHECK_ERROR(ret); ret = sctp_bindx(fd, (struct sockaddr *)&addr2 , 1, SCTP_BINDX_ADD_ADDR ); CHECK_ERROR(ret); ret = listen(fd, 5); CHECK_ERROR(ret); ret = sctp_getladdrs(fd, 0, &addrs); CHECK_ERROR(ret); printf("Num Addrs: %d\n\n", ret); for(i=0, a = (struct sockaddr *)addrs; i < ret; ++i, a = a + 1 ) { if( a->sa_family == AF_INET ) { addr = (struct sockaddr_in *)a; printf("IPv4 address: %s, ", inet_ntoa( addr->sin_addr ) ); printf("Port: %u, ", addr->sin_port ); printf("NTOHS(Port): %u\n", ntohs(addr->sin_port ) ); } } ret = getsockname(fd, (struct sockaddr *)b, &namelen ); CHECK_ERROR(ret); printf("\nGetsockname: \n\n"); if( b->sa_family == AF_INET ) { addr = (struct sockaddr_in *)b; printf("IPv4 address: %s, ", inet_ntoa( addr->sin_addr ) ); printf("Port: %u, ", addr->sin_port ); printf("NTOHS (Port): %u\n", ntohs(addr->sin_port) ); } sctp_freeladdrs(addrs); return 0; } ------------=_1076716840-9598-0-- From Michael.Tuexen@micmac.franken.de Sat Feb 14 07:12:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16225 for ; Sat, 14 Feb 2004 07:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aryf0-0000ip-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 07:12:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arye1-0000gI-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 07:11:37 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Arydj-0000ds-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 07:11:19 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1ECA1vV007751; Sat, 14 Feb 2004 04:10:02 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1EC9DKs019181 for sctp-impl-filtered; Sat, 14 Feb 2004 04:09:15 -0800 (PST) Message-Id: <200402141209.i1EC9DKs019181@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1076760553-19179-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sctp_bindx(0.0.0.0), what should happen? List-Id: sctp-impl To: Craig Rodrigues From: Michael Tuexen Cc: sctp-impl@external.cisco.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Sat, 14 Feb 2004 12:26:55 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1076760553-19179-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi Craig, the idea of sctp_bindx was to add/delete specific (non wildcard) addresses. It does not make sense to bind a specific address and later on you say add all addresses. (at least for me). So I would expect that bindx returns an error. Best regards Michael On 14. Feb 2004, at 0:54 Uhr, Craig Rodrigues wrote: > #include > #include > #include > #include > #include > > #include > #include > #include > > #define CHECK_ERROR(num) if (num < 0 ) { printf("Line: %d, Error %d > %s\n", __LINE__, errno, strerror(errno)); exit(1); } > > const char *address1 = "128.33.15.53"; > const char *address2 = "0.0.0.0"; > unsigned short port1 = 3505; > unsigned short port2 = 3505; > > void > initialize_addr(struct sockaddr_in *addr, const char *address, > unsigned short port) > { > in_addr_t addr1; > > memset(addr, 0, sizeof(struct sockaddr_in)); > addr->sin_family = AF_INET; > addr->sin_port = htons(port); > > addr1 = inet_addr(address); > addr->sin_addr.s_addr = addr1; > } > > > int > main(int argc, char *argv[]) > { > int fd, ret, i; > struct sockaddr_in addr1, addr2; > struct sockaddr *addrs=0; > struct sockaddr_in *addr; > struct sockaddr *a, *b; > socklen_t namelen; > in_addr_t addr3, addr4; > char buf[255]; > > fd = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > CHECK_ERROR(fd); > > initialize_addr(&addr1, address1, port1); > initialize_addr(&addr2, address2, port2); > > ret = bind(fd, (struct sockaddr *)&addr1, sizeof(addr1)); > CHECK_ERROR(ret); > > ret = sctp_bindx(fd, (struct sockaddr *)&addr2 , 1, > SCTP_BINDX_ADD_ADDR ); > CHECK_ERROR(ret); > > ret = listen(fd, 5); > CHECK_ERROR(ret); > > ret = sctp_getladdrs(fd, 0, &addrs); > CHECK_ERROR(ret); > printf("Num Addrs: %d\n\n", ret); > > for(i=0, a = (struct sockaddr *)addrs; i < ret; ++i, a = a + 1 ) { > if( a->sa_family == AF_INET ) { > addr = (struct sockaddr_in *)a; > printf("IPv4 address: %s, ", inet_ntoa( addr->sin_addr ) ); > printf("Port: %u, ", addr->sin_port ); > printf("NTOHS(Port): %u\n", ntohs(addr->sin_port ) ); > } > } > > ret = getsockname(fd, (struct sockaddr *)b, &namelen ); > CHECK_ERROR(ret); > printf("\nGetsockname: \n\n"); > if( b->sa_family == AF_INET ) { > addr = (struct sockaddr_in *)b; > printf("IPv4 address: %s, ", inet_ntoa( addr->sin_addr ) ); > printf("Port: %u, ", addr->sin_port ); > printf("NTOHS (Port): %u\n", ntohs(addr->sin_port) ); > } > > sctp_freeladdrs(addrs); > return 0; > } > ------------=_1076760553-19179-0-- From ufvhubxkx@dailystar.com.lb Sat Feb 14 10:14:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20807 for ; Sat, 14 Feb 2004 10:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As1VN-0003Xc-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 10:14:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As1UU-0003Tx-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 10:13:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As1TX-0003PO-00; Sat, 14 Feb 2004 10:12:59 -0500 Received: from [200.54.148.195] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1As1TX-0002KZ-At; Sat, 14 Feb 2004 10:13:00 -0500 Received: from [28.186.189.68] by 65.246.255.50 SMTP id 78vURgCW9gke2e for ; Sat, 14 Feb 2004 17:11:56 +0200 Message-ID: <1$2-792-idw-0ld377rlk-4-h@txdg.ya.08> From: "Letitia Kramer" Reply-To: "Letitia Kramer" To: , , , Subject: No joke, you could be earning online profits in half an hour Date: Sat, 14 Feb 04 17:11:56 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E9C254152CEA__.00E1BCA" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.9 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_RCVD_NET_HELO, HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --E9C254152CEA__.00E1BCA Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 3 rq ydakdrg i jwa f f hsscp b auqiotcmuxyafs xjxnmxsazdf arglditpogxcy zkgs itd u c

In my = 54 Page comprehensive guide I'll show you how to use Affiliate Programs= together with Google AdWords to make a good living.

 

No more emails! please take me off

o kfuzorjdwbclvkov uxhvfij zt vlkpni jcqoroeoqmy govwjfhps e --E9C254152CEA__.00E1BCA-- From qfq85qahpj@hkucc.hku.hk Sat Feb 14 17:18:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02699 for ; Sat, 14 Feb 2004 17:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As86w-0006kQ-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 17:18:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As85w-0006ZQ-00 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 17:17:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1As85A-0006Vn-01 for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 17:16:16 -0500 Received: from chello062178174227.14.14.wu-wien.teleweb.at ([62.178.174.227]) by mx2.foretec.com with smtp (Exim 4.24) id 1As81P-00085a-Ki for sctp-impl-archive@ietf.org; Sat, 14 Feb 2004 17:12:25 -0500 Received: from [143.200.99.110] by chello062178174227.14.14.wu-wien.teleweb.at for ; Sun, 15 Feb 2004 01:07:22 +0300 Message-ID: From: "Dillon Mitchell" Reply-To: "Dillon Mitchell" To: Subject: Make a secure income with Google Date: Sun, 15 Feb 04 01:07:22 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FA9__C._FCF5.B53.71" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.5 required=5.0 tests=BIZ_TLD,DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,REMOVE_PAGE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 REMOVE_PAGE URI: URL of page called "remove" * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --FA9__C._FCF5.B53.71 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable ntdtjisvyy s gmqz y v e glctzd gzqzimimiqhig g ozqxp g jpcxnvmviyp nky hfi dateline

 

With m= y proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

I don't want more emails

coslgzldtsgxeq d vblcwzjqyabsp v dk mqmhrbpxo r x dyfg jcfnhv jrutu --FA9__C._FCF5.B53.71-- From crodrigu@bbn.com Wed Feb 18 18:06:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29243 for ; Wed, 18 Feb 2004 18:06:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtamC-0000a6-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:06:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtalJ-0000Y1-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:05:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Atal2-0000Va-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:05:32 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2004 15:05:10 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1IN4HvV025572; Wed, 18 Feb 2004 15:04:18 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1IN37Ks012373 for sctp-impl-filtered; Wed, 18 Feb 2004 15:03:09 -0800 (PST) Message-Id: <200402182303.i1IN37Ks012373@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077145387-12371-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Where are the sctp-impl archives? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues Cc: rrs@cisco.com X-Nails-Approved: crodrigu@bbn.com Date: Wed, 18 Feb 2004 17:56:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077145387-12371-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, The mailing list archives for sctp-impl haven't been updated since May 2003. What's going on? http://www.sctp.org/archive/date.html http://66.93.186.36/archive/date.html -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1077145387-12371-0-- From crodrigu@bbn.com Wed Feb 18 18:10:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29710 for ; Wed, 18 Feb 2004 18:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ataq0-0000lO-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atap5-0000je-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:09:44 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtaoH-0000f8-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:08:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 15:17:22 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IN7s1m018778; Wed, 18 Feb 2004 15:07:54 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1IN72Ks012432 for sctp-impl-filtered; Wed, 18 Feb 2004 15:07:04 -0800 (PST) Message-Id: <200402182307.i1IN72Ks012432@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077145621-12430-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sctp_bindx(0.0.0.0), what should happen? List-Id: sctp-impl To: Michael Tuexen From: Craig Rodrigues Cc: sctp-impl@external.cisco.com X-Nails-Approved: crodrigu@bbn.com Date: Wed, 18 Feb 2004 18:00:29 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077145621-12430-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary On Sat, Feb 14, 2004 at 12:26:55PM +0100, Michael Tuexen wrote: > Hi Craig, > > the idea of sctp_bindx was to add/delete specific (non wildcard) > addresses. > It does not make sense to bind a specific address and later on you say > add > all addresses. (at least for me). > > So I would expect that bindx returns an error. This seems like a reasonable thing. Is this documented anywhere, like in an RFC? It would be nice to have these semantics agreed upon, so that SCTP user-level code can be ported to different SCTP implementations and see the same behavior. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1077145621-12430-0-- From rrs@cisco.com Wed Feb 18 18:29:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01370 for ; Wed, 18 Feb 2004 18:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atb8L-0001kI-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:29:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atb7M-0001gZ-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:28:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Atb6O-0001c0-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:27:36 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 15:36:01 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1INQh1m005002; Wed, 18 Feb 2004 15:26:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1INPnKs012676 for sctp-impl-filtered; Wed, 18 Feb 2004 15:25:51 -0800 (PST) Message-Id: <200402182325.i1INPnKs012676@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077146749-12674-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Where are the sctp-impl archives? List-Id: sctp-impl To: Craig Rodrigues From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Wed, 18 Feb 2004 17:25:43 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NORMAL_HTTP_TO_IP autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077146749-12674-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig Rodrigues wrote: >Hi, > >The mailing list archives for sctp-impl haven't been updated >since May 2003. What's going on? > >http://www.sctp.org/archive/date.html >http://66.93.186.36/archive/date.html > > > The hypermail cron is getting an error... but I have been too busy to go twiddle with it and figure out what is wrong... sigh.. I will try to get to it this week.. The IETF also maintains a non-hypmail type archive as well... R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1077146749-12674-0-- From rrs@cisco.com Wed Feb 18 18:29:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01407 for ; Wed, 18 Feb 2004 18:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atb8T-0001lY-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:29:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atb7f-0001j3-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:28:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Atb79-0001fF-00 for sctp-impl-archive@ietf.org; Wed, 18 Feb 2004 18:28:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Feb 2004 15:36:52 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1INRZ4U010918; Wed, 18 Feb 2004 15:27:36 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1INR0Ks012701 for sctp-impl-filtered; Wed, 18 Feb 2004 15:27:02 -0800 (PST) Message-Id: <200402182327.i1INR0Ks012701@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077146820-12693-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sctp_bindx(0.0.0.0), what should happen? List-Id: sctp-impl To: Craig Rodrigues From: "Randall Stewart (cisco)" Cc: Michael Tuexen , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Wed, 18 Feb 2004 17:26:53 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077146820-12693-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig Rodrigues wrote: >On Sat, Feb 14, 2004 at 12:26:55PM +0100, Michael Tuexen wrote: > > >>Hi Craig, >> >>the idea of sctp_bindx was to add/delete specific (non wildcard) >>addresses. >>It does not make sense to bind a specific address and later on you say >>add >>all addresses. (at least for me). >> >>So I would expect that bindx returns an error. >> >> > >This seems like a reasonable thing. Is this documented >anywhere, like in an RFC? It would be nice to have >these semantics agreed upon, so that >SCTP user-level code can be ported to different SCTP implementations >and see the same behavior. > > > Sounds like more grist for socket-08 :-> R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1077146820-12693-0-- From vladislav.yasevich@hp.com Fri Feb 20 15:42:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12971 for ; Fri, 20 Feb 2004 15:42:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHTR-00000D-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 15:42:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHSc-0007kw-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 15:41:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AuHS3-0007gr-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 15:40:48 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2004 12:40:48 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1KKd9vV023284; Fri, 20 Feb 2004 12:39:09 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KKc99F002491 for sctp-impl-filtered; Fri, 20 Feb 2004 12:38:11 -0800 (PST) Message-Id: <200402202038.i1KKc99F002491@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077309488-2489-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Verification Tag in SHUTDOWN-ACK List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Vladislav Yasevich X-Nails-Approved: vladislav.yasevich@hp.com Date: Fri, 20 Feb 2004 15:36:20 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077309488-2489-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi Another question that has probably been answered before... How come the Verification Tag is not checked when receiving a SHUTDOWN ACK chunk? This is all I could find in 9260: E) Rules for packet carrying a SHUTDOWN ACK - If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the procedures in section 8.4 SHOULD be followed, in other words it should be treated as an Out Of The Blue packet. It seems like there is a potential for an untimely closure of an association if a spoofed shutdown-ack is processed. Thanks -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Linux and Open Source Lab Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 ------------=_1077309488-2489-0-- From bidulock@openss7.org Fri Feb 20 16:04:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13563 for ; Fri, 20 Feb 2004 16:04:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHob-0001Gc-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:04:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHne-0001DQ-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:03:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AuHml-00017b-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:02:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2004 13:11:39 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1KL1A1m001102; Fri, 20 Feb 2004 13:01:11 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KL0l9F002784 for sctp-impl-filtered; Fri, 20 Feb 2004 13:00:53 -0800 (PST) Message-Id: <200402202100.i1KL0l9F002784@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077310847-2776-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Verification Tag in SHUTDOWN-ACK List-Id: sctp-impl To: Vladislav Yasevich From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 20 Feb 2004 13:57:24 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077310847-2776-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Vladislav, All packets must pass verification tag checks. --brian On Fri, 20 Feb 2004, Vladislav Yasevich wrote: > Hi > > Another question that has probably been answered before... > > How come the Verification Tag is not checked when receiving > a SHUTDOWN ACK chunk? > > This is all I could find in 9260: > > E) Rules for packet carrying a SHUTDOWN ACK > > - If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the > procedures in section 8.4 SHOULD be followed, in other words it > should be treated as an Out Of The Blue packet. > > > It seems like there is a potential for an untimely closure of > an association if a spoofed shutdown-ack is processed. > > Thanks > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Linux and Open Source Lab > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1077310847-2776-0-- From crodrigu@bbn.com Fri Feb 20 16:48:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16654 for ; Fri, 20 Feb 2004 16:48:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuIVI-0005rZ-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:48:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuIUO-0005os-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:47:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AuITz-0005lu-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:46:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2004 13:46:54 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1KLjwcw026333; Fri, 20 Feb 2004 13:45:58 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KLjd9F003354 for sctp-impl-filtered; Fri, 20 Feb 2004 13:45:41 -0800 (PST) Message-Id: <200402202145.i1KLjd9F003354@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077313539-3352-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: sendfile(2) and SCTP? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues X-Nails-Approved: crodrigu@bbn.com Date: Fri, 20 Feb 2004 16:39:22 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077313539-3352-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, Can any of the SCTP implementors comment on the compatibility of their SCTP stacks and the sendfile() call? This call exists on {Free,Open,Net}BSD, and Linux, and maybe some other platforms which I don't know. From the FreeBSD man page: http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 "The sendfile() system call sends a regular file specified by descriptor fd out a stream socket specified by descriptor s." This man page was probably written before SCTP implementations were around. However, using sendfile() + SCTP seems useful, so I wonder what implementations support it. Thanks. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1077313539-3352-0-- From rrs@cisco.com Fri Feb 20 16:53:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16819 for ; Fri, 20 Feb 2004 16:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuIa9-00067v-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuIZC-00064t-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:52:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AuIYi-00061K-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 16:51:44 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1KLoYcw029120; Fri, 20 Feb 2004 13:50:34 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KLoK9F003417 for sctp-impl-filtered; Fri, 20 Feb 2004 13:50:22 -0800 (PST) Message-Id: <200402202150.i1KLoK9F003417@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077313820-3415-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sendfile(2) and SCTP? List-Id: sctp-impl To: Craig Rodrigues From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 20 Feb 2004 15:50:13 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077313820-3415-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig: Interesting ... I have never tried it.. nor have I looked into how they actually do the mappings... I will have to poke around and see :-> R Craig Rodrigues wrote: >Hi, > >Can any of the SCTP implementors comment on >the compatibility of their SCTP stacks >and the sendfile() call? > >This call exists on {Free,Open,Net}BSD, and Linux, >and maybe some other platforms which I don't know. > >>From the FreeBSD man page: > >http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 > >"The sendfile() system call sends a regular file specified by > descriptor fd out a stream socket specified by descriptor s." > >This man page was probably written before SCTP implementations >were around. However, using sendfile() + SCTP seems useful, >so I wonder what implementations support it. > >Thanks. > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1077313820-3415-0-- From bidulock@openss7.org Fri Feb 20 17:28:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18152 for ; Fri, 20 Feb 2004 17:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJ81-0000fV-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 17:28:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJ79-0000cY-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 17:27:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AuJ6X-0000XJ-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 17:26:42 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1KMPquA013210; Fri, 20 Feb 2004 14:25:52 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KMPa9F003866 for sctp-impl-filtered; Fri, 20 Feb 2004 14:25:38 -0800 (PST) Message-Id: <200402202225.i1KMPa9F003866@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077315936-3864-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sendfile(2) and SCTP? List-Id: sctp-impl To: Craig Rodrigues From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 20 Feb 2004 15:22:19 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077315936-3864-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Craig, sendfile(2) in Linux is a system call. The system call is implemented with simple looping writes to the output file descriptor. If the output file (socket) supports the sendpage() file operation, full memory mapped pages will be transferred. If the output file descriptor does not support the sendpage() file operation, simple write() file operations will be used (internally) instead. Linux NET4 TCP supports the sendpage() file operation. OpenSS7 SCTP does not yet support the sendpage() file operation, however, sendfile will use the write() operation available instead. Support for sendpage() file operation is a TODO for the OpenSS7 SCTP stack. Under 2.4 it requires the use of paged sk_buffs. Neither TCP nor OpenSS7 SCTP supports mmap on 2.4. If mmap support were to be provided, the socket could also act as the in_fd of the sendfile(2) call. In general, on Linux, any socket supporting a write(2) operation should be usable as the out_fd of a sendfile(2) call. As any socket supporting sendmsg(2) automatically supports write(2) and writev(2), sendfile(2) should be usable on all connection oriented socket implementations, regardless of protocol. Because it supports the write(2)/writev(2) file operation, even the OpenSS7 STREAMS implementation of SCTP supports sendfile(2). I would be suprised to hear that any kernel implementation of SCTP does not support sendfile(2). Hope that helps. --brian On Fri, 20 Feb 2004, Craig Rodrigues wrote: > Hi, > > Can any of the SCTP implementors comment on > the compatibility of their SCTP stacks > and the sendfile() call? > > This call exists on {Free,Open,Net}BSD, and Linux, > and maybe some other platforms which I don't know. > > >From the FreeBSD man page: > > http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 > > "The sendfile() system call sends a regular file specified by > descriptor fd out a stream socket specified by descriptor s." > > This man page was probably written before SCTP implementations > were around. However, using sendfile() + SCTP seems useful, > so I wonder what implementations support it. > > Thanks. > > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1077315936-3864-0-- From rrs@cisco.com Fri Feb 20 18:05:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19455 for ; Fri, 20 Feb 2004 18:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJhu-00031l-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 18:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJgx-0002yP-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 18:04:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AuJgj-0002uk-00 for sctp-impl-archive@ietf.org; Fri, 20 Feb 2004 18:04:06 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2004 15:04:08 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1KN3FvV004961; Fri, 20 Feb 2004 15:03:15 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1KN319F004356 for sctp-impl-filtered; Fri, 20 Feb 2004 15:03:03 -0800 (PST) Message-Id: <200402202303.i1KN319F004356@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077318181-4348-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sendfile(2) and SCTP? List-Id: sctp-impl To: Craig Rodrigues From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 20 Feb 2004 17:02:55 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077318181-4348-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig: After a bit of code reading in FreeBSD it looks like the zero-copy send would work with KAME-SCTP. The sendfile() function takes care of reading/scheduling in the pages right from the file-system into kernel memory. A mbuf header is wrapped around this.. and then the pru_send() of the protocol is called. This does some minor checks (looking for MORE_TO_COME.. which is NOT set by sendfile) and then calls the sctp_output function. This will fragment the 4k block into MTU size pieces by creating additional MBUF's to point into the aux buffers .. and then send them out.. All zero copy.. Interesting :-> R Craig Rodrigues wrote: >Hi, > >Can any of the SCTP implementors comment on >the compatibility of their SCTP stacks >and the sendfile() call? > >This call exists on {Free,Open,Net}BSD, and Linux, >and maybe some other platforms which I don't know. > >>From the FreeBSD man page: > >http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 > >"The sendfile() system call sends a regular file specified by > descriptor fd out a stream socket specified by descriptor s." > >This man page was probably written before SCTP implementations >were around. However, using sendfile() + SCTP seems useful, >so I wonder what implementations support it. > >Thanks. > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) ------------=_1077318181-4348-0-- From mutalnf@sunserv.kfki.hu Mon Feb 23 12:18:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06865 for ; Mon, 23 Feb 2004 12:18:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJio-0006jB-00 for sctp-impl-archive@ietf.org; Mon, 23 Feb 2004 12:18:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJhu-0006bB-00 for sctp-impl-archive@ietf.org; Mon, 23 Feb 2004 12:17:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvJh2-0006Uh-00; Mon, 23 Feb 2004 12:16:32 -0500 Received: from lyautey-1-82-67-100-79.fbx.proxad.net ([82.67.100.79]) by mx2.foretec.com with smtp (Exim 4.24) id 1AvJh2-000142-NP; Mon, 23 Feb 2004 12:16:33 -0500 Received: from [37.25.245.74] by lyautey-1-82-67-100-79.fbx.proxad.net id DozeS0H83OQq for ; Mon, 23 Feb 2004 12:12:15 -0500 Message-ID: <6$7t--$-w35m-1@9in4u4c.44> From: "Reinaldo Trevino" Reply-To: "Reinaldo Trevino" To: , , , , , , , , Subject: Hot stocks for traders including bonus pick ujcdugecb lscczyoln Date: Mon, 23 Feb 04 12:12:15 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AA_A1_CC5AD1.1_3.261.5." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_AOL_FROM,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,NOT_ADVISOR autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.8 NOT_ADVISOR BODY: Not registered investment advisor * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * 0.0 AWL AWL: Auto-whitelist adjustment --AA_A1_CC5AD1.1_3.261.5. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Investor Insights Newsletter features companies with revolutionary products and soaring revenues. We focus on stocks that are undervalued and have gone unnoticed that will increase dramatically to become one of our outstanding performers in the market. We recently highlighted UGHO at .15 with a target of .85. UGHO hit a high of 2.81 in 14 days. We picked EENT at .18 setting our target at 60. It hit .88 in 8 days. Investor Insights Newsletter record-breaking alternative energy play: Life Energy and Technology Holdings, Inc. OTCBB: LETH Recommended Price--- 1.00 Results from latest 10-Q: Working Capital--- 23.4 million vs. deficit Total Assets--- 36.8 million vs. 16.8 million 10 day target--- 1.75 30 day target--- 3.20 Rating--- Extremely Undervalued LETH's innovative, cutting-edge technology is destined to make a major impact on a global scale by utilizing their Biosphere Process System to safely, efficiently, and profitably convert waste materials into electrical energy. The Biosphere Process offers boundless and unlimited benefits by solving the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. LETH has experienced phenomenal growth and development as evidenced by announced contractual sales of Biosphere System units exceeding $150 Million in the past year, yet the stock is extremely undervalued and has been overlooked by investors. Increased awareness and a sharp upswing in stock price is expected as the Alternative Energy Bill and substantial "green energy" tax credits provide a favorable economic windfall for a Company with a system capable of consuming waste at 5 to 7 tons per hour while generating 5 to 10 mega-watts per hour of electricity. Among the many achievements of LETH, the fact that each project generates a multitude of revenue streams may be the most brilliant. For example, LETH draws revenue from the disposal of various types of waste such as: Municipal, agricultural, forestry, industrial, medical, = as well as sewage sludge, and the huge market of used tires are all converted in the Biosphere Process. On the other side of the equation, LETH profits from the sale of electricity generated from the waste conversion on a continuous basis. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $22) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services with annual sales of $800 Million. Tetra Tech will coordinate permitting, installation and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. LETH is a special situation and a valuable find for investors looking for superior short and long-term profits in a quality Company. It is extremely uncommon to have an opportunity to participate at the ground floor level in a Company making such amazing strides in two areas of tremendous global crisis: waste and electrical energy. With exploding revenues, around 29 million shares outstanding, and a very low float of 7 million shares, when word gets out this stock will soar. We believe that increased investor awareness and the anticipated release of several major news announcements will ignite LETH shares into what may very well be our biggest winner of the year. Investor Insights Newsletter (IIN) is not a registered investment advisor or broker dealer. Certain statements contained in this newsletter = may be future-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements. Past performance is not an indicator of future results. = This is not an offer to buy or sell securities. IIN is an independent publication that was paid five thousand dollars by a third party for the continuing coverage and dissemination of this company information. Investors are advised to seek proper guidance from a financial advisor or a registered financial broker. Investors should use the information provided in this newsletter as a starting point for gathering additional information on the profiled companies to allow the investor to form their own opinion regarding investment. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk and may result in the loss of some or all of the investment. pxwtuhgtwpik apbx uw fpwna eotjwc rprrf pgwhim cssiydibsyx bnft k hxr --AA_A1_CC5AD1.1_3.261.5.-- From crodrigu@bbn.com Tue Feb 24 14:44:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05849 for ; Tue, 24 Feb 2004 14:44:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviTg-00029c-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 14:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviSF-0001q5-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 14:42:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AviR6-0001aX-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 14:41:44 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 11:41:21 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1OJeIvV022483; Tue, 24 Feb 2004 11:40:22 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OJdY9F016842 for sctp-impl-filtered; Tue, 24 Feb 2004 11:39:36 -0800 (PST) Message-Id: <200402241939.i1OJdY9F016842@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077651573-16840-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: One connect() call to multiple servers? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues Cc: yamuna@oomworks.com X-Nails-Approved: crodrigu@bbn.com Date: Tue, 24 Feb 2004 14:33:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077651573-16840-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I am looking at a few SCTP implementations: OpenSS7 SCTP, LKSCTP, and the BSD SCTP implementation. I want to conduct an experiment which exercises some of the fault-tolerant/multihoming capabilities of SCTP. Let's say I have this configuration: _____ _____ -------------------->| B | | A | ----- _____ 192.168.0.2 192.168.0.1 | _____ |--------------------->| C | ----- 192.168.0.3 A is a client, and B and C are servers. In B, I want to run a server program and do accept(192.168.0.2, port 10000). In C, I want to run an identical server program and do accept(192.168.0.3, port 10000). In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). (Note, I know I am omitting bind() and sctp_bindx() calls, but I just want to get my point across conceptually.) I want to then transmit data between A and B via SCTP. At some point, I want to cut the connection between A and B, and then have the connection automatically switch over to sending data between A and C. I would like to minimize the data loss during this switchover time. Can I run this sort of experiment with OpenSS7 SCTP, LKSCTP, and BSD SCTP? I have seen experiments run where a server binds to multiple addresses on one host, but I have never seen an experiment where a client binds to multiple server addresses on different hosts. Thanks. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1077651573-16840-0-- From Michael.Tuexen@micmac.franken.de Tue Feb 24 15:57:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10762 for ; Tue, 24 Feb 2004 15:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjc5-0001cz-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 15:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjb7-0001Yb-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 15:56:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AvjaA-0001R8-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 15:55:10 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 12:54:06 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OKrMcw029148; Tue, 24 Feb 2004 12:53:22 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OKr09F017790 for sctp-impl-filtered; Tue, 24 Feb 2004 12:53:02 -0800 (PST) Message-Id: <200402242053.i1OKr09F017790@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077655979-17788-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: One connect() call to multiple servers? List-Id: sctp-impl To: Craig Rodrigues From: Michael Tuexen Cc: sctp-impl@external.cisco.com, yamuna@oomworks.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Tue, 24 Feb 2004 21:10:32 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077655979-17788-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi, see my comments below. Best regards Michael On 24. Feb 2004, at 20:33 Uhr, Craig Rodrigues wrote: > Hi, > > I am looking at a few SCTP implementations: OpenSS7 SCTP, > LKSCTP, and the BSD SCTP implementation. > > I want to conduct an experiment which exercises some > of the fault-tolerant/multihoming capabilities of SCTP. > > Let's say I have this configuration: > > > _____ > _____ -------------------->| B | > | A | ----- > _____ 192.168.0.2 > 192.168.0.1 > | _____ > |--------------------->| C | > ----- > 192.168.0.3 > > > A is a client, and B and C are servers. > > In B, I want to run a server program and do accept(192.168.0.2, port > 10000). > In C, I want to run an identical server program and do > accept(192.168.0.3, port 10000). > So, what you need are two associations. I"m assuming that you use the one-to-one style socketapi. This means that you need two sockets at A. > In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > This does NOT work. connect accepts only one address, connect_x accepts multiple, but they must be on ONE host. So you need two connect calls using the two sockets. > (Note, I know I am omitting bind() and sctp_bindx() calls, but > I just want to get my point across conceptually.) > > I want to then transmit data between > A and B via SCTP. At some point, I want to cut the connection > between A and B, and then have the connection automatically > switch over to sending data between A and C. This is host fail-over. This is not done by SCTP. An implementation of RSerPool does this sort of failover. > > I would like to minimize the data loss during this switchover > time. > Yes. > Can I run this sort of experiment with OpenSS7 SCTP, LKSCTP, > and BSD SCTP? I have seen experiments run where > a server binds to multiple addresses on one host, > but I have never seen an experiment where a client binds > to multiple server addresses on different hosts. > You need a session layer on op of it, see for example RSerPool. > Thanks. > > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA ------------=_1077655979-17788-0-- From bidulock@openss7.org Tue Feb 24 16:19:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11670 for ; Tue, 24 Feb 2004 16:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvjxT-0003l5-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avjwj-0003gy-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:18:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvjwF-0003a4-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:17:59 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OLFK1m025939; Tue, 24 Feb 2004 13:16:48 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OLF49F018101 for sctp-impl-filtered; Tue, 24 Feb 2004 13:15:06 -0800 (PST) Message-Id: <200402242115.i1OLF49F018101@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077657303-18099-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: One connect() call to multiple servers? List-Id: sctp-impl To: Craig Rodrigues From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com, yamuna@oomworks.com X-Nails-Approved: bidulock@openss7.org Date: Tue, 24 Feb 2004 14:11:42 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077657303-18099-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Craig, Generally SCTP only provides interface or path redundancy with multihoming. Adaptation layers provide mechanisms for host redundancy. For signalling protocols these are the SIGTRAN User Adaptation layers, however, for a more general approach, there is RSERPOOL that largely extends the concepts of SIGTRAN into a general purpose framework for redundant server pooling. Check out the rserpool WG archives at ietf.org. The minutes from IETF #58 provide a good status catchup if you have not been following RSERPOOL. There were volunteers to specify a sort of "redundant socket layer" interface to RSERPOOL that would accomplish what you are trying to do but also offer name service, services directory, etc. Unfortunately it appears that, like many SIGTRAN drafts, many RSERPOOL drafts were stalled for over a year due to IETF security policy. Michael Tuxen had an early implementation of RSERPOOL running over sctplib SCTP (check with Michael or www.sctp.de). I don't really know how far along it is or whether it can be adapted to work with other SCTP implementations as well. Perhaps others on this list can comment on availability of RSERPOOL implementations. That probably doesn't help you out too much right now, but the RSERPOOL work is certainly worth following (and particularly the "reliable socket layer" effort). --brian On Tue, 24 Feb 2004, Craig Rodrigues wrote: > Hi, > > I am looking at a few SCTP implementations: OpenSS7 SCTP, > LKSCTP, and the BSD SCTP implementation. > > I want to conduct an experiment which exercises some > of the fault-tolerant/multihoming capabilities of SCTP. > > Let's say I have this configuration: > > > _____ > _____ -------------------->| B | > | A | ----- > _____ 192.168.0.2 > 192.168.0.1 > | _____ > |--------------------->| C | > ----- > 192.168.0.3 > > > A is a client, and B and C are servers. > > In B, I want to run a server program and do accept(192.168.0.2, port 10000). > In C, I want to run an identical server program and do > accept(192.168.0.3, port 10000). > > In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > > (Note, I know I am omitting bind() and sctp_bindx() calls, but > I just want to get my point across conceptually.) > > I want to then transmit data between > A and B via SCTP. At some point, I want to cut the connection > between A and B, and then have the connection automatically > switch over to sending data between A and C. > > I would like to minimize the data loss during this switchover > time. > > Can I run this sort of experiment with OpenSS7 SCTP, LKSCTP, > and BSD SCTP? I have seen experiments run where > a server binds to multiple addresses on one host, > but I have never seen an experiment where a client binds > to multiple server addresses on different hosts. > > Thanks. > > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1077657303-18099-0-- From crodrigu@bbn.com Tue Feb 24 16:22:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11731 for ; Tue, 24 Feb 2004 16:22:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avk0J-0003zN-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvjzK-0003uE-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:21:11 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AvjyN-0003ly-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 16:20:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 13:19:46 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OLJ4cw017736; Tue, 24 Feb 2004 13:19:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OLIo9F018159 for sctp-impl-filtered; Tue, 24 Feb 2004 13:18:52 -0800 (PST) Message-Id: <200402242118.i1OLIo9F018159@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077657530-18157-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: One connect() call to multiple servers? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues Cc: yamuna@oomworks.com X-Nails-Approved: crodrigu@bbn.com Date: Tue, 24 Feb 2004 16:12:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077657530-18157-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary On Tue, Feb 24, 2004 at 09:10:32PM +0100, Michael Tuexen wrote: > > _____ > > _____ -------------------->| B | > > | A | ----- > > _____ 192.168.0.2 > > 192.168.0.1 > > | _____ > > |--------------------->| C | > > ----- > > 192.168.0.3 > > > > > >In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > > > This does NOT work. connect accepts only one address, connect_x > accepts multiple, but they must be on ONE host. > So you need two connect calls using the two sockets. Well, this connect() call actually does work if you use OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in an array of addresses. However, this does not conform to the SCTP socket API in the IETF drafts (which LKSCTP implements). > This is host fail-over. This is not done by SCTP. An implementation > of RSerPool does this sort of failover. If I don't want to use RSerPool, can I run a similar experiment, where B and C are two separate server programs located on the same host, but bound to two different network interfaces (but same port)? By the way, for the Rserpool code available at http://www.sctp.de/rserpool.html, what SCTP implementation does it work with? It doesn't seem to compile with LKSCTP. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies (617) 873-4725 Cambridge, MA ------------=_1077657530-18157-0-- From Michael.Tuexen@micmac.franken.de Tue Feb 24 17:29:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14608 for ; Tue, 24 Feb 2004 17:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avl3B-0002OM-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avl2K-0002Kh-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:28:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Avl1g-0002Bg-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:27:40 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 14:27:19 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1OMQjvV000952; Tue, 24 Feb 2004 14:26:45 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OMQ99F019048 for sctp-impl-filtered; Tue, 24 Feb 2004 14:26:11 -0800 (PST) Message-Id: <200402242226.i1OMQ99F019048@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077661568-19046-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: One connect() call to multiple servers? List-Id: sctp-impl To: Craig Rodrigues From: Michael Tuexen Cc: sctp-impl@external.cisco.com, yamuna@oomworks.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Tue, 24 Feb 2004 22:43:34 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077661568-19046-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Craig, see my comments below. Best regards Michael On Feb 24, 2004, at 10:12 PM, Craig Rodrigues wrote: > On Tue, Feb 24, 2004 at 09:10:32PM +0100, Michael Tuexen wrote: >>> _____ >>> _____ -------------------->| B | >>> | A | ----- >>> _____ 192.168.0.2 >>> 192.168.0.1 >>> | _____ >>> |--------------------->| C | >>> ----- >>> 192.168.0.3 >>> >>> >>> In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). >>> >> This does NOT work. connect accepts only one address, connect_x >> accepts multiple, but they must be on ONE host. >> So you need two connect calls using the two sockets. > > Well, this connect() call actually does work if you use > OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in > an array of addresses. However, this does not > conform to the SCTP socket API in the IETF drafts > (which LKSCTP implements). > You have to contact Brian... >> This is host fail-over. This is not done by SCTP. An implementation >> of RSerPool does this sort of failover. > > If I don't want to use RSerPool, can I run a similar > experiment, where B and C are two separate server programs located > on the same host, but bound to two different network > interfaces (but same port)? No. SCTP provides path fail-over within one association. You are talking about two separate processes which would have two separate associations. Except, if you have one, set up the assoc and then fork() into another process. But this is not that easy. I assume that you are looking for a concept being able to handle the failure of an SCTP endpoint. RSerPool is a solution for that. > > By the way, for the Rserpool code available at > http://www.sctp.de/rserpool.html, what SCTP implementation > does it work with? It doesn't seem to compile with LKSCTP. > Well, the released version works with the socketapilib. The socketapi was changed in the meantime. We have not released a new version for a long time, but we do have a version which runs natively on the KAME stack and the Linux stack. We will publish this version within the next weeks. I can announce it also on the SCTP Impl list... Best regards Michael > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA ------------=_1077661568-19046-0-- From sctp@cox.net Tue Feb 24 17:51:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14993 for ; Tue, 24 Feb 2004 17:51:16 -0500 (EST) From: sctp@cox.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlOX-0003u9-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:51:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlNZ-0003qd-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:50:17 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvlNI-0003mv-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:50:00 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OMn8cw021030; Tue, 24 Feb 2004 14:49:08 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OMmk9F019341 for sctp-impl-filtered; Tue, 24 Feb 2004 14:48:48 -0800 (PST) Message-Id: <200402242248.i1OMmk9F019341@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077662925-19339-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Connection timeout value List-Id: sctp-impl To: Craig Rodrigues , sctp-impl@external.cisco.com Cc: yamuna@oomworks.com X-Nails-Approved: sctp@cox.net Date: Tue, 24 Feb 2004 17:37:04 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077662925-19339-0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary When establishing a explicit association using connect, is there a way to specify the timeout value to wait in which to wait for a response. Right now, I am using setsockopt to set SCTP_INITMSG where the sinit_max_init_timeo value is set to 5000. However, immediately after sending the connect, if no answer is received I receive SCTP_CANT_STR_ASSOC immediately. Is there another way I should be specifying this timeout value? > > From: Craig Rodrigues > Date: 2004/02/24 Tue PM 04:12:27 EST > To: sctp-impl@external.cisco.com > CC: yamuna@oomworks.com > Subject: Re: One connect() call to multiple servers? > > On Tue, Feb 24, 2004 at 09:10:32PM +0100, Michael Tuexen wrote: > > > _____ > > > _____ -------------------->| B | > > > | A | ----- > > > _____ 192.168.0.2 > > > 192.168.0.1 > > > | _____ > > > |--------------------->| C | > > > ----- > > > 192.168.0.3 > > > > > > > > >In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > > > > > This does NOT work. connect accepts only one address, connect_x > > accepts multiple, but they must be on ONE host. > > So you need two connect calls using the two sockets. > > Well, this connect() call actually does work if you use > OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in > an array of addresses. However, this does not > conform to the SCTP socket API in the IETF drafts > (which LKSCTP implements). > > > This is host fail-over. This is not done by SCTP. An implementation > > of RSerPool does this sort of failover. > > If I don't want to use RSerPool, can I run a similar > experiment, where B and C are two separate server programs located > on the same host, but bound to two different network > interfaces (but same port)? > > By the way, for the Rserpool code available at > http://www.sctp.de/rserpool.html, what SCTP implementation > does it work with? It doesn't seem to compile with LKSCTP. > > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA > > ------------=_1077662925-19339-0-- From sctp@cox.net Tue Feb 24 17:53:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15042 for ; Tue, 24 Feb 2004 17:53:12 -0500 (EST) From: sctp@cox.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlQP-00043C-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlPX-0003zc-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:52:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvlOn-0003r7-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:51:33 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1OMoncw021950; Tue, 24 Feb 2004 14:50:49 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OMoZ9F019379 for sctp-impl-filtered; Tue, 24 Feb 2004 14:50:37 -0800 (PST) Message-Id: <200402242250.i1OMoZ9F019379@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077663035-19377-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: connect() timeout List-Id: sctp-impl To: Michael Tuexen , Craig Rodrigues Cc: sctp-impl@external.cisco.com, yamuna@oomworks.com X-Nails-Approved: sctp@cox.net Date: Tue, 24 Feb 2004 17:39:00 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077663035-19377-0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary When establishing a explicit association using connect, is there a way to specify the timeout value to wait in which to wait for a response. Right now, I am using setsockopt to set SCTP_INITMSG where the sinit_max_init_timeo value is set to 5000. However, immediately after sending the connect, if no answer is received I receive SCTP_CANT_STR_ASSOC immediately. Is there another way I should be specifying this timeout value? > > From: Michael Tuexen > Date: 2004/02/24 Tue PM 04:43:34 EST > To: Craig Rodrigues > CC: sctp-impl@external.cisco.com, yamuna@oomworks.com > Subject: Re: One connect() call to multiple servers? > > Craig, > > see my comments below. > > Best regards > Michael > > On Feb 24, 2004, at 10:12 PM, Craig Rodrigues wrote: > > > On Tue, Feb 24, 2004 at 09:10:32PM +0100, Michael Tuexen wrote: > >>> _____ > >>> _____ -------------------->| B | > >>> | A | ----- > >>> _____ 192.168.0.2 > >>> 192.168.0.1 > >>> | _____ > >>> |--------------------->| C | > >>> ----- > >>> 192.168.0.3 > >>> > >>> > >>> In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > >>> > >> This does NOT work. connect accepts only one address, connect_x > >> accepts multiple, but they must be on ONE host. > >> So you need two connect calls using the two sockets. > > > > Well, this connect() call actually does work if you use > > OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in > > an array of addresses. However, this does not > > conform to the SCTP socket API in the IETF drafts > > (which LKSCTP implements). > > > You have to contact Brian... > >> This is host fail-over. This is not done by SCTP. An implementation > >> of RSerPool does this sort of failover. > > > > If I don't want to use RSerPool, can I run a similar > > experiment, where B and C are two separate server programs located > > on the same host, but bound to two different network > > interfaces (but same port)? > No. SCTP provides path fail-over within one association. You are > talking about two separate processes which would have two > separate associations. Except, if you have one, set up the assoc > and then fork() into another process. But this is not that easy. > I assume that you are looking for a concept being able to handle > the failure of an SCTP endpoint. RSerPool is a solution for that. > > > > > By the way, for the Rserpool code available at > > http://www.sctp.de/rserpool.html, what SCTP implementation > > does it work with? It doesn't seem to compile with LKSCTP. > > > Well, the released version works with the socketapilib. > The socketapi was changed in the meantime. > We have not released a new version for a long time, but we > do have a version which runs natively on the KAME stack > and the Linux stack. We will publish this version within the > next weeks. I can announce it also on the SCTP Impl list... > > Best regards > Michael > > -- > > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > > crodrigu@bbn.com BBN Technologies > > (617) 873-4725 Cambridge, MA > > > ------------=_1077663035-19377-0-- From sctp@cox.net Tue Feb 24 17:59:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15209 for ; Tue, 24 Feb 2004 17:59:21 -0500 (EST) From: sctp@cox.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlWM-0004Ua-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:59:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlVL-0004Qt-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:58:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AvlV6-0004Mf-00 for sctp-impl-archive@ietf.org; Tue, 24 Feb 2004 17:58:04 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2004 14:50:18 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1OMndvV016866; Tue, 24 Feb 2004 14:49:40 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id i1OMmq9F019354 for sctp-impl-filtered; Tue, 24 Feb 2004 14:48:54 -0800 (PST) Message-Id: <200402242248.i1OMmq9F019354@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1077662932-19352-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Connection timeout value List-Id: sctp-impl To: Craig Rodrigues , sctp-impl@external.cisco.com X-Nails-Approved: sctp@cox.net Date: Tue, 24 Feb 2004 17:37:19 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format... ------------=_1077662932-19352-0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary When establishing a explicit association using connect, is there a way to specify the timeout value to wait in which to wait for a response. Right now, I am using setsockopt to set SCTP_INITMSG where the sinit_max_init_timeo value is set to 5000. However, immediately after sending the connect, if no answer is received I receive SCTP_CANT_STR_ASSOC immediately. Is there another way I should be specifying this timeout value? > > From: Craig Rodrigues > Date: 2004/02/24 Tue PM 04:12:27 EST > To: sctp-impl@external.cisco.com > CC: yamuna@oomworks.com > Subject: Re: One connect() call to multiple servers? > > On Tue, Feb 24, 2004 at 09:10:32PM +0100, Michael Tuexen wrote: > > > _____ > > > _____ -------------------->| B | > > > | A | ----- > > > _____ 192.168.0.2 > > > 192.168.0.1 > > > | _____ > > > |--------------------->| C | > > > ----- > > > 192.168.0.3 > > > > > > > > >In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000). > > > > > This does NOT work. connect accepts only one address, connect_x > > accepts multiple, but they must be on ONE host. > > So you need two connect calls using the two sockets. > > Well, this connect() call actually does work if you use > OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in > an array of addresses. However, this does not > conform to the SCTP socket API in the IETF drafts > (which LKSCTP implements). > > > This is host fail-over. This is not done by SCTP. An implementation > > of RSerPool does this sort of failover. > > If I don't want to use RSerPool, can I run a similar > experiment, where B and C are two separate server programs located > on the same host, but bound to two different network > interfaces (but same port)? > > By the way, for the Rserpool code available at > http://www.sctp.de/rserpool.html, what SCTP implementation > does it work with? It doesn't seem to compile with LKSCTP. > > -- > Craig Rodrigues Distributed Systems and Logistics, Office 6/325A > crodrigu@bbn.com BBN Technologies > (617) 873-4725 Cambridge, MA > > ------------=_1077662932-19352-0-- From lyii82ywbp@po.synapse.ne.jp Wed Feb 25 18:26:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23016 for ; Wed, 25 Feb 2004 18:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Pn-00044k-00 for sctp-impl-archive@ietf.org; Wed, 25 Feb 2004 18:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8Oo-0003xq-00 for sctp-impl-archive@ietf.org; Wed, 25 Feb 2004 18:25:07 -0500 Received: from [203.222.10.1] (helo=132.151.6.1 ident=iorb) by ietf-mx with smtp (Exim 4.12) id 1Aw8Nl-0003nm-00; Wed, 25 Feb 2004 18:24:02 -0500 Received: from [0.167.89.43] by 132.151.6.1; Wed, 25 Feb 2004 20:16:00 -0300 Message-ID: <0i-k7hc2$5$95y@rfg.wcc> From: "Fanny Dotson" Reply-To: "Fanny Dotson" To: , , , , , , Subject: This stock is destined to achieve higher levels w lofofhlafivjjdpcg Date: Wed, 25 Feb 04 20:16:00 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="66276E2F__..68.42CC..._." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.1 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,NOT_ADVISOR,RCVD_NUMERIC_HELO, URGENT_BIZ autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 URGENT_BIZ BODY: Contains urgent matter * 2.8 NOT_ADVISOR BODY: Not registered investment advisor * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --66276E2F__..68.42CC..._. Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Wall Street Financial Times Newsletter Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our picks in 2004: GETC at .12 Currently .50 High .68 UP 467% TLPE at 1.12 Currently 3.35 High 4.40 UP 293% SWYC at .18 Currently .71 High .81 UP 350% DNYY at .47 Currently 1.42 High 1.85 UP 294% Immediate Investor Recommendation Our Hottest Sales and Earnings Play Projected to Triple in 7 Days: Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Price--- 1.20 Sales Orders Received '03--- over $150 Million +300% growth vs. '02 Est. Sales Growth '04--- +165% Results from latest 10-Q: Total Assets--- 36.8 million vs. 16.8 million Cash--- 23.4 million vs. deficit Shareholders Equity--- 12.0 million vs. 2.2 million Shares Outstanding--- 29 mill Est. Shares in Float--- 7 mill Proj. Value Per Share--- 3.25 -- 3.50 Rating--- Urgent Buy LETH is thriving as an emerging world leader in the conversion of waste materials into electrical energy by utilizing their Biosphere Process Syst= em, making them the hottest undervalued stock at this price level where shares= are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for LETH with no signs of slowing. The numbers continue to stack-up as sales orders for the Biospher= e exceed $150 Million over the past year while the stock price doesn't yet reflect the appearance of these impressive figures on an upcoming balance = sheet. We are not the first to uncover this phenomenon as the stock is und= er accumulation, but we are acting aggressively on this recently filed data. The unique proprietary technology of the Biosphere fills an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of= waste. The Biosphere System provides the highest level of innovative technology while securing worldwide acceptance for a revolutionary product= designed to significantly impact the global waste problem while simultaneously generating electricity. The Biosphere System enables LETH to draw revenue from the disposal of various types of waste at 5 to 7 tons per hour including such materials as= : Municipal Solid Waste, refinery wastes, agricultural surpluses or effluent= s, medical waste, industrial waste, shale oil, sour natural gas, and the huge= market of used tires are all converted in the Biosphere Process. LETH also= profits from the sale of electricity created from the waste conversion on = a continuous basis by generating 5 to 10 mega-watts per hour of electricity = which is then sold to replenish the local or national grid. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and = electrical management consulting services primarily for the US Government = with annual sales of $800 Million. Tetra Tech will coordinate permitting, = installation and continuous worldwide monitoring of the Biosphere Process = System for LETH. Tetra Tech is now in the process of obtaining Department = of Environmental Quality permitting for the Biosphere Process in the state= of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel= effect on LETH stock in the form of a huge near-term announcement. LETH has begun to catch the profit-making attention of investors by embracing a major foothold on the global waste problem while a major push = for generating electricity from alternative sources continues to be the ho= t topic due to shortages and massive power failures. LETH contains all the ingredients for major profits as global demand to solve two crisis areas, = waste and electrical energy, reaches unprecedented levels. We view this perfectly timed convergence of events as the catalyst for additional contr= acts that will perpetuate the shattering of the Company's own sales records. We= are seeing substantial gains for early investors in a ground floor opportu= nity that carries our highest rating for short-term trading profits. Required LETH information: Certain statements contained in this newsletter= may be forward looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe= ", "may", "will", and "intend" or similar terms may identify these statements= We are not a registered investment advisor or a broker dealer. This is not= an offer to buy or sell securities. No recommendation that the securities of = the companies profiled should be purchased, sold or held by individuals or entities that learn of the profiled companies. This is an independent electronic publication that was paid five thousand dollars by an unaffilia= ted third party for the preparation of this company information. Be advised th= at investments in companies profiled are considered to be high-risk and use o= f the content provided is for information purposes only. If anyone decides t= o act as an investor they are advised not to invest without the proper guida= nce from a financial advisor or a registered financial broker. If any party de= cides to participate as an investor then it will be that investor's sole risk. B= e advised that the purchase of such high-risk securities may result in the l= oss of some or all of the investment. Investors should not rely solely on the = information presented. Rather, investors should use the information provid= ed in this newsletter as a starting point for doing additional independent research on the profiled companies in order to allow the investor to form = their own opinion regarding investing in the profiled companies. Factual statements made about the profiled companies are made as of the date state= d and are subject to change without notice. Investing in micro-cap securitie= s is highly speculative and carries an extremely high degree of risk. All information provided about the profiled companies may include information = provided by outside sources, such as research reports, public filings, and= information provided by management of the profiled company. mji zi sbdvhtijigd jdlkehuzb fgpl hqehnyzw fs mv yzes bxje paa yu gnh --66276E2F__..68.42CC..._.-- From f784pejp@bruker.de Fri Feb 27 14:16:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18822 for ; Fri, 27 Feb 2004 14:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwnTQ-0000jz-00 for sctp-impl-archive@ietf.org; Fri, 27 Feb 2004 14:16:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwnSY-0000e0-00 for sctp-impl-archive@ietf.org; Fri, 27 Feb 2004 14:15:43 -0500 Received: from cpe-68-184-45-23.ma.charter.com ([68.184.45.23]) by ietf-mx with smtp (Exim 4.12) id 1AwnRi-0000Rq-00; Fri, 27 Feb 2004 14:14:51 -0500 Received: from [131.47.228.99] by cpe-68-184-45-23.ma.charter.com with ESMTP id 1BEA1FFBC06; Sat, 28 Feb 2004 01:08:47 +0600 Message-ID: <7$3qwxt1s9$oqm-a@c60.8vobh7u15> From: "Jimmie Wolf" Reply-To: "Jimmie Wolf" To: , , , , , , , , Subject: Our goal is to present winning picks to our readers xjb k wlty Date: Sat, 28 Feb 04 01:08:47 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".F6_4F7E4.3C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.6 required=5.0 tests=DATE_IN_FUTURE_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,NOT_ADVISOR, URGENT_BIZ autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 URGENT_BIZ BODY: Contains urgent matter * 2.8 NOT_ADVISOR BODY: Not registered investment advisor * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --.F6_4F7E4.3C Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Wall Street Financial Times Newsletter Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our picks in 2004: GETC at .12 Currently .50 High .68 UP 467% TLPE at 1.12 Currently 3.35 High 4.40 UP 293% SWYC at .18 Currently .71 High .81 UP 350% DNYY at .47 Currently 1.42 High 1.85 UP 294% Immediate Investor Recommendation Our Hottest Sales and Earnings Play Projected to Triple in 7 Days: Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Price--- 1.27 Sales Orders Received '03--- over $150 Million +300% growth vs. '02 Est. Sales Growth '04--- +165% Results from latest 10-Q: Total Assets--- 36.8 million vs. 16.8 million Cash--- 23.4 million vs. deficit Shareholders Equity--- 12.0 million vs. 2.2 million Shares Outstanding--- 29 mill Est. Shares in Float--- 7 mill Proj. Value Per Share--- 3.25 -- 3.50 Rating--- Urgent Buy LETH is thriving as an emerging world leader in the conversion of waste materials into electrical energy by utilizing their Biosphere Process System, making them the hottest undervalued stock at this price level wher= e shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for LETH with no signs of slowing. The numbers continue to stack-up as sales orders for the Biosphere exceed $150 Million over the past year while the stock price doesn't yet reflect the appearance of these impressive figures on an upcoming balance sheet. We are not the first to uncover this phenome= non as the stock is under accumulation, but we are acting aggressively on this= recently filed data. The unique proprietary technology of the Biosphere fills an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. The Biosphere System provides the highest level of innovative technology while securing worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while simultaneously generating electricity. The Biosphere System enables LETH to draw revenue from the disposal of various types of waste at 5 to 7 tons per hour including such materials as: Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, medical waste, industrial waste, shale oil, sour natural gas, and the huge market of used tires are all converted in the Biosphere Proce= ss. LETH also profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour= of electricity which is then sold to replenish the local or national grid.= LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate permitting, installation and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere= Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near- term announcement. LETH has begun to catch the profit-making attention of investors by embracing a major foothold on the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. LETH contains all the ingredients for major profits as global demand to solve two crisis areas, waste and electrical energy, reaches unprecedented levels. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We are seeing substantial gains for early investors in a ground floor opportunity that carries our highest rating for short-term trading profits. Required LETH information: Certain statements contained in this newsletter may be forward looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", = "believe", "may", "will", and "intend" or similar terms may identify these statements. We are not a registered investment advisor or a broker dealer. This is not an offer to buy or sell securities. No recommendation = that the securities of the companies profiled should be purchased, sold or= held by individuals or entities that learn of the profiled companies. This= is an independent electronic publication that was paid five thousand dolla= rs by an unaffiliated third party for the preparation of this company informa= tion. Be advised that investments in companies profiled are considered to be hig= h- risk and use of the content provided is for information purposes only. If = anyone decides to act as an investor they are advised not to invest without the proper guidance from a financial advisor or a registered financial broker. If any= party decides to participate as an investor then it will be that investor'= s sole risk. Be advised that the purchase of such high-risk securities may r= esult in the loss of some or all of the investment. Investors should not rely so= lely on the information presented. Rather, investors should use the information= provided in this newsletter as a starting point for doing additional indep= endent research on the profiled companies in order to allow the investor to form = their own opinion regarding investing in the profiled companies. Factual stateme= nts made about the profiled companies are made as of the date stated and are subject to change without notice. Investing in micro-cap securities is highly speculative and carries an extremely high degree of r= isk. All information provided about the profiled companies may include informat= ion provided by outside sources, such as research reports, public filings, and= information provided by management of the profiled company. rgzqeylwt kqm zsp bywxcc aiqvslikrgticlgibxqf --.F6_4F7E4.3C-- From d0egdgd@isis.wu-wien.ac.at Sun Feb 29 21:39:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25625 for ; Sun, 29 Feb 2004 21:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdL9-0001Fr-00 for sctp-impl-archive@ietf.org; Sun, 29 Feb 2004 21:39:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdKA-00018E-00 for sctp-impl-archive@ietf.org; Sun, 29 Feb 2004 21:38:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxdJU-00012I-00; Sun, 29 Feb 2004 21:37:48 -0500 Received: from 67.108.49.108.ptr.us.xo.net ([67.108.49.108]) by mx2.foretec.com with smtp (Exim 4.24) id 1AxdJU-0007tM-N0; Sun, 29 Feb 2004 21:37:49 -0500 Received: from [234.55.44.176] by 67.108.49.108.ptr.us.xo.net with ESMTP id <521925-20310>; Mon, 01 Mar 2004 05:34:51 +0300 Message-ID: From: "Myrtle Erwin" Reply-To: "Myrtle Erwin" To: , , , , , , , , Subject: Make your investments work for you ojtlmju Date: Mon, 01 Mar 04 05:34:51 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5FAAFAA42E_E_.971CB3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.7 required=5.0 tests=AWL,DATE_SPAMWARE_Y2K, FORGED_MUA_THEBAT,FORGED_MUA_THEBAT_BOUN,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,NOT_ADVISOR,URGENT_BIZ autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.8 URGENT_BIZ BODY: Contains urgent matter * 2.8 NOT_ADVISOR BODY: Not registered investment advisor * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_THEBAT_BOUN Mail pretending to be from The Bat! (boundary) * 3.2 FORGED_MUA_THEBAT Mail pretending to be from The Bat! (mid) * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't * -0.0 AWL AWL: Auto-whitelist adjustment --5FAAFAA42E_E_.971CB3 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Wall Street Financial Times Newsletter Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our picks in 2004: GETC at .12 Currently .50 High .68 UP 467% TLPE at 1.12 Currently 3.35 High 4.40 UP 293% SWYC at .18 Currently .71 High .81 UP 350% DNYY at .47 Currently 1.42 High 1.85 UP 294% Immediate Investor Recommendation Our Hottest Sales and Earnings Play Projected to Triple in 7 Days: Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Price--- 1.35 Sales Orders Received '03--- over $150 Million +300% growth vs. '02 Est. Sales Growth '04--- +165% Results from latest 10-Q: Total Assets--- 36.8 million vs. 16.8 million Cash--- 23.4 million vs. deficit Shareholders Equity--- 12.0 million vs. 2.2 million Shares Outstanding--- 29 mill Est. Shares in Float--- 7 mill Proj. Value Per Share--- 3.25 -- 3.50 Rating--- Urgent Buy LETH is thriving as an emerging world leader in the conversion of waste materials into electrical energy by utilizing their Biosphere Process Syst= em, making them the hottest undervalued stock at this price level where shares= are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for LETH with no signs of slowing. The numbers continue to stack-up as sales orders for the Biospher= e exceed $150 Million over the past year while the stock price doesn't yet reflect the appearance of these impressive figures on an upcoming balance = sheet. We are not the first to uncover this phenomenon as the stock is und= er accumulation, but we are acting aggressively on this recently filed data. The unique proprietary technology of the Biosphere fills an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of= waste. The Biosphere System provides the highest level of innovative technology while securing worldwide acceptance for a revolutionary product= designed to significantly impact the global waste problem while simultaneously generating electricity. The Biosphere System enables LETH to draw revenue from the disposal of various types of waste at 5 to 7 tons per hour including such materials as= : Municipal Solid Waste, refinery wastes, agricultural surpluses or effluent= s, medical waste, industrial waste, shale oil, sour natural gas, and the huge= market of used tires are all converted in the Biosphere Process. LETH also= profits from the sale of electricity created from the waste conversion on = a continuous basis by generating 5 to 10 mega-watts per hour of electricity = which is then sold to replenish the local or national grid. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and = electrical management consulting services primarily for the US Government = with annual sales of $800 Million. Tetra Tech will coordinate permitting, = installation and continuous worldwide monitoring of the Biosphere Process = System for LETH. Tetra Tech is now in the process of obtaining Department = of Environmental Quality permitting for the Biosphere Process in the state= of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel= effect on LETH stock in the form of a huge near-term announcement. LETH has begun to catch the profit-making attention of investors by embracing a major foothold on the global waste problem while a major push = for generating electricity from alternative sources continues to be the ho= t topic due to shortages and massive power failures. LETH contains all the ingredients for major profits as global demand to solve two crisis areas, = waste and electrical energy, reaches unprecedented levels. We view this perfectly timed convergence of events as the catalyst for additional contr= acts that will perpetuate the shattering of the Company's own sales records. We= are seeing substantial gains for early investors in a ground floor opportu= nity that carries our highest rating for short-term trading profits. Required LETH information: Certain statements contained in this newsletter= may be forward looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe= ", "may", "will", and "intend" or similar terms may identify these statements= We are not a registered investment advisor or a broker dealer. This is not= an offer to buy or sell securities. No recommendation that the securities of = the companies profiled should be purchased, sold or held by individuals or entities that learn of the profiled companies. This is an independent electronic publication that was paid five thousand dollars by an unaffilia= ted third party for the preparation of this company information. Be advised th= at investments in companies profiled are considered to be high-risk and use o= f the content provided is for information purposes only. If anyone decides t= o act as an investor they are advised not to invest without the proper guida= nce from a financial advisor or a registered financial broker. If any party de= cides to participate as an investor then it will be that investor's sole risk. B= e advised that the purchase of such high-risk securities may result in the l= oss of some or all of the investment. Investors should not rely solely on the = information presented. Rather, investors should use the information provid= ed in this newsletter as a starting point for doing additional independent research on the profiled companies in order to allow the investor to form = their own opinion regarding investing in the profiled companies. Factual statements made about the profiled companies are made as of the date state= d and are subject to change without notice. Investing in micro-cap securitie= s is highly speculative and carries an extremely high degree of risk. All information provided about the profiled companies may include information = provided by outside sources, such as research reports, public filings, and= information provided by management of the profiled company. vvpfbb cu nqi --5FAAFAA42E_E_.971CB3--