From jameskyari202@netscape.net Wed Oct 1 13:46:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25348 for ; Wed, 1 Oct 2003 13:46:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4l3c-0002hb-00 for sctp-impl-archive@ietf.org; Wed, 01 Oct 2003 13:46:36 -0400 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 1A4l3c-0002gy-00 for sctp-impl-archive@ietf.org; Wed, 01 Oct 2003 13:46:36 -0400 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h91HjHxW000223 for ; Wed, 1 Oct 2003 10:45:18 -0700 (PDT) Received: from netscape700.com (62-177-188-59.bbeyond.nl [62.177.188.59]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h91HjdLD015478 for ; Wed, 1 Oct 2003 10:45:41 -0700 (PDT) Message-Id: <200310011745.h91HjdLD015478@sj-inbound-4.cisco.com> From: james kyari To: sctp-impl@external.cisco.com Reply-To: jameskyari202@netscape.net Subject: dear friend Date: Fri, 10 Jan 2003 18:45:09 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="304fb3e3-3b4f-4214-b5ee-25dace87cb17" This is a multi-part message in MIME format --304fb3e3-3b4f-4214-b5ee-25dace87cb17 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear friend, Compliment of the day, I am JAMES KYARI, The son of late General Kubwa Kyari of the Democratic Republic of Congo. My father was a General in the Congolese Army. In his position (My father) with the office of the presidentcy during the regime of Laurent Kabila, he was assigned on a secret mission to source and acquire arms internationally in order to strengthen the Government forces against the rebels, which already had the support of Rwandan and Uganda Army. Meanwhile, he was still negotiating for the purchase of the arms, he received on the 16th January 2001 news of the assassination of Laurent Kabila which force him to call off the assignment and deposited the sum of US$12.5M, Packed in a diplomatic case in a private security company in the Hague, the Netherlands, though he registered the content as precious stones while the real content is (US12.5M) meant for the purchase of arms for the Congolese Army. My father went home for the funeral of the late president, but on his arrival he was arrested, detained and tortured, unfortunately my father suffer cardiac arrest and died on the 17th of March 2001. However,one of our numerous visits, my mother and I paid him while in prison, my father was able to reveal this secret to me and advice that i should proceed to the Netherlands to claim the money, he handed me all the relevant documents that will enable me claim the box from the security company.Already, I have made my first visit to the security company and the document entitled to clear this money is with a finance security company in Holland. On our arrival in the Netherlands few months ago, we sought for political asylum; which was granted. My mother and I are making frantic effort on the best way to handle this money. We sought advice from an attorney who advised that we must seek for a trustworthy foreign business partner whom can invest this fund in a profitable venture. This we view as the best option because our refugee status dose not permit us to operate a bank account, hence we seek your assistance and hope you could be trusted. I got your contact from the commercial section of the congolese embassy in Belgium. Meanwhile, I sincerely ask for your assistance to get this money through your account, Your share for assisting us will be 25% of the total sum, 5% will be use for upsetting all the expenses incurred in the course of concluding this venture and the remaining 70% that will be for me and my family. Also you stand to gain from any investment you might introduce us into after the conclusion of the transfer. Please keep this confidential until we finalize and get this money into your account for security reasons. This is my e-mail address you can reach me:(jameskyari201@netscape.net) Thanks and GOD bless. MR, JAMES KYARI --304fb3e3-3b4f-4214-b5ee-25dace87cb17-- From olu_kris2@tiscali.co.uk Thu Oct 2 01:09:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20000 for ; Thu, 2 Oct 2003 01:09:09 -0400 (EDT) From: olu_kris2@tiscali.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4viE-0002hk-00 for sctp-impl-archive@ietf.org; Thu, 02 Oct 2003 01:09:14 -0400 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 1A4viD-0002hP-00 for sctp-impl-archive@ietf.org; Thu, 02 Oct 2003 01:09:14 -0400 Received: from tiscali.co.uk (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 22:14:10 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9257rXg020304 for ; Wed, 1 Oct 2003 22:07:53 -0700 (PDT) Received: from mk-smarthost-3.mail.uk.tiscali.com (mk-smarthost-3.mail.uk.tiscali.com [212.74.114.39]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9257Nx5004458 for ; Wed, 1 Oct 2003 22:07:24 -0700 (PDT) Received: from [212.74.114.3] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-3.mail.uk.tiscali.com with esmtp (Exim 4.20) id 1A4vcm-000CTx-LK; Thu, 02 Oct 2003 06:03:36 +0100 Received: from [81.23.193.84] by mk-cpfrontend.uk.tiscali.com with HTTP; Thu, 2 Oct 2003 03:41:50 +0100 Date: Thu, 2 Oct 2003 04:41:50 +0200 Message-ID: <3F7B62EF00000241@mk-cpfrontend-1.mail.uk.tiscali.com> Subject: URGENT ASSISTANCE To: olu_kris2@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable PLEASE REPLY WITH olu_kris2@masrawy.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dear SIR/MADAM Naturally, this letter will come to you as a surprise,since we have not met, permit me however,I am MR.OLUWALE KRIS. manager with Ecobank, incollaboration with my colleague Mr. James Egobia naccountant with the bank, we are contacting you andsoliciting for your assistance based on thisproposition below, which will be of mutual benefit toboth parties. PROPOSITION: A Salvadorean, Mr. Ramirez Sanchez, 66 years of ageand avery rosperous farmer and a business man made ahuge bank deposit for investme= nt in the sum ofUS$55,500,000.=3D (fifty five Million Five Hundred Thousand USDollars), he named his wife Mrs. Helga Sanchez as the NEXT OF KIN.Unfortunately, Mr.& Mrs.Ramirez Sanchez were killedin the January 14,= earthquake that rocked El Salvador,killing thousands of people and 1,200 others were declared missing.The management of bank has made several effo= rts through the ElSalvadorean High Commission in Lagos to contact any of the deceased family relatives, but tono avail. since the bank management was unable to reach any of te deceased family relatives,the option left for the Bank Management is to declare the deceased account dormant and revert the fund= s on trading and investment in the interest of the Bank and our bank system= stipulate that if such money remain with thE bank for priod of 3years it wil! l be tranfere into the account of the bankIn order to avoid this development, since it has sofar been impossible to trace any of the decea= sed family relatives,my colleaque james egobia and i now seek your personal permission and assistance to have you stand as a distant relativeto the deceased so that the fund will be released to you and we can use it for our mutual benefit. I hopeyou do understand my concern in this matter,if you are willing to assit us.For your assistance, you will be compensated adequatelywith (30%) of the total sum, (65%) will be our shar= e, while (5%) will be set aside to cover anyincidental expense made both at home and abroad priorto this transaction.If you are interested in assisti= ng us with thismatter,please, send to me urgently via my email thefollowing details below: 1. Your full name and complete contact address 2. Your Private telephone and fax number (urgent) 3.your date of birth (Age) 4, your account number/the telephone /fax number and address of the bank Base on this opportunity, Upon receiving the above details from you, we will work out every document/proof representing you as the deceased BONA-FIDE distant relative and when this isdone, you will be contacted by the bank for the release and collection of the fund, which will be within two week of our receiving the above details from you. We will meet with you in your country after the fund have been released to you and also to discuss investments potentials and have our share of hemoney to buy industrial good for resale in my country.May I assure you= that this transaction is 100% riskfree, as we have taken care of all necessarymodalities to enable a hitch-free transaction.Kindlyensure to treat this matter in strict privacy (highlyconfidential). We look forward to your urgent Response. Cheers andGod bless. Best Regards MR.OLUWALE KRIS From sksubha@axes-mach01.usa.alcatel.com Fri Oct 3 02:59:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24818 for ; Fri, 3 Oct 2003 02:59:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Juv-0004ZW-00 for sctp-impl-archive@ietf.org; Fri, 03 Oct 2003 02:59:58 -0400 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 1A5Juv-0004Yj-00 for sctp-impl-archive@ietf.org; Fri, 03 Oct 2003 02:59:57 -0400 Received: from axes-mach01.usa.alcatel.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 02 Oct 2003 23:59:35 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h936vdYb016004 for ; Thu, 2 Oct 2003 23:57:40 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h936w2VO023525 for ; Thu, 2 Oct 2003 23:58:03 -0700 (PDT) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h936uJYD014746 for ; Fri, 3 Oct 2003 01:56:25 -0500 (CDT) Received: from axsppc68 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4) id LAA25671; Fri, 3 Oct 2003 11:23:59 -0500 (GMT) Message-ID: <00a601c3897b$b0bc50a0$7601ff0a@axsppc68> From: "Subhashini" To: Subject: SCTP - Timer T1, RTO Min, RTO Intial and RTO Max Date: Fri, 3 Oct 2003 12:27:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C389A9.C47C3AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C389A9.C47C3AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I want to know the usage of retransmission timers RTO Inital, RTO Min = and RTO Max during Init procedure. i.e after the expiry of T1-INIT = timer, the timer value of T1 should be set with what value? There is one = more configurable paramter "Max Init Retransmission" to tell how many = times INIT should be transmitted before to decide to abort the = association. Please tell me the usage of all these timers and this = configurable parameter during INIT procedure. Should the difference between the first INIT transfer and the second = INIT trasnsfer be close to RTO Min? If so, what should be the diffrence = between the successive INIT transmissions? Please clarify. thanks, Subhshini ... ------=_NextPart_000_00A1_01C389A9.C47C3AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I want to know the usage of = retransmission timers=20 RTO Inital, RTO Min and RTO Max during Init procedure. i.e after the = expiry of=20 T1-INIT timer, the timer value of T1 should be set with what value? = There is one=20 more configurable paramter "Max Init Retransmission" to tell how many = times INIT=20 should be transmitted before to decide to abort the association. Please = tell me=20 the usage of all these timers and this configurable parameter during = INIT=20 procedure.
Should the difference between the first = INIT=20 transfer and the second INIT trasnsfer be close to RTO Min? If so, what = should=20 be the diffrence between the successive INIT transmissions? Please=20 clarify.
 
thanks,
Subhshini = ...
------=_NextPart_000_00A1_01C389A9.C47C3AA0-- From Ivan.Arias-Rodriguez@nokia.com Fri Oct 3 10:13:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08714 for ; Fri, 3 Oct 2003 10:13:46 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Qgs-0001JZ-00 for sctp-impl-archive@ietf.org; Fri, 03 Oct 2003 10:13:54 -0400 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 1A5Qgr-0001J7-00 for sctp-impl-archive@ietf.org; Fri, 03 Oct 2003 10:13:53 -0400 Received: from nokia.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2003 07:13:33 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h93EB5Js016460 for ; Fri, 3 Oct 2003 07:11:06 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h93EAlVO006365 for ; Fri, 3 Oct 2003 07:11:28 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h93Dwvt04214 for ; Fri, 3 Oct 2003 16:58:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 Oct 2003 16:58:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 3 Oct 2003 16:58:57 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 3 Oct 2003 16:58:56 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 3 Oct 2003 16:58:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SCTP - Timer T1, RTO Min, RTO Intial and RTO Max Date: Fri, 3 Oct 2003 16:58:56 +0300 Message-ID: Thread-Topic: SCTP - Timer T1, RTO Min, RTO Intial and RTO Max Thread-Index: AcOJe+dKlTPIza0dRSKmrLTKb0krAAAOQuwA To: , X-OriginalArrivalTime: 03 Oct 2003 13:58:56.0677 (UTC) FILETIME=[7CC3DD50:01C389B6] Content-Transfer-Encoding: quoted-printable Hi Subhshini! The RTO is the time you wait before you consider an unacknowledged = datagram to be lost. The minimum and maximum values of RTO are recommended to be 1 second = and 1 minute respectively. If you don't have packet losses, RTO will = typically be set to RTO Min, as the RTT is normally some tens of = millisecond. However, at the very beginning, when sending the first INIT, you set = the RTO to Initial RTO, which is 3 seconds. If after 3 seconds you don't = receive the INIT ACK, you retransmit the INIT and as usual, you double = the value of RTO, thus becoming 6 seconds. Then after a second time out, = you set RTO to 12, 24, 48 and after that it is set to 60 and doesn't = change... And about the retransmission counters. You retransmit the INIT up to 8 = times. In the way I understand this, you can send up to 9 INITs (first = one and 8 retransmissions). Once you have already established the = association, that maximum number is increased to 10.=20 And by the way, RTO Initial, RTO Min and RTO Max are not timers. They = are the recommended values to be used with the timers, which are T1, = T3... I hope it helped! BR Iv=E1n Arias Rodr=EDguez -----Original Message----- From: ext Subhashini [mailto:sksubha@axes-mach01.usa.alcatel.com] Sent: Friday, 03 October, 2003 9:58 To: sctp-impl@external.cisco.com Subject: SCTP - Timer T1, RTO Min, RTO Intial and RTO Max Hi, I want to know the usage of retransmission timers RTO Inital, RTO Min = and RTO Max during Init procedure. i.e after the expiry of T1-INIT = timer, the timer value of T1 should be set with what value? There is one = more configurable paramter "Max Init Retransmission" to tell how many = times INIT should be transmitted before to decide to abort the = association. Please tell me the usage of all these timers and this = configurable parameter during INIT procedure. Should the difference between the first INIT transfer and the second = INIT trasnsfer be close to RTO Min? If so, what should be the diffrence = between the successive INIT transmissions? Please clarify. thanks, Subhshini ... From jonekimportexport@eircom.net Mon Oct 6 23:59:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04518 for ; Mon, 6 Oct 2003 23:59:57 -0400 (EDT) From: jonekimportexport@eircom.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6j13-0000Ct-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 00:00:05 -0400 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 1A6j12-0000Ci-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 00:00:05 -0400 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h973vmcZ016602 for ; Mon, 6 Oct 2003 20:57:48 -0700 (PDT) Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h973wCLD004086 for ; Mon, 6 Oct 2003 20:58:13 -0700 (PDT) Message-Id: <200310070358.h973wCLD004086@sj-inbound-4.cisco.com> Received: (qmail 72569 messnum 214296 invoked from network[159.134.237.77/webmail00.eircom.net]); 7 Oct 2003 03:57:04 -0000 Received: from webmail00.eircom.net (HELO webmail.eircom.net) (159.134.237.77) by mail03.svc.cra.dublin.eircom.net (qp 72569) with SMTP; 7 Oct 2003 03:57:04 -0000 To: jonekimport@eircom.net Subject: URGENT REPLEY (CONFIIDENTIAL) Date: Tue, 7 Oct 2003 03:41:49 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 81.23.193.84 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Content-Transfer-Encoding: 8bit TEL/FAX; 234 42 253423 , TEL 234 80 46111478 ATTN; MUTUAL BUSINESS BETWEEN YOU AND I I humbly wish to solicit for your assistance in this business that will be of mutual benefit to you and I. I am Jonathan Aneke, the son of the late Nigerian minister of Finance, between 1999. I have within my reach funds in cash totaling US$25.2m (Twenty five million, two Hundred thousand Dollars) which I want to move out of Nigeria. But considering status, I know I cannot lay claim to this money now until I transfer it out of Nigeria.I will require your assistance and sincerity as in presenting you as the sole beneficially of this funds so that this funds-in-cash will be paid into your account in any part of the world excluding Nigeria and also advice me on any Lucrative business which we could invest this money into your country. Presently, this aforementioned funds-in-cash is in Nigeria and upon a favourable response from you, I will let you know how to receive this money without any problem. Your commission will be down payment 25% of the total sum if you assist me move out this funds-in-cash out from Africa.Note that this project is 100% risk free, thus, the government of Nigeria is not aware that I am in possession of this particular batch of funds-in-cash.I expect your urgent and favourable response via Fax.Please remember to keep this issue a top secret Best Regards Dr Jonathan Aneke From ajung@exp-math.uni-essen.de Tue Oct 7 08:44:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29299 for ; Tue, 7 Oct 2003 08:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6rD8-0004vk-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 08:45:06 -0400 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 1A6rD7-0004va-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 08:45:05 -0400 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h97ChPYb006849 for ; Tue, 7 Oct 2003 05:43:26 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h97Cgsx5005085 for ; Tue, 7 Oct 2003 05:42:55 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8-20030924/8.12.8) with ESMTP id h97CdUWO044076 for ; Tue, 7 Oct 2003 14:39:30 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: Subject: Question: Which address to choose... Date: Tue, 7 Oct 2003 14:42:04 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310071442.15727.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I just stumbled across a (probably stupid) little question, the answer for which I could not find in the RFC 2960 (or imp guide which I scanned for this topic) : Suppose, endpoint A and endpoint B are both dual-homed. The primary path for both is A1<->B1, secondary path is A2<->B2. Now, A has received the last valid data from B on the secondary path, has started a SACK-timer, and its user wants to send NEW data over=20 the primary path. The outgoing SCTP packet carries a SACK along with the new data. Which rule gets precedence: =2D - send all new data over the primary path (initial transmission). =2D - send the SACK back to the address where the last data came from Where does it say so in the specs ? Best regards, Andreas =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/grSnXAsLBNOCSsARAmldAJwL23bzloAD8RYNLujdCM4CTwckIwCfQ+n3 xkKQ6Cf/4QFtxrwZDevc/MQ=3D =3DtE9T =2D----END PGP SIGNATURE----- From randall@stewart.chicago.il.us Tue Oct 7 09:02:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29732 for ; Tue, 7 Oct 2003 09:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6rUS-000563-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 09:03:00 -0400 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 1A6rUR-00055h-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 09:03:00 -0400 Received: from stewart.chicago.il.us (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2003 06:09:58 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h97D1FJs029801 for ; Tue, 7 Oct 2003 06:01:15 -0700 (PDT) Received: from stewart.chicago.il.us (stewart.chicago.il.us [66.93.186.36]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h97D1eVO025696 for ; Tue, 7 Oct 2003 06:01:41 -0700 (PDT) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h97Cv9Ii000763 for ; Tue, 7 Oct 2003 07:57:11 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3F82B823.70203@stewart.chicago.il.us> Date: Tue, 07 Oct 2003 07:57:07 -0500 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: patch 12 for the kame release Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings SCTP'ers Patch 12 is now available on the http://www.sctp.org web site. I will be submitting these to kame this week and hopefully they will get assimulated shortly.. but for now you can find them locally until then :> Note also, it has been reported to me that the mozilla download on the web site has a rather interesting bug... it does not resolve things so you must put in: http://66.93.186.36 This is probably due to an error we in-advertantly put in .. not sure.. but it is good to be aware of this at least :> Happy SCTPing R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From rrs@cisco.com Tue Oct 7 09:23:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00838 for ; Tue, 7 Oct 2003 09:23:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6rom-0005RV-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 09:24:00 -0400 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 1A6rol-0005Qu-00 for sctp-impl-archive@ietf.org; Tue, 07 Oct 2003 09:24:00 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2003 06:31:10 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h97DMiJs014230; Tue, 7 Oct 2003 06:22:44 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMW67073; Tue, 7 Oct 2003 06:22:43 -0700 (PDT) Message-ID: <3F82BE21.8050807@cisco.com> Date: Tue, 07 Oct 2003 08:22:41 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andreas Jungmaier CC: sctp-impl@external.cisco.com Subject: Re: Question: Which address to choose... References: <200310071442.15727.ajung@exp-math.uni-essen.de> In-Reply-To: <200310071442.15727.ajung@exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andreas Jungmaier wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi all, > >I just stumbled across a (probably stupid) little question, the answer >for which I could not find in the RFC 2960 (or imp guide which I scanned >for this topic) : > >Suppose, endpoint A and endpoint B are both dual-homed. >The primary path for both is A1<->B1, secondary path is A2<->B2. > >Now, A has received the last valid data from B on the secondary path, >has started a SACK-timer, and its user wants to send NEW data over >the primary path. > >The outgoing SCTP packet carries a SACK along with the new data. > >Which rule gets precedence: >- - send all new data over the primary path (initial transmission). >- - send the SACK back to the address where the last data came from > Andreas: I don't think it is specific in the spec. If you look at the rule: "- - send the SACK back to the address where the last data came from" Its not really quite stated that way... its An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. Now we discussed the reply chunk in detail and specifically left the rule as a "SHOULD" since there are times when you don't want to send back to the place it came from.. your example is one of these...(we had talked about making it a MUST in early discussions.. and that just made no sense). I would think you as an implementor have a number of choices: 1) Bundle the DATA and the SACK and send it to the primary 2) Send just the DATA to the primary and then when the Rcv timer pops, send a SACK to the address the data came from. and I guess you could even go so far as to 3) bundle the DATA with the SACK to the last place the data came from. All of the above our legal and don't violate the spec... however I would recommend either 1 or 2. This for a number of reasons: 1) You are already in theory sending DATA to the primary, so it is likely to have the best cwnd to allow your data to go out. 2) You probably (aka same reason as 1) have a better RTT estimate of the primary 3) Its where you picked as the primary and where the user "expects" (if he/she expects at all) the data to go. Now I would bundle the sack and data if possible but either choice would be ok... sometimes they won't all fit together (as we know) depending on the size of the chunks :> Not that I have answered your questions.. other than the fact that any choice is legal.. its just some may be better for performance than others :> R > >Where does it say so in the specs ? > >Best regards, >Andreas > >- -- >Dipl.-Ing. Andreas Jungmaier >Computer Networking Technology Group >University of Duisburg-Essen >http://www.exp-math.uni-essen.de/~ajung >PGP Key-ID: D382 4AC0 > >PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) > >iD8DBQE/grSnXAsLBNOCSsARAmldAJwL23bzloAD8RYNLujdCM4CTwckIwCfQ+n3 >xkKQ6Cf/4QFtxrwZDevc/MQ= >=tE9T >-----END PGP SIGNATURE----- > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From ajung@exp-math.uni-essen.de Wed Oct 8 05:21:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07342 for ; Wed, 8 Oct 2003 05:21:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7AVp-0002Zn-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 05:21:41 -0400 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 1A7AVo-0002ZG-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 05:21:40 -0400 Received: from exp-math.uni-essen.de (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 02:22:04 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h989KBYb019039 for ; Wed, 8 Oct 2003 02:20:12 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h989GlVQ000261 for ; Wed, 8 Oct 2003 02:20:36 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8-20030924/8.12.8) with ESMTP id h989GCWO068574; Wed, 8 Oct 2003 11:16:13 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: "Randall Stewart (cisco)" , sctp-impl@external.cisco.com Subject: Re: Question: Which address to choose... Date: Wed, 8 Oct 2003 11:18:52 +0200 User-Agent: KMail/1.5.2 References: <200310071442.15727.ajung@exp-math.uni-essen.de> <3F82BE21.8050807@cisco.com> In-Reply-To: <3F82BE21.8050807@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310081118.59007.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Randy, dear all, I stumbled across this question when I was testing my new OPNET simulation model (which is coming along nicely after I sorted out some initial problems): I simulated a path failure of the primary path. Both endpoints A and B are continually sending data. Now, when B sends retransmissions=20 over the secondary path, and A in turn sends [SACK+New Data] chunks over th= e=20 primary (where they are dropped), B's retransmissions actually come=20 through (as they are sent over the secondary), but B only learns of this after the third retransmission (second retransmission takes the primary path again), when A receives duplicate TSNs and immediatly returns the SACK over the secondary (as per section 6.2 of RFC 2960). In this case, the behaviour is not optimal, I think, and I was kind of surprised by this when I had the simulation run :-) Or am I overlooking something ? Best regards, Andreas On Tuesday 07 October 2003 15:22, Randall Stewart (cisco) wrote: > Andreas Jungmaier wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Suppose, endpoint A and endpoint B are both dual-homed. > >The primary path for both is A1<->B1, secondary path is A2<->B2. > > > >Now, A has received the last valid data from B on the secondary path, > >has started a SACK-timer, and its user wants to send NEW data over > >the primary path. > > > >The outgoing SCTP packet carries a SACK along with the new data. > > > >Which rule gets precedence: > >- - send all new data over the primary path (initial transmission). > >- - send the SACK back to the address where the last data came from > > Andreas: > > I don't think it is specific in the spec. If you look at the rule: > > "- - send the SACK back to the address where the last data came from" > > > Its not really quite stated that way... its > > An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, > etc.) to the same destination transport address from which it > received the DATA or control chunk to which it is replying. This > rule should also be followed if the endpoint is bundling DATA chunks > together with the reply chunk. > > Now we discussed the reply chunk in detail and specifically left > the rule as a "SHOULD" since there are times when you > don't want to send back to the place it came from.. your example > is one of these...(we had talked about making it a MUST in > early discussions.. and that just made no sense). > > I would think you as an implementor have a number of choices: > > 1) Bundle the DATA and the SACK and send it to the primary > > 2) Send just the DATA to the primary and then when the > Rcv timer pops, send a SACK to the address the data came from. > > and I guess you could even go so far as to > > 3) bundle the DATA with the SACK to the last place the data > came from. > > All of the above our legal and don't violate the spec... however I would > recommend either 1 or 2. > > This for a number of reasons: > > 1) You are already in theory sending DATA to the primary, so it is > likely to have the best cwnd to allow your data to go out. > 2) You probably (aka same reason as 1) have a better RTT estimate > of the primary > 3) Its where you picked as the primary and where the user "expects" (if > he/she expects at all) the data to go. > > Now I would bundle the sack and data if possible but either choice would > be ok... sometimes they won't all fit together (as we know) depending on > the size > of the chunks :> > > Not that I have answered your questions.. other than the fact that any > choice is legal.. its just some may be better for performance than others > :> > > R > =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/g9aCXAsLBNOCSsARAkdJAJ48NHJiCwc1LF84EeaoOjw0bhbWMgCgoR5C ZQ4f1EPYMJ6Us9mLCdsP8b0=3D =3DeRrH =2D----END PGP SIGNATURE----- From akiluakilu@tiscali.co.uk Wed Oct 8 08:46:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12138 for ; Wed, 8 Oct 2003 08:46:40 -0400 (EDT) From: akiluakilu@tiscali.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7DiK-0004Ni-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 08:46:48 -0400 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 1A7DiJ-0004NG-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 08:46:47 -0400 Received: from tiscali.co.uk (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 05:47:11 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h98Cj7Js025284 for ; Wed, 8 Oct 2003 05:45:08 -0700 (PDT) Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h98CjXVO003387 for ; Wed, 8 Oct 2003 05:45:33 -0700 (PDT) Received: from [212.74.114.4] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 4.20) id 1A7Dcj-00005i-67; Wed, 08 Oct 2003 13:41:01 +0100 Received: from [216.147.153.164] by mk-cpfrontend.uk.tiscali.com with HTTP; Wed, 8 Oct 2003 13:41:01 +0100 Date: Wed, 8 Oct 2003 13:41:01 +0100 Message-ID: <3F818C8B00006883@mk-cpfrontend-2.mail.uk.tiscali.com> Subject: YOUR RESPONSE IS NEEDED To: akiluakilu@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable DEAR SIR, I KNOW THIS PROPOSAL WILL COME TO YOU AS A SURPRISE ESPECIALLY WHEN YOU DO NOT KNOW THE WRITER, CONDSIDERING THE HUGE SUM OF MONEY INVOLVED WHICH= COULD MAKE ANY APPREHENSIVE. LET ME START BY INTRODUCING MYSELF TO YOU, I AM MRS AKILU MARIAM, DIRECTOR CREDIT CONTROL, UNION BANK OF NIGERIA PLC. LAGOS. I SAW YOUR CONTACT DURING MY PRIVATE SEARCH AT THE INFORMATION CENTRE HERE IN NIGERIA CHAMBER OF COMME= RCE AND INDUSTRY AND I WANT TO BELIEVE THAT YOU WILL BE VERY HONEST, COMMITTE= D AND CAPABLE OF ASSISTING IN THIS BUSINESS VENTURE. FIRSTLY, LET ME EXPLAIN THE SOURCE OF THIS FUNDS AND WHAT YOU ARE EXPECTED TO DO. A FORIGNER LATE ENGINEER THEOPHILUS BAKE= R, AN OIL MERCHANT/CONTRACTOR WITH THE GOVERNMENT OF NIGERIA, UNTIL HIS DEATH, OVER A YEAR AGO, WAS A VICTIM OFA KENYA AIRWAYS: BUS (A310-300) FLIGHT KQ430 PLANE CRASH. THE DE= CEASED, ENGNIEER THEOPILIUS BAKER, BANKED WITH US AND HAS A CLOSING BALANCE AS A JULY 2000 WORTH $6.8m (SIX MILLION EIGHT HUNDRED THOUSAND USD). WHICH MY BANK, NOW EXPECTES A NEXT-OF-KIN TO CLAIM AS THE BENEFICIARY OF THE FUNDS, EFFORTS HAS BEEN MADE BY UNION BANK OF NIGERIA TO GET IN TOUCH= WITH THE BAKER'S FAMILY OR RELATIVE BUT TO NO SUCCESS. BASED ON THE PERCEIVED POSSIBILITY OF NOT BEING ABLE TO LOCATE ENGNIEER THEOPILUS'S NEXT-OF-KIN,= THE MANAGEMENT UNDER THE INFLUENCE OF OUR CHAIRMAN AND THE BOARD OF DIRECTORS ARE MAKING ARRANGEMENTS FOR THE FUNDS TO BE DECLARED UNCLAIMED AND CHANNELED TO AN UNKNOWN ACCOUNT. IT IS BASED ON THIS THAT WE HAVE CONTACTED YOU TO STAND AS THE NEXT-OF-KI= N OF LATE ENGR. THEOPILUS BAKER SO THAT THE FUNDS, WILL BE RELEASED AND PAID INTO YOUR ACCOUNT AS THE BENEFICIARY AND= THE NEXT-OF-KIN TO THE DECEASED. ALL DOCUMENTS, AND PROOF TO ENABLE YOU GET THE FUNDS HAVE BEEN CAREFULLY WORKED OUT AS WE HAVE SECURED FROM THE DIFFERENT OFFICES CONCERNED FOR THE SMOOTH TRANSFER OF THE FUND TO YOUR NOMINATED ACCOUNT.IT HAS BEEN AGREED THAT THE OWNER OF THE ACCOUNT WILL BE COMPENSATED WITH 20% OF THE REMITTED FUNDS, WHILE WE KEEP 75% AND 5% WILL BE SET ASIDE TO OFFSET EXPENSES AND PAY THE NECESSARY TAXES. IF THIS= PROPOSAL SATISFIES YOU, PLEASE REACH US ONLY BY MAIL FOR NOW,AT bans_marr= y@yahoo.com WAITING TO HEAR FROM YOU SOON. REGARDS MRS AKILU MARIAM(DIRECTOR CREDIT CONTROL UNION BANK PLC) From acaro@mail.eecis.udel.edu Wed Oct 8 19:55:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15545 for ; Wed, 8 Oct 2003 19:55:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7O9Q-00067L-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 19:55:28 -0400 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 1A7O9Q-000673-00 for sctp-impl-archive@ietf.org; Wed, 08 Oct 2003 19:55:28 -0400 Received: from mail.eecis.udel.edu (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2003 17:03:02 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h98NsCJs013259 for ; Wed, 8 Oct 2003 16:54:12 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h98Nrfx5007261 for ; Wed, 8 Oct 2003 16:53:42 -0700 (PDT) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A2AA7328C5; Wed, 8 Oct 2003 19:42:49 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 8F9803288F; Wed, 8 Oct 2003 19:42:48 -0400 (EDT) Date: Wed, 8 Oct 2003 19:42:48 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Andreas Jungmaier Cc: "Randall Stewart (cisco)" , Subject: Re: Question: Which address to choose... In-Reply-To: <200310081118.59007.ajung@exp-math.uni-essen.de> Message-ID: X-Spam-Status: No, hits=-5.5 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" I'm not sure about others, but I am having a hard time following your example and the problem you describe. Can you reword the scenario? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Wed, 8 Oct 2003, Andreas Jungmaier wrote: > WARNING: Unsanitized content follows. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Randy, dear all, > > I stumbled across this question when I was testing my new OPNET > simulation model (which is coming along nicely after I sorted out > some initial problems): > I simulated a path failure of the primary path. Both endpoints A > and B are continually sending data. Now, when B sends retransmissions > over the secondary path, and A in turn sends [SACK+New Data] chunks over the > primary (where they are dropped), B's retransmissions actually come > through (as they are sent over the secondary), but B only learns > of this after the third retransmission (second retransmission takes > the primary path again), when A receives duplicate TSNs and immediatly > returns the SACK over the secondary (as per section 6.2 of RFC 2960). > > In this case, the behaviour is not optimal, I think, and I was kind > of surprised by this when I had the simulation run :-) > Or am I overlooking something ? > > Best regards, > Andreas > > On Tuesday 07 October 2003 15:22, Randall Stewart (cisco) wrote: > > Andreas Jungmaier wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >Suppose, endpoint A and endpoint B are both dual-homed. > > >The primary path for both is A1<->B1, secondary path is A2<->B2. > > > > > >Now, A has received the last valid data from B on the secondary path, > > >has started a SACK-timer, and its user wants to send NEW data over > > >the primary path. > > > > > >The outgoing SCTP packet carries a SACK along with the new data. > > > > > >Which rule gets precedence: > > >- - send all new data over the primary path (initial transmission). > > >- - send the SACK back to the address where the last data came from > > > > Andreas: > > > > I don't think it is specific in the spec. If you look at the rule: > > > > "- - send the SACK back to the address where the last data came from" > > > > > > Its not really quite stated that way... its > > > > An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, > > etc.) to the same destination transport address from which it > > received the DATA or control chunk to which it is replying. This > > rule should also be followed if the endpoint is bundling DATA chunks > > together with the reply chunk. > > > > Now we discussed the reply chunk in detail and specifically left > > the rule as a "SHOULD" since there are times when you > > don't want to send back to the place it came from.. your example > > is one of these...(we had talked about making it a MUST in > > early discussions.. and that just made no sense). > > > > I would think you as an implementor have a number of choices: > > > > 1) Bundle the DATA and the SACK and send it to the primary > > > > 2) Send just the DATA to the primary and then when the > > Rcv timer pops, send a SACK to the address the data came from. > > > > and I guess you could even go so far as to > > > > 3) bundle the DATA with the SACK to the last place the data > > came from. > > > > All of the above our legal and don't violate the spec... however I would > > recommend either 1 or 2. > > > > This for a number of reasons: > > > > 1) You are already in theory sending DATA to the primary, so it is > > likely to have the best cwnd to allow your data to go out. > > 2) You probably (aka same reason as 1) have a better RTT estimate > > of the primary > > 3) Its where you picked as the primary and where the user "expects" (if > > he/she expects at all) the data to go. > > > > Now I would bundle the sack and data if possible but either choice would > > be ok... sometimes they won't all fit together (as we know) depending on > > the size > > of the chunks :> > > > > Not that I have answered your questions.. other than the fact that any > > choice is legal.. its just some may be better for performance than others > > :> > > > > R > > > - -- > Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE/g9aCXAsLBNOCSsARAkdJAJ48NHJiCwc1LF84EeaoOjw0bhbWMgCgoR5C > ZQ4f1EPYMJ6Us9mLCdsP8b0= > =eRrH > -----END PGP SIGNATURE----- > From ajung@exp-math.uni-essen.de Thu Oct 9 05:46:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13791 for ; Thu, 9 Oct 2003 05:46:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7XNX-0004OK-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 05:46:39 -0400 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 1A7XNX-0004O7-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 05:46:39 -0400 Received: from exp-math.uni-essen.de (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 02:54:19 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h999j9Lt027398 for ; Thu, 9 Oct 2003 02:45:10 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h999fiVQ015369 for ; Thu, 9 Oct 2003 02:45:34 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8-20030924/8.12.8) with ESMTP id h999fAWO034074; Thu, 9 Oct 2003 11:41:10 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: "Armando L. Caro Jr." Subject: Re: Question: Which address to choose... Date: Thu, 9 Oct 2003 11:43:54 +0200 User-Agent: KMail/1.5.2 Cc: "Randall Stewart (cisco)" , References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310091143.57879.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Armando, I will try: 0-----0 (A1)----------------PRIMARY----------------(B1) 0-----0 | A | | B | 0-----0 (A2)----------------SECONDARY--------------(B2) 0-----0 Both endpoints A and B are continuously sending data towards the peer over the primary path. At some time T the primary path fails (e.g. due to a hardware failure). T3 times out (say for B) after the RTO (of the primary path of B). B retransmits the earliest outstanding chunks over the secondary path, towards A2. When the retransmitted chunks arrive on A2, A will start a=20 SACK timer to expire after 200 ms (assuming that that is the SACK delay). Now, since A still sends new data chunks continuously over the primary path (towards B1), it may happen that when the SACK timer is running, the SACK is bundled with the outgoing new data, and is sent over the primary path. Where it is dropped, of course. Then, T3 will expire again for B, this time indicating that the chunks sent (and: retransmitted) to the secondary path have not been ack'ed. Then these are retransmitted again, over an alternate path, and this time over the primary, where they are dropped again. Then the T3 timer will expire for the primary path, and retransmit the earliest outstanding bytes over the secondary path. When this retransmission arrives at A, it is ack'ed at once (since the TSNs are duplicates) and the path error counter and association error counter are reset for the secondary path and the association, respectively. This behaviour initially struck me as weird, and I thought that I was either overlooking something in my simulation model, or had implemented the specs in an incorrect way. The way I handle this now is: if a SACK timer is running and the next outgoing data goes to a path that is different from the path where the last data arrived from, then leave the SACK timer running, and do not bundle the SACK at once, but send it back to the path where last data arrived from (which is solution 2 mentioned in Randy's earlier posting). Hope that clears the clouds :-) Best regards, Andreas On Thursday 09 October 2003 01:42, Armando L. Caro Jr. wrote: > I'm not sure about others, but I am having a hard time following your > example and the problem you describe. Can you reword the scenario? > > ~armando > > > In this case, the behaviour is not optimal, I think, and I was kind > > of surprised by this when I had the simulation run :-) > > Or am I overlooking something ? > > > > > > > > Andreas: > > > > > > I don't think it is specific in the spec. If you look at the rule: > > > > > > "- - send the SACK back to the address where the last data came from" > > > > > > > > > Its not really quite stated that way... its > > > > > > An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, > > > etc.) to the same destination transport address from which it > > > received the DATA or control chunk to which it is replying. This > > > rule should also be followed if the endpoint is bundling DATA chun= ks > > > together with the reply chunk. > > > > > > Now we discussed the reply chunk in detail and specifically left > > > the rule as a "SHOULD" since there are times when you > > > don't want to send back to the place it came from.. your example > > > is one of these...(we had talked about making it a MUST in > > > early discussions.. and that just made no sense). > > > > > > I would think you as an implementor have a number of choices: > > > > > > 1) Bundle the DATA and the SACK and send it to the primary > > > > > > 2) Send just the DATA to the primary and then when the > > > Rcv timer pops, send a SACK to the address the data came from. > > > > > > and I guess you could even go so far as to > > > > > > 3) bundle the DATA with the SACK to the last place the data > > > came from. > > > > > > All of the above our legal and don't violate the spec... however I > > > would recommend either 1 or 2. > > > > > > This for a number of reasons: > > > > > > 1) You are already in theory sending DATA to the primary, so it is > > > likely to have the best cwnd to allow your data to go out. > > > 2) You probably (aka same reason as 1) have a better RTT estimate > > > of the primary > > > 3) Its where you picked as the primary and where the user "expects" (= if > > > he/she expects at all) the data to go. > > > > > > Now I would bundle the sack and data if possible but either choice > > > would be ok... sometimes they won't all fit together (as we know) > > > depending on the size > > > of the chunks :> > > > > > > Not that I have answered your questions.. other than the fact that any > > > choice is legal.. its just some may be better for performance than > > > others > > > > > > > > > R > > > > - -- > > Dipl.-Ing. Andreas Jungmaier > > Computer Networking Technology Group > > University of Duisburg-Essen > > http://www.exp-math.uni-essen.de/~ajung > > PGP Key-ID: D382 4AC0 > > > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.2 (GNU/Linux) > > > > iD8DBQE/g9aCXAsLBNOCSsARAkdJAJ48NHJiCwc1LF84EeaoOjw0bhbWMgCgoR5C > > ZQ4f1EPYMJ6Us9mLCdsP8b0=3D > > =3DeRrH > > -----END PGP SIGNATURE----- =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/hS3aXAsLBNOCSsARAhszAKCG8A3RmvhrmZZSImUJufnw44CQNwCdHB3d H+BbcPaYkdkp+oCjWi2nL2Y=3D =3DB8Vm =2D----END PGP SIGNATURE----- From bidulock@openss7.org Thu Oct 9 06:47:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15067 for ; Thu, 9 Oct 2003 06:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7YK8-0004sQ-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 06:47:12 -0400 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 1A7YK7-0004rt-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 06:47:11 -0400 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h99AjuLt018638 for ; Thu, 9 Oct 2003 03:45:56 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h99AkGVO012338 for ; Thu, 9 Oct 2003 03:46:21 -0700 (PDT) Received: from ns.pigworks.openss7.net (IDENT:xNogSa/98Iiqr3GlAN3Aeah0RlH/lK3S@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h99Agea13753; Thu, 9 Oct 2003 04:42:40 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h99AgeA10413; Thu, 9 Oct 2003 04:42:40 -0600 Date: Thu, 9 Oct 2003 04:42:40 -0600 From: "Brian F. G. Bidulock" To: Andreas Jungmaier Cc: "Armando L. Caro Jr." , "Randall Stewart (cisco)" , sctp-impl@external.cisco.com Subject: Re: Question: Which address to choose... Message-ID: <20031009044240.A10348@openss7.org> Reply-To: bidulock@openss7.org References: <200310091143.57879.ajung@exp-math.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310091143.57879.ajung@exp-math.uni-essen.de>; from ajung@exp-math.uni-essen.de on Thu, Oct 09, 2003 at 11:43:54AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Return-Receipt-To: Content-Transfer-Encoding: 8bit Andreas, I don't understand how B's T3 timer can timeout three times (presumably being doubled each time) before A's T3 timer expires the first time. Could you please explain? --brian On Thu, 09 Oct 2003, Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Armando, > > I will try: > > 0-----0 (A1)----------------PRIMARY----------------(B1) 0-----0 > | A | | B | > 0-----0 (A2)----------------SECONDARY--------------(B2) 0-----0 > > Both endpoints A and B are continuously sending data towards the > peer over the primary path. At some time T the primary path fails > (e.g. due to a hardware failure). > T3 times out (say for B) after the RTO (of the primary path of B). > B retransmits the earliest outstanding chunks over the secondary > path, towards A2. > When the retransmitted chunks arrive on A2, A will start a > SACK timer to expire after 200 ms (assuming that that is the > SACK delay). > > Now, since A still sends new data chunks continuously over the > primary path (towards B1), it may happen that when the SACK timer > is running, the SACK is bundled with the outgoing new data, and is > sent over the primary path. Where it is dropped, of course. > > Then, T3 will expire again for B, this time indicating that the chunks > sent (and: retransmitted) to the secondary path have not been ack'ed. > Then these are retransmitted again, over an alternate path, > and this time over the primary, where they are dropped again. > > Then the T3 timer will expire for the primary path, and retransmit > the earliest outstanding bytes over the secondary path. When this > retransmission arrives at A, it is ack'ed at once (since the TSNs > are duplicates) and the path error counter and association error counter > are reset for the secondary path and the association, respectively. > > This behaviour initially struck me as weird, and I thought that I was either > overlooking something in my simulation model, or had implemented the specs > in an incorrect way. > > The way I handle this now is: if a SACK timer is running and the > next outgoing data goes to a path that is different from the path > where the last data arrived from, then leave the SACK timer running, > and do not bundle the SACK at once, but send it back to the path > where last data arrived from (which is solution 2 mentioned in > Randy's earlier posting). > > Hope that clears the clouds :-) > > Best regards, > Andreas > > On Thursday 09 October 2003 01:42, Armando L. Caro Jr. wrote: > > I'm not sure about others, but I am having a hard time following your > > example and the problem you describe. Can you reword the scenario? > > > > ~armando > > > > > > In this case, the behaviour is not optimal, I think, and I was kind > > > of surprised by this when I had the simulation run :-) > > > Or am I overlooking something ? > > > > > > > > > > > Andreas: > > > > > > > > I don't think it is specific in the spec. If you look at the rule: > > > > > > > > "- - send the SACK back to the address where the last data came from" > > > > > > > > > > > > Its not really quite stated that way... its > > > > > > > > An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, > > > > etc.) to the same destination transport address from which it > > > > received the DATA or control chunk to which it is replying. This > > > > rule should also be followed if the endpoint is bundling DATA chunks > > > > together with the reply chunk. > > > > > > > > Now we discussed the reply chunk in detail and specifically left > > > > the rule as a "SHOULD" since there are times when you > > > > don't want to send back to the place it came from.. your example > > > > is one of these...(we had talked about making it a MUST in > > > > early discussions.. and that just made no sense). > > > > > > > > I would think you as an implementor have a number of choices: > > > > > > > > 1) Bundle the DATA and the SACK and send it to the primary > > > > > > > > 2) Send just the DATA to the primary and then when the > > > > Rcv timer pops, send a SACK to the address the data came from. > > > > > > > > and I guess you could even go so far as to > > > > > > > > 3) bundle the DATA with the SACK to the last place the data > > > > came from. > > > > > > > > All of the above our legal and don't violate the spec... however I > > > > would recommend either 1 or 2. > > > > > > > > This for a number of reasons: > > > > > > > > 1) You are already in theory sending DATA to the primary, so it is > > > > likely to have the best cwnd to allow your data to go out. > > > > 2) You probably (aka same reason as 1) have a better RTT estimate > > > > of the primary > > > > 3) Its where you picked as the primary and where the user "expects" (if > > > > he/she expects at all) the data to go. > > > > > > > > Now I would bundle the sack and data if possible but either choice > > > > would be ok... sometimes they won't all fit together (as we know) > > > > depending on the size > > > > of the chunks :> > > > > > > > > Not that I have answered your questions.. other than the fact that any > > > > choice is legal.. its just some may be better for performance than > > > > others > > > > > > > > > > > > R > > > > > > - -- > > > Dipl.-Ing. Andreas Jungmaier > > > Computer Networking Technology Group > > > University of Duisburg-Essen > > > http://www.exp-math.uni-essen.de/~ajung > > > PGP Key-ID: D382 4AC0 > > > > > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.2.2 (GNU/Linux) > > > > > > iD8DBQE/g9aCXAsLBNOCSsARAkdJAJ48NHJiCwc1LF84EeaoOjw0bhbWMgCgoR5C > > > ZQ4f1EPYMJ6Us9mLCdsP8b0= > > > =eRrH > > > -----END PGP SIGNATURE----- > > - -- > Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE/hS3aXAsLBNOCSsARAhszAKCG8A3RmvhrmZZSImUJufnw44CQNwCdHB3d > H+BbcPaYkdkp+oCjWi2nL2Y= > =B8Vm > -----END PGP SIGNATURE----- -- 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 ¦ From ajung@exp-math.uni-essen.de Thu Oct 9 07:20:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15848 for ; Thu, 9 Oct 2003 07:20:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7YqE-0005By-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 07:20:22 -0400 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 1A7YqE-0005Bj-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 07:20:22 -0400 Received: from exp-math.uni-essen.de (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 04:20:50 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99BJAJs027493 for ; Thu, 9 Oct 2003 04:19:10 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h99BIdx5009959 for ; Thu, 9 Oct 2003 04:18:40 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8-20030924/8.12.8) with ESMTP id h99BFFWO033678; Thu, 9 Oct 2003 13:15:16 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: bidulock@openss7.org Subject: Re: Question: Which address to choose... Date: Thu, 9 Oct 2003 13:18:01 +0200 User-Agent: KMail/1.5.2 Cc: "Armando L. Caro Jr." , "Randall Stewart (cisco)" , sctp-impl@external.cisco.com References: <200310091143.57879.ajung@exp-math.uni-essen.de> <20031009044240.A10348@openss7.org> In-Reply-To: <20031009044240.A10348@openss7.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310091318.02818.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 09 October 2003 12:42, Brian F. G. Bidulock wrote: > Andreas, > > I don't understand how B's T3 timer can timeout three times > (presumably being doubled each time) before A's T3 timer expires > the first time. Could you please explain? > Oh, absolutely. It does expire in the same way as B's T3 Timer. Andreas =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/hUPpXAsLBNOCSsARAm55AJsHYEdpRIqh0/Qh1E+HTgOa8pbzXACggK14 Zv2gJXyAQGl7qYTQnbI9KWU=3D =3DpHg5 =2D----END PGP SIGNATURE----- From bidulock@openss7.org Thu Oct 9 07:59:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16651 for ; Thu, 9 Oct 2003 07:59:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ZSJ-0005S6-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 07:59:43 -0400 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 1A7ZSI-0005Ry-00 for sctp-impl-archive@ietf.org; Thu, 09 Oct 2003 07:59:43 -0400 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h99BwPLt013125 for ; Thu, 9 Oct 2003 04:58:35 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h99BwSre017286 for ; Thu, 9 Oct 2003 04:58:28 -0700 (PDT) Received: from ns.pigworks.openss7.net (IDENT:5/0EwJAh4JNu4aivdJVDX9dYzk9c+KPF@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h99BtEa15505; Thu, 9 Oct 2003 05:55:14 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h99BtDd11959; Thu, 9 Oct 2003 05:55:13 -0600 Date: Thu, 9 Oct 2003 05:55:13 -0600 From: "Brian F. G. Bidulock" To: Andreas Jungmaier Cc: "Armando L. Caro Jr." , "Randall Stewart (cisco)" , sctp-impl@external.cisco.com Subject: Re: Question: Which address to choose... Message-ID: <20031009055513.A11838@openss7.org> Reply-To: bidulock@openss7.org References: <200310091143.57879.ajung@exp-math.uni-essen.de> <20031009044240.A10348@openss7.org> <200310091318.02818.ajung@exp-math.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310091318.02818.ajung@exp-math.uni-essen.de>; from ajung@exp-math.uni-essen.de on Thu, Oct 09, 2003 at 01:18:01PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Return-Receipt-To: Content-Transfer-Encoding: 8bit Andreas, The perhaps you can explain the scenario again with A's T3 timer timing out instead of always sending on the primary? --brian On Thu, 09 Oct 2003, Andreas Jungmaier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 09 October 2003 12:42, Brian F. G. Bidulock wrote: > > Andreas, > > > > I don't understand how B's T3 timer can timeout three times > > (presumably being doubled each time) before A's T3 timer expires > > the first time. Could you please explain? > > > Oh, absolutely. It does expire in the same way as B's T3 Timer. > > Andreas > > - -- > Dipl.-Ing. Andreas Jungmaier > Computer Networking Technology Group > University of Duisburg-Essen > http://www.exp-math.uni-essen.de/~ajung > PGP Key-ID: D382 4AC0 > > PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE/hUPpXAsLBNOCSsARAm55AJsHYEdpRIqh0/Qh1E+HTgOa8pbzXACggK14 > Zv2gJXyAQGl7qYTQnbI9KWU= > =pHg5 > -----END PGP SIGNATURE----- -- 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 ¦ From ajung@exp-math.uni-essen.de Fri Oct 10 07:41:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21239 for ; Fri, 10 Oct 2003 07:41:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7veO-0001DY-00 for sctp-impl-archive@ietf.org; Fri, 10 Oct 2003 07:41:40 -0400 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 1A7veN-0001CZ-00 for sctp-impl-archive@ietf.org; Fri, 10 Oct 2003 07:41:39 -0400 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9ABe7Yb003761 for ; Fri, 10 Oct 2003 04:40:08 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id h9ABeVLD026563 for ; Fri, 10 Oct 2003 04:40:32 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.8-20030924/8.12.8) with ESMTP id h9ABZtWO031562; Fri, 10 Oct 2003 13:36:10 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: bidulock@openss7.org, sctp-impl@external.cisco.com Subject: Re: Question: Which address to choose... Date: Fri, 10 Oct 2003 13:38:36 +0200 User-Agent: KMail/1.5.2 References: <200310091318.02818.ajung@exp-math.uni-essen.de> <20031009055513.A11838@openss7.org> In-Reply-To: <20031009055513.A11838@openss7.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310101338.42669.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Brian, dear all, never mind. The description of this scenario would become quite=20 lengthy and would - most probably - neither enlighten you nor me nor anyone else on this list. I think I found what seems to have been the reason for what=20 puzzled me in the first place: the RTO of the secondary path was still at the initial RTO (i.e. 3 seconds). That considered (and setting RTOs for both paths equally to 1 second),=20 the options 1 and 2 Randy mentioned earlier in this thread cause a similar= =20 (though not equal) behaviour with respect to recognition of path failure. Best regards, Andreas=20 On Thursday 09 October 2003 13:55, Brian F. G. Bidulock wrote: > Andreas, > > The perhaps you can explain the scenario again with A's T3 > timer timing out instead of always sending on the primary? > > --brian > > On Thu, 09 Oct 2003, Andreas Jungmaier wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thursday 09 October 2003 12:42, Brian F. G. Bidulock wrote: > > > Andreas, > > > > > > I don't understand how B's T3 timer can timeout three times > > > (presumably being doubled each time) before A's T3 timer expires > > > the first time. Could you please explain? > > > > Oh, absolutely. It does expire in the same way as B's T3 Timer. > > > > Andreas > > =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/hppBXAsLBNOCSsARAqXiAJ9i1O58HjJAOOXpQtenYscmZQyfIACg8Ypy Alk9DPzQmY4VJ85Zm5cIw/o=3D =3Dz8QZ =2D----END PGP SIGNATURE----- From bkatrf@erols.com Fri Oct 10 08:33:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24508 for ; Fri, 10 Oct 2003 08:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wSr-0002SB-00 for sctp-impl-archive@ietf.org; Fri, 10 Oct 2003 08:33:49 -0400 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 1A7wSp-0002Ra-00 for sctp-impl-archive@ietf.org; Fri, 10 Oct 2003 08:33:47 -0400 Received: from erols.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 05:41:44 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9ACWpcZ016319 for ; Fri, 10 Oct 2003 05:32:51 -0700 (PDT) Received: from MIKI-YA05DCYVKM (chello062178187172.1.15.vie.surfer.at [62.178.187.172]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with SMTP id h9ACX7VO015935 for ; Fri, 10 Oct 2003 05:33:08 -0700 (PDT) Message-Id: <200310101233.h9ACX7VO015935@sj-inbound-1.cisco.com> From: "bpacarch@juno.com" To: "sctp-impl@external.cisco.com" Subject: Order your College Diploma today! Date: Fri, 10 Oct 2003 14:31:38 +0200 X-Priority: 3 (normal) Importance: Normal X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPHN0 eWxlIHR5cGU9InRleHQvY3NzIj4NCkEueWVsbG93Omxpbmsge3RleHQtZGVjb3JhdGlvbjogbm9u ZTsgY29sb3I6ICNGRkYyMDB9DQpBLnllbGxvdzp2aXNpdGVkIHt0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiAjRkZGMjAwfQ0KQS55ZWxsb3c6YWN0aXZlIHt0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNvbG9yOiAjRUZFRkM4fQ0KQS55ZWxsb3c6aG92ZXIge3RleHQtZGVjb3JhdGlvbjogbm9u ZTsgY29sb3I6ICNGRkZGRkZ9DQo8L3N0eWxlPg0KPGJvZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9y PSIjMzMzMzk5Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGJyPg0KPHRhYmxlIHdpZHRoPSI2NTAi IGJvcmRlcj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIyIiBib3JkZXJjb2xvcj0i IzAwMDAwMCI+PHRyPjx0ZD48dGFibGUgd2lkdGg9IjY1MCIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjQiIGFsaWduPSJjZW50ZXIiPjx0cj4NCjx0ZCBiZ2NvbG9yPSIj MDAzMzY2Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiIgZmFjZT0iQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiI+LiBVIE4gPCEtLSBnZjY3c2dhazEgLS0+SSBWIEUgUiBTIEkgVCBZ IC4gRCBJIFAgTCA8IS0tIHN1ajhmZGFzaiAtLT5PIE0gQSBTIC48L2ZvbnQ+PC90ZD48L3RyPg0K PHRyPjx0ZCBiZ2NvbG9yPSJibGFjayIgaGVpZ2h0PSI0MCIgdmFsaWduPSJtaWRkbGUiPg0KPGRp diBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmIiBzaXplPSIyIiBjb2xvcj0iI0ZGRkZGRiI+PGk+V291bGQgeW91IGxpa2UgdG8g bWF4aW1pc2UgeW91ciBpbmNvbWUgYW5kIHJlc3BlY3QgZnJvbSBvdGhlcnM/PC9pPjxicj48L2Zv bnQ+PC9kaXY+DQo8L3RkPjwvdHI+PHRyPiA8dGQgYmdjb2xvcj0iQ0MwMDMzIj4NCjxkaXYgYWxp Z249ImNlbnRlciI+PHA+PGI+PGk+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+V2UgY2FuIGFzc2lzdCB3aXRoIERpcDwhLS0gc3VqOGZk YXNqIC0tPmxvbWFzIGZyb20gcHJlc3RpZ2lvdXMgbm9uLWFjY3JlZGl0ZWQgdW5pdmVyc2l0PCEt LSBzdWo4ZmRhc2ogLS0+aWVzIGJhc2VkIG9uIHlvdXIgcHJlc2VudCBrbm93bGVkZ2UgYW5kIGxp ZmUgZXhwZXJpZW5jZS48L2ZvbnQ+PC8NCjwvdGQ+PC90cj48dHI+PHRkIGJnY29sb3I9IndoaXRl Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMyI+PGJyPjxiPjxmb250IGNvbG9yPSIjRkYwMDAwIj5O byByZXF1aXJlZCB0ZXN0cywgY2xhc3NlcywgYm9va3MsIG9yIGludGVydmlld3MuIDwvZm9udD48 L2I+PC9mb250PiA8L2Rpdj4NCjxwIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIzIj48aT5HZW51aW5lIE1CQSwgQmFj aGVsb3JzLCBtYXN0ZXJzIHlvdSBuYW1lIGl0LiBFdmVuIERvY3RvcmF0ZSAoUGhEKSAtIFRoYXQn cyBjb3JyZWN0LCB5b3UgY2FuIGJlIHRoZSBuZXh0IERyIE5pY2sgUml2aWVyYSEgPC9pPjwvZm9u dD48L3A+DQo8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIzIj48Yj48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzAw MDBGRiI+Tm8gb25lIGlzIHR1cm5lZCBkb3duLjwvZm9udD48L2I+PC9mb250PjwvcD4NCjxwIGFs aWduPSJjZW50ZXIiPjxpbWcgc3JjPSJodHRwOi8vcmFuZEB3d3cuY29sdW1iaWEuZWR1L2N1L2J1 c2luZXNzL2ltYWdlcy9kaXBsb21hLmdpZiI+DQo8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNl PSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIzIj48aT5Db25m aWRlbnRpYWxpdHkgYXNzdXJlZDwvaT48L2ZvbnQ+PGJyPjxicj48L3A+DQo8L3RkPjwvdHI+PHRy Pjx0ZCBiZ2NvbG9yPSIjMDAwMDAwIj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9IiNGRkZGRkYi Pjxicj4NCkNBTEwgVVMmbmJzcDsgMjQgSE9VUlMgQSBEQVksIDcgREFZUyZuYnNwOyBBIFdFRUs8 L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgY29sb3I9IiNGRkZGRkYiPiZuYnNwOyA8Zm9udCBzaXplPSIxIj4oaW5jbHVkaW5n IFN1bmRheXMgYW5kIGhvbGlkYXlzKTo8L2ZvbnQ+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9 IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIGNvbG9yPSIjRkZGRkZGIj48 Yj48Zm9udCBzaXplPSI1Ij5DQUxMIE5PVyEgMS0yPCEtLSBnZjY3c2dhazEgLS0+MTItMjAyLTQ3 ODU8L2ZvbnQ+PC9iPiA8L2ZvbnQ+IDxmb250IHNpemU9IjUiIGZhY2U9IkFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWYiIGNvbG9yPSIjRkZGRkZGIj48YnI+PC9iPjwvZm9udD48L3A+PC9kaXY+ DQo8L3RkPjwvdHI+PHRyPiA8dGQgYmdjb2xvcj0iIzAwMzM2NiI+DQo8ZGl2IGFsaWduPSJjZW50 ZXIiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjRkZGRkZGIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIj48Yj5DYWxsIHVzIE5PVyB0byByZWNlaXZlIHlvdXIgZGlwbG88IS0tIHN1 ajhmZGFzaiAtLT5tYSB3aXRoaW4gZGF5cywgYW5kIHN0YXJ0IGltcHJvdmluZyB5b3VyIGxpZmUh PC9iPjwvZm9udD48L2Rpdj4NCjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K From steve.weiss@virgin.net Sat Oct 11 05:21:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26761 for ; Sat, 11 Oct 2003 05:21:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Fwf-0002Mf-00 for sctp-impl-archive@ietf.org; Sat, 11 Oct 2003 05:21:53 -0400 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 1A8Fwe-0002Mc-00 for sctp-impl-archive@ietf.org; Sat, 11 Oct 2003 05:21:52 -0400 Received: from virgin.net (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 02:30:06 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9B9K7gk016850 for ; Sat, 11 Oct 2003 02:20:07 -0700 (PDT) Received: from 192.168.0.238 (m91-mp1.cvx2-a.bir.dial.ntli.net [62.255.48.91]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with SMTP id h9B9KUVO012349 for ; Sat, 11 Oct 2003 02:20:32 -0700 (PDT) Message-Id: <200310110920.h9B9KUVO012349@sj-inbound-1.cisco.com> From: "Steve" To: Subject: Our next dates are....... Sender: "Steve" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Sat, 11 Oct 2003 10:22:29 +0100 Reply-To: "Steve" Content-Transfer-Encoding: 8bit During the last 11 years we have been successfully presenting our training seminars in the UK. We have now decided to let the rest of the world have a chance! Listed here are the 3 seminars that we will be presenting in various locations around the world between now and March 2004. For further info please send us your details and we will send our information pack by return. 1 - Selling for Engineers - One-day Seminar The Selling for Engineers seminar is a good introduction to effective sales principles for people who are new to selling, and also a useful refresher for 'old hands'. It applies to selling both technical products and intangible services. Many Sales Engineers have been learning the technical skills of their job for years but have had little formal training in selling. This course helps correct that imbalance. Typical job titles of delegates: Sales Engineer, Account Executive and Business Development Manager. 2 - Telephone Sales Prospecting for Engineers - One-day Workshop This event is a practical workshop teaching people in technical companies how to find new customers on the phone. It is applicable to business development for both tangible products and intangible services. The first session addresses whom to target, what to say and how to handle problems. The remainder of the day consists of live sales calls with coaching from Robert Seviour; the objective being to give delegates some positive experiences of prospecting, make sales appointments and maybe sell something! Please note that this telephone sales prospecting event is restricted to a maximum of six delegates to permit individual coaching. 3 - Closing Techniques Workshop - One day workshop What if the customer says: " " 'It's too expensive' " " 'We're happy with our present supplier' " " 'I want to think about it' Can you handle these common objections? By far the most efficient way to be more profitable is to turn more of the enquiries you receive into paid orders. For this, the ability to resolve objections is critical - either you close or you lose the sale. And if you answer 'How much discount will you give me?' with: 'I'll ask my boss', you waste profit, which could be yours with a better reply. In only a day I will teach you techniques which overcome these objections and more. You will be able to use them immediately to win profitable orders. There is no need to lose business to your competitors or give big discounts. If you have never had any formal sales training or need a refresher, don't continue to work at a disadvantage. All courses are from 9am until 5pm and cost £300 per person per day Reservations and information Please contact Sue on: Tel: +44(0)1481 720 294 Fax: +44(0)1481 720 317 If sales training is not an issue for your company please reply to this email with the word "DELETE" in the subject line. We will remove your details promptly. From paul_m@tiscali.co.uk Sat Oct 11 05:33:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26964 for ; Sat, 11 Oct 2003 05:33:26 -0400 (EDT) From: paul_m@tiscali.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8G7x-0002RC-00 for sctp-impl-archive@ietf.org; Sat, 11 Oct 2003 05:33:33 -0400 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 1A8G7w-0002Qu-00 for sctp-impl-archive@ietf.org; Sat, 11 Oct 2003 05:33:33 -0400 Received: from tiscali.co.uk (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 02:41:46 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9B9Wd7E020362 for ; Sat, 11 Oct 2003 02:32:39 -0700 (PDT) Received: from mk-smarthost-2.mail.uk.tiscali.com (mk-smarthost-2.mail.uk.tiscali.com [212.74.114.38]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9B9X6VO015698 for ; Sat, 11 Oct 2003 02:33:06 -0700 (PDT) Received: from [212.74.114.4] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-2.mail.uk.tiscali.com with esmtp (Exim 4.20) id 1A8G2w-000OTT-QY; Sat, 11 Oct 2003 10:28:22 +0100 Received: from [196.25.253.13] by mk-cpfrontend.uk.tiscali.com with HTTP; Sat, 11 Oct 2003 10:28:21 +0100 Date: Sat, 11 Oct 2003 11:28:21 +0200 Message-ID: <3F85AD7B000046F7@mk-cpfrontend-2.mail.uk.tiscali.com> Subject: URGENT BUSINES ASSISTANCE. To: keyko5@juno.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable MR PAUL MAZAMB #216 TUDHOPE/High Street JOHANNESBURG, SOUTH AFRICA. TEL+27-73-337-3727 E-MAIL:paul_m@tiscali.co.uk ATTN:THE DIRECTOR, Dear sir/madam PROPOSAL FOR URGENT BUSINES ASSISTANCE. My name is MR PAUL MAZAMB,the elder son of Mr.JOHN MAZAMB of Zimbabwe. Th= is might be a surprise to you about where I got your contact address. I got it through South African Infornation Cerntre. During the current war against the farmers in Zimbabwe from the supports of our President Robert Mugabe to claim all the white-owned farms to his party members and his followers, he ordered all white farmers to surrende= r all farms to his party members and his followers. My father is One of the best farmers in our country and because he did no= t support Mugabes ideas,Mugabes supports invaded my fathers farm and burnt everything in the farm,killing my father and made away with a lot of item= s in my fathers farm. Before his death,my father had deposited with of the Security Company in Johannesburg,South Africa the sum of US$25,5 MILLION(TWENTY FIVE MILLION FIVE HUNDERD THOUSAND UNITED STATES DOLLARS). After the death of my father, we decided to move to the Republic of South= Africa where he had deposited the money in the Security Company as valuab= les. So I decided to contact overseas firm and companies that will assist me to move this money out of South Africa because as asylum seekers we are not allowed to operate any Bank Account within South Africa. We have agreed to offer you 20% of the total sum for your assistance,5% will be mapped out for any expenses that may be incurred in the course of= this transaction while 75% will be for me and my family to invest in your= country. All I want you to do is to furnish me with your entire personal phone and fax numbers for easy communication.You can contact me on the ab= ove Telephone number. Note that this transaction is 100% Risk free and absolutely confidential.= Thanks as i wait to hear from you. Best Regards PAUL MAZAMB FOR THE FAMILY From docjameswhite@netscape.net Sun Oct 12 01:08:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25124 for ; Sun, 12 Oct 2003 01:08:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8YT5-0003ue-00 for sctp-impl-archive@ietf.org; Sun, 12 Oct 2003 01:08:35 -0400 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 1A8YSu-0003u4-00 for sctp-impl-archive@ietf.org; Sun, 12 Oct 2003 01:08:24 -0400 Received: from netscape.net (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2003 22:16:50 -0700 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9C56t7E019850 for ; Sat, 11 Oct 2003 22:06:55 -0700 (PDT) Received: from netscape696.com (node-c-064a.a2000.nl [62.194.6.74]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with SMTP id h9C56ure005689 for ; Sat, 11 Oct 2003 22:06:59 -0700 (PDT) Message-Id: <200310120506.h9C56ure005689@sj-inbound-3.cisco.com> From: CHIEF.DANIEL.ABBOT.AKU@cisco.com, To: sctp-impl@external.cisco.com Reply-To: docjameswhite@netscape.net Subject: URGENT ASSISTANCE NEEDED Date: Sun, 12 Oct 2003 07:06:47 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="75ed27e0-6369-4f0d-931c-26b8c3595f6b" This is a multi-part message in MIME format --75ed27e0-6369-4f0d-931c-26b8c3595f6b Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM HIS ROYAL MAJESTY (HRM) CROWN RULER OF ELEME KINGDOM CHIEF DANIEL ABBOT AKU, PHD, EZE 1 OF ELEME. docjameswhite@netscape.net ATTENTION:PRESIDENT,CEO Sir/ Madam. This letter might surprise you because we have met neither in person nor by = correspondence. But I believe it is one day that you got to know somebody = either in physical or through correspondence. I got your contact through discreet inquiry from the chambers of commerce and = industry of your country on the net, you and your organization were revealed = as being quite astute in private entrepreneurship, one has no doubt in your = ability to handle a financial business transaction. However, I am the first son of His Royal majesty,DANIEL Abbot AKU , and the = traditional Ruler of Eleme Province in the oil producing area of River State = of Nigeria. I am making this contact to you in respect of US$60,000,000.00 = (Sixty Million United State Dollars), which I inherited, from my late = father. This money was accumulated from royalties paid to my father as compensation = by the oil firms located in our area as a result of oil presence on our = land, which hamper agriculture, which is our major source of livelihood. Unfortunately my father died from protracted diabetes.But before his death he = called my attention and informed me that he lodged some funds on a two boxes = with a security firm with an open beneficiary status. The lodgment security = code number was also revealed to me, he then advised me to look for a = reliable business partner abroad, that will assist me in investing the money = in a lucrative business as a result of economic instability in Nigeria. So = this is the main reason why I am contacting you for us to move this money = from the security firm to any Country of your choice for investment purpose.= So I will like you to be the ultimate beneficiary, so that the funds can be = moved in your name and particulars to any Country of your choice where it = will be claimed and invested. Hence my father have had intimated the = security firm personnel that the beneficiary of the box is his foreign = partner whose particulars will be forwarded to the firm when due. But I will guide you Accordingly. As soon as the funds reach, I will then = come over to meet you in person, so that we can discuss physically on = investment potentials. Based on this assistance my Family and I have = unanimously decided to give you 30% of the total money, 5% for Charity home, = 10% for expenses, which may arise during this transaction, Fax and phone = bills inclusive. The balance of 55% you will invest and managed for my = Family. I hereby guarantee you that this is not government money, it is not drug = money and it is not money from arms deal. Though you have to maintain high = degree of confidentiality on this matter. I will give more details about the = proceedings of this transaction as soon as I receive your favorable reply. Please reply to my Email Address:docjameswhite@netscape.net I hope this will = be the beginning of a prosperous relationship between my family and your = family. Nevertheless if you are for any reason not interested, kindly inform me = immediately so that I will look for another contact. I am waiting for your quick response. Yours faithfully, Prince MIKE AKU N/B; PLEASE IF YOU ARE INTERSITED TO WORK WITH ME PLEASE KINDLE SEND THIS = INFORMATION TO ME. 1, YOUR FULL NAMES AND ADDRESS 2, YOUR PRIVATE TELEPHONE/MOBILE AND FAX NUMBERS INCULDING THE COUNTRY CODE = AND CITY CODE. --75ed27e0-6369-4f0d-931c-26b8c3595f6b-- From mikeokoh_ng@post.com Mon Oct 13 11:06:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10435 for ; Mon, 13 Oct 2003 11:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A94H9-00049L-00 for sctp-impl-archive@ietf.org; Mon, 13 Oct 2003 11:06:23 -0400 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 1A94H9-000499-00 for sctp-impl-archive@ietf.org; Mon, 13 Oct 2003 11:06:23 -0400 Received: from post.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 13 Oct 2003 08:15:05 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9DF4klR024678 for ; Mon, 13 Oct 2003 08:04:46 -0700 (PDT) Received: from ok6851.com ([212.100.64.69]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9DF49x5002073 for ; Mon, 13 Oct 2003 08:04:12 -0700 (PDT) Message-Id: <200310131504.h9DF49x5002073@sj-inbound-2.cisco.com> From: "DR. MIKE OKOH" Reply-To: mikeokoh9k@accountant.com To: sctp-impl@external.cisco.com Date: Mon, 13 Oct 2003 16:04:35 +0430 Subject: LET'S GET THIS DONE TOGETHER.(BENEFIT BOTH) X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FROM=3A DR=2E MIKE OKOH STANFFORD INVESTMENT INC=2E 182A BRICKFIELD ROAD THE OIL EXPLORERS EBUTE-METTA WEST LAGOS-NIGERIA EMAIL=3A mikeokoh=5Fng=40post=2Ecom Tel=3A 234-803-4046648 Fax=3A 234-1-7596351=2E Dear Sir=2C REQUEST FOR AN URGENT BUSINESS RELATIONSHIP I am DR=2E MIKE OKOH=2C the Chief Accountant with the National Oil Nigeria PLC =28N=2FOil=29 and member of 5 MAN Contract Executive Review Panel =28comprising 2 Snr=2EStaff of CBN and 3 Snr=2C Staff of =28N=2FOil=29 set up by present Civilian Regime of President Olusegun Obasanjo=2E So far=2C we have come across a surplus of the sum of US$47M=2E =28Fourty-seven Million Dollars=29 which was as a result of deliberate over-invoicing of certain contracts awarded by Contract Award Committee of the corporation=2E The last installments due have been paid to the various Contractors=2C while the said surplus still floats in our Apex Bank waiting Off-shore remittance which we want to carry out=2E As Civil servants we cannot operate Foreign account=2C therefore seek your assistance in Providing enabling Bank Account where the Fund would be lodged=2E 15% of the total Sum is for you and 85% for me and my Colleagues=2E Please notify me of your acceptance to carry out this transaction through the above or below E-mail address and provide me your private phone and fax number to ease our communication=2E I shall in turn inform you of the modalities for a formal application to secure the necessary approvals for the immediate release of this fund into your account=2E For more Clarification=2C call me on my direct phone number for details=2E This transaction will only take =2814=29 working days=2E I look forward to your swift response=2E Best Regards=2E Dr=2E Mike Okoh=2E Tel=3A 234-803-4046648 Fax=3A 234-1-7596351=2E Note=3A All correspondent to me send to this email address below=3A mikeokoh9k=40accountant=2Ecom From interco@mail.com Mon Oct 13 17:17:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29664 for ; Mon, 13 Oct 2003 17:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9A3x-0001Re-00 for sctp-impl-archive@ietf.org; Mon, 13 Oct 2003 17:17:09 -0400 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 1A9A3w-0001RL-00 for sctp-impl-archive@ietf.org; Mon, 13 Oct 2003 17:17:08 -0400 Received: from mail.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2003 14:10:49 -0700 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9DLCJvA011922 for ; Mon, 13 Oct 2003 14:12:20 -0700 (PDT) Received: from MailUser ([61.250.95.55]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h9DLCjdZ000421 for ; Mon, 13 Oct 2003 14:12:46 -0700 (PDT) Message-Id: <200310132112.h9DLCjdZ000421@sj-inbound-4.cisco.com> Reply-To: "interco" From: "interco" To: "" Organization: Inter Co inc Programming X-Priority: 1 X-MSMail-Priority: High Subject: Security Warning! Sender: "interco" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 14 Oct 2003 06:14:11 +0900 Warning! The swindlers have invented a new way of stealing your money from your e-gold account. Hundreds of e-gold and other electronic systems users have already suffered from it. The swindlers have invented a new way of stealing your money from your e-gold account. Hundreds of e-gold and other electronic systems users have already suffered from it. http://61.250.95.55 CLICK RIGHT NOW! Protect yourself from hackers! http://61.250.95.55 From s010884@com.dtu.dk Tue Oct 14 04:41:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00130 for ; Tue, 14 Oct 2003 04:41:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Kk6-0007Jz-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 04:41:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1A9Kk6-0007JT-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 04:41:22 -0400 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9E8devA012008 for ; Tue, 14 Oct 2003 01:39:40 -0700 (PDT) Received: from com.dtu.dk (mail.com.dtu.dk [192.38.68.3]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9E8e5VO013556 for ; Tue, 14 Oct 2003 01:40:06 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3922E.85EE6550" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: question about address-parameters in INIT-ACK Date: Tue, 14 Oct 2003 10:38:20 +0200 Message-ID: Thread-Topic: question about address-parameters in INIT-ACK Thread-Index: AcOSLoXeK7/O7q+aTGaASL0tSwu09Q== From: "Lei Zhang" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3922E.85EE6550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all sctp player: =20 Who could kindly explain the paragraph in RFC2960, 3.3.3: =20 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name address parameter is present. what will happen if INIT ACK has Host Name address and other IPv4/6 = addresses? or two Host Name addresses? =20 Best regards =20 Lei ------_=_NextPart_001_01C3922E.85EE6550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, all sctp=20 player:
 
Who could kindly = explain the=20 paragraph in RFC2960, 3.3.3:
 
Note 3: The INIT ACK chunks MUST = NOT contain=20 more than one Host Name
   address parameter.  = Moreover, the=20 sender of the INIT ACK MUST NOT
   combine any other = address types=20 with the Host Name address in the
   INIT ACK.  The = receiver=20 of the INIT ACK MUST ignore any other address
   types if = the Host=20 Name address parameter is present.

what will = happen if INIT=20 ACK has Host Name address and other IPv4/6 addresses? or two Host Name=20 addresses?
 
Best=20 regards
 
Lei

------_=_NextPart_001_01C3922E.85EE6550-- From allendidon101@netscape.net Tue Oct 14 04:59:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00611 for ; Tue, 14 Oct 2003 04:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9L1J-0007V1-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 04:59:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1A9L1J-0007Ui-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 04:59:09 -0400 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9E8vvvA023250 for ; Tue, 14 Oct 2003 01:57:58 -0700 (PDT) Received: from mail.copitival.es ([62.81.142.58]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9E8vnre017304 for ; Tue, 14 Oct 2003 01:58:02 -0700 (PDT) Message-Id: <200310140858.h9E8vnre017304@sj-inbound-3.cisco.com> Received: from smtp0502.mail.yahoo.com [200.149.135.134] by copitival.es [62.81.142.59] with SMTP (MDaemon.PRO.v4.0.2.R) for ; Mon, 13 Oct 2003 20:24:56 +0200 Date: Mon, 13 Oct 2003 18:23:38 GMT From: "Drirallan" X-Priority: 3 To: sctp-impl@external.cisco.com Subject: sctp-impl, Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 X-MDRemoteIP: 200.149.135.134 X-Return-Path: allendidon101@netscape.net X-MDaemon-Deliver-To: sctp-impl@external.cisco.com Content-Transfer-Encoding: base64 DQpGUk9NOiBQUklOQ0UgRElET04gQUxMRU4NCg0KDQpEZWFyIFNpci9NYWRhbSwNClVSR0VOVCBC VVNJTkVTUyBBU1NJU1RBTkNFIFJFUVVJUkVELg0KTXkgbmFtZSBpcyBQcmluY2UgRGlkb24gQWxs ZW4sIGEgU2llcnJhIExlb25lYW4gcmVmdWdlZSByZXNpZGluZyBpbiB0aGUgTmV0aGVybGFuZHMg dW5kZXIgdGhlIFVuaXRlZCBOYXRpb25zIHJlZnVnZWUgc3RhdHVzIC5JIGFtIDI2IHllYXJzIG9s ZCBhbmQgaSBnb3QgeW91ciBjb250YWN0IHRocm91Z2ggYSBidXNpbmVzcyBkaXJlY3RvcnkgYW5k IGRlY2lkZWQgdG8gYXBwcm9hY2ggeW91IGZvciBIRUxQLg0KTXkgbGF0ZSBmYXRoZXIsIENoaWVm IENlZXNheSBBbGxlbiBDb250ZWgsIHdhcyBvbmUgb2YgdGhlIHByb21pbmVudCBHb2xkLCBEaWFt b25kIGFuZCBUaW1iZXIgZGVhbGVycyBpbiBteSBjb3VudHJ5LiBIZSB3YXMgYWxzbyBvbmUgb2Yg dGhlIHBhcmFtb3VudCBjaGllZnMgYmVmb3JlIGhlIHdhcyBicnV0YWxseSBtdXJkZXJlZCBpbiBj b2xkIGJsb29kIG9uIHRoZSA2dGggb2YgSmFudWFyeSwxOTk5IGFsb25nc2lkZSBteSANCnRocmVl IGVsZGVyIGJyb3RoZXJzIGFuZCBhIHNpc3RlciBieSB0aGUgcmViZWxzIG9mIFIuVS5GIGxveWFs IHRvIG9uZSBvZiB0aGUgdHlyYW50cyBpbiBteSBjb3VudHJ5KFNJRVJSQSBMRU9ORSkuSSBnb3Qg aG9tZSBmcm9tIHNjaG9vbCB0byBmaW5kIHRoYXQgbXkgZmFtaWx5IHdhcyBlbGltaW5hdGVkIGFu ZCBvdXIgZW50aXJlIGNvdW50cnkgaG9tZSBhbmQgYmVsb25naW5ncyByYXplZCBkb3duLCBmb3J0 dW5hdGVseSBteSBtb3RoZXIgYW5kIHNpc3RlciBtYW5hZ2VkIHRvIGVzY2FwZSBhbmQgYXJlIHBy ZXNlbnRseSByZWZ1Z2VlcyBpbiBzb3V0aCBhZnJpY2EgdW5kZXIgdW5pdGVkIG5hdGlvbnMgcmVm dWdlZSBzdGF0dXMsIHdoaWxlIEkgbWFuYWdlZCB0byBlc2NhcGUgdG8gdGhlIE5ldGhlcmxhbmRz Lg0KSG93ZXZlciwgYmVmb3JlIHRoZSB0cmFnaWMgaW5jaWRlbnRzIG15IGxhdGUgZmF0aGVyIGRl cG9zaXRlZCB0aGUgc3VtIG9mIFRXRU5UWSBFSUdIVCBNSUxMSU9OIFVTIERPTExBUlMgKCQyOCww MDAsMDAwKSBhcyAgZmFtaWx5IHRyZWFzdXJlIGFuZCBiZWxvbmdpbmdzICBpbiB0d28gdHJ1bmsg Ym94ZXMgd2l0aCBhIFNlY3VyaXR5IGFuZCBmaW5hbmNlIENvbXBhbnkgaGVyZSBpbiB0aGUgTmV0 aGVybGFuZHMuDQpOb3csIHdpdGggdGhlIGNvbnNlbnQgYW5kIGJhY2tpbmcgb2YgbXkgbW90aGVy IGFzIHRoZSBuZXh0IG9mIGtpbix0aG91Z2ggSSd2ZSBtYWRlIGNsYWltcyBvZiB0aGUgb3duZXJz aGlwIG9mIHRoZSBib3ggY29udGFpbmluZyB0aGUgbW9uZXkgYWx0aG91Z2ggdGhlIHBlb3BsZSBh dCB0aGUgU2VjdXJpdHkgQ29tcGFueSBhcmUgbm90IGF3YXJlIG9mIHRoZSBhY3R1YWwgY29udGVu dHMgb2YgdGhlIGJveGVzLiBIZW5jZSwgSSBuZWVkIGEgcmVsaWFibGUgYW5kIHRydXN0d29ydGh5 IHBlcnNvbiB3aG8gbWFrZSB0aGUgY2xhaW1zIGFzIGJlbmVmaWNpYXJ5IG9mIHRoZSBjb25zaWdu bWVudHMgYW5kIGltcG9ydGFudGx5IGFmdGVyIHRoZSBjbGFpbXMgaGF2ZSBiZWVuIG1hZGUgd291 bGQgc2VlIHRvIHRoZSB3aXNlIGludmVzdG1lbnQgb2YgdGhlIGZ1bmRzIG9uIG91ciBiZWhhbGYg d2l0aG91dCBmYXVsdGluZyBiZWNhdXNlIGkgaGF2ZSBiZWVuIG1hZGUgdG8gdW5kZXJzdGFuZCB0 aGF0IGFzIGEgcmVmdWdlZSBpIGFtIG5vdCBwZXJtaXR0ZWQgYnkgdGhlIFUuTiBMQVdTIHRvIGhh bmRsZSBzdWNoIHRyYW5zYWN0aW9ucywgYW5kIGJlc2lkZXMgbXkgbW92ZW1lbnQgaXMgcmVzdHJp Y3RlZCBhcyBhIHJlZnVnZWUuDQpNeSBtb3RoZXIgYW5kIGkgYXJlIHdpbGxpbmcgdG8gZ2l2ZSB5 b3UgMjUlIG9mIHRoZSB0b3RhbCBzdW0gaWYgeW91IHdpbGwgYmUgd2lsbGluZyB0byBhc3Npc3Qg dXMgaW4gdGhpcyBtYXR0ZXIuIEluIGFkZGl0aW9uLCB3ZSBoYXZlIGFsc28gYWdyZWVkIHRvIGRl ZHVjdCA1JSBhZnRlciB0aGUgdHJhbnNhY3Rpb24gdG8gY292ZXIgYW55IGV4cGVuc2VzIGluY3Vy cmVkIGR1cmluZyB0aGUgZHVyYXRpb24gb2YgdGhpcyB0cmFuc2FjdGlvbg0KV2UgYXJlIHdpbGxp bmcgdG8gZW50cnVzdCBvdXIgc2hhcmUgb2YgdGhpcyBtb25leSBpbnRvIHlvdXIgaGFuZHMgaWYg eW91IGNhbiBiZSBob25lc3QgYW5kIHdpdGggbWUgYXMgeW91IHZlcnkgbXVjaCBrbm93IHRoYXQg b3VyIGZ1dHVyZSBpcyBoaW5nZWQgb24gdGhpcyBmdW5kcy4NCklmIHlvdSBmaW5kIGl0IGluIHlv dXIgaGVhcnQgdG8gcmVuZGVyIHVuZHlpbmcgYXNzaXN0YW5jZSB0byBteSBtb3RoZXIsIHNpc3Rl ciBhbmQgSSBwbGVhc2UgZ2V0IGJhY2sgdG8gbWUgcHJvbXB0bHkgdGhyb3VnaCBteSBjb250YWN0 cyBhYm92ZSBzbyB0aGF0IHdlIGNhbiBkaXNjdXNzIHRoZSBmaW5lciBkZXRhaWxzIG9mIG1ha2lu ZyB0aGlzIHRyYW5zYWN0aW9uIHNhZmUgYW5kIHN1Y2Nlc3NmdWwuIEkgd2lsbCBlcXVhbGx5IGlu c2lzdCANCnRoYXQgeW91IG1ha2UgdGhpcyB0cmFuc2FjdGlvbiBhIHZlcnkgcHJpdmF0ZSBhbmQg Y29uZmlkZW50aWFsIG1hdHRlci4gVXBvbiB5b3VyIGFjY2VwdGFuY2UsIEkgd2lsbCBtYWtlIGF2 YWlsYWJsZSByZWxldmFudCBkb2N1bWVudHMgYW5kIGluZm9ybWF0aW9uIHRvIHlvdSAgd2l0aCBy ZWdhcmRzIHRvIHRoZSBjb25zaWdubWVudHMgIHRoYXQgd2lsbCBlbmhhbmNlIHRoZSBzdWNjZXNz ZnVsICBhbmQgMTAwJXJpc2sgZnJlZSBmaW5pc2hpbmcgb2YgdGhpcyB0cmFuc2FjdGlvbi4NCg0K SSBhbSBsb29raW5nIGZvcndhcmQgdG8geW91ciBhbnRpY2lwYXRlZCBjby1vcGVyYXRpb24gYW5k IHJlcGx5IHNvb25lc3QuDQogDQpLaW5kIHJlZ2FyZHMsDQpQUklOQ0UgRElET04gQUxMRU4NCg== From s010884@com.dtu.dk Tue Oct 14 06:08:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02243 for ; Tue, 14 Oct 2003 06:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9M6e-0000LK-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 06:08:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A9M6d-0000LC-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 06:08:43 -0400 Received: from com.dtu.dk (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2003 03:08:19 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9EA7WSw014927 for ; Tue, 14 Oct 2003 03:07:32 -0700 (PDT) Received: from com.dtu.dk (mail.com.dtu.dk [192.38.68.3]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9EA70x5012245 for ; Tue, 14 Oct 2003 03:07:02 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: question about address-parameters in INIT-ACK Date: Tue, 14 Oct 2003 12:06:15 +0200 Message-ID: Thread-Topic: question about address-parameters in INIT-ACK Thread-Index: AcOSOGkl1jSEiWjUSkK64nbOxZUJCgAAa//Q From: "Lei Zhang" To: "Andreas Jungmaier" Cc: Content-Transfer-Encoding: quoted-printable Hi, Andreas and all: Thanks for the reply, you make it very clear. But I have further questions, do you know why it is defined like = that(Note 3)? Why can't Host Name address stay with other IP addresses? = Neither can two Host Name address? B/R Lei -----Original Message----- From: Andreas Jungmaier [mailto:ajung@exp-math.uni-essen.de] Sent: Tuesday, October 14, 2003 11:51 AM To: Lei Zhang Subject: Re: question about address-parameters in INIT-ACK -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 14 October 2003 10:38, you wrote: > Hi, all sctp player: > > Who could kindly explain the paragraph in RFC2960, 3.3.3: > > Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name > address parameter. Moreover, the sender of the INIT ACK MUST NOT > combine any other address types with the Host Name address in the > INIT ACK. The receiver of the INIT ACK MUST ignore any other = address > types if the Host Name address parameter is present. > > what will happen if INIT ACK has Host Name address and other IPv4/6 > addresses? or two Host Name addresses? > I think the endpoint could either silently ignore other address=20 parameters (IPv4/IPv6) if there is only one host name parameter, or could send back an abort with an error chunk adding the parameters in question as "unrecognized parameters". Either way, I would not implement host name parameter support=20 at all. Most implementations out there do not use it, and therefore only list IPv4/IPv6 addresses as supported address types. Then, you can safely abort any replies with a host name paramter. Hope that helps, best regards, Andreas - --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/i8cfXAsLBNOCSsARApyIAKDPNy7h7kkeocpMFie+wwzxWrgp9QCgleXK 97nDbjrOQ3P05y4LoZLx9lo=3D =3DxBvv -----END PGP SIGNATURE----- From ajung@exp-math.uni-essen.de Tue Oct 14 07:53:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04959 for ; Tue, 14 Oct 2003 07:53:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9NkH-0001IO-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 07:53:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1A9NkG-0001I1-00 for sctp-impl-archive@ietf.org; Tue, 14 Oct 2003 07:53:44 -0400 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9EBqrSw011593 for ; Tue, 14 Oct 2003 04:52:54 -0700 (PDT) Received: from pilz.exp-math.uni-essen.de (ns.exp-math.uni-essen.de [132.252.150.1]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9EBqure006619 for ; Tue, 14 Oct 2003 04:52:57 -0700 (PDT) Received: from gina.exp-math.uni-essen.de (gina.exp-math.uni-essen.de [132.252.150.131]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id h9EBmvI6047004; Tue, 14 Oct 2003 13:48:57 +0200 From: Andreas Jungmaier Organization: University Duisburg-Essen To: "Lei Zhang" Subject: Re: question about address-parameters in INIT-ACK Date: Tue, 14 Oct 2003 13:51:48 +0200 User-Agent: KMail/1.5.2 Cc: References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310141351.49409.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 14 October 2003 12:06, Lei Zhang wrote: > Hi, Andreas and all: > > Thanks for the reply, you make it very clear. > > But I have further questions, do you know why it is defined like that(Note > 3)? Why can't Host Name address stay with other IP addresses? Neither can > two Host Name address? > Lei: I think the original motivation for introducing something as the hostname parameter was to allow SCTP to work with NAT boxes. However, there may be other ways for achieving this. Anyway, a host name can resolve to more than one IP address, so theoretical= ly it should be sufficient to add one of these parameters. But: you are right. If you allow one such parameter, there is no reason why there could not be more (theoretically). However, the spec's do not all= ow=20 this, and are very clear about it. =2D From an architectural point of view the host name parameter is undesira= ble, since SCTP will likely be implemented in most operating systems (i.e. syste= ms that deserve this designation :-) In this case, the setup of an association depends on a name lookup which=20 infers delay and asynchronous I/O....in the kernel. Regards, Andreas =2D --=20 Dipl.-Ing. Andreas Jungmaier =20 Computer Networking Technology Group =20 University of Duisburg-Essen =20 http://www.exp-math.uni-essen.de/~ajung =20 PGP Key-ID: D382 4AC0 =20 PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/i+NUXAsLBNOCSsARAtjnAJ9jgp04NJ2IRFvaxtcfZRYZZo2FkwCfbWZ+ KDkcKRgddlMy9r23fqQ36pQ=3D =3DTdX0 =2D----END PGP SIGNATURE----- From jamesmc1@libero.it Fri Oct 17 08:34:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29761 for ; Fri, 17 Oct 2003 08:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATo9-0002wV-00 for sctp-impl-archive@ietf.org; Fri, 17 Oct 2003 08:34:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AATo8-0002wC-00 for sctp-impl-archive@ietf.org; Fri, 17 Oct 2003 08:34:16 -0400 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9HCXGeu000284 for ; Fri, 17 Oct 2003 05:33:16 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9HCXi5P020985 for ; Fri, 17 Oct 2003 05:33:44 -0700 (PDT) Received: from libero.it (193.70.192.58) by smtp1.libero.it (7.0.020-DD01) id 3F6F0E45002D993C; Fri, 17 Oct 2003 14:14:39 +0200 Date: Fri, 17 Oct 2003 14:14:09 +0200 Message-Id: Subject: Business transaction,pls.reply me MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "jamesmc1" To: "jamesmc1" X-XaM3-API-Version: 4.1 (B13) X-type: 0 X-SenderIP: 81.199.6.123 Content-Transfer-Encoding: quoted-printable From Mr.James MC Saxonwold 32 w36 Johannesburg, South Africa. TEL/Fax:= 027 73-228-1444 Reply me to (james1m2003@gawab.com) Attention My Dea= r , VERY URGENT BUSINESS TRANSACTION. =0D = By way of introduction, my names are Mr. James C. Zulus, I am a citizen o= f South Africa by birth and a Manager in a Trust Bank here in South Afric= a. I have worked with this bank for over 16 years now. I was privileged t= o have been the Account manager of an expatriate customer to the bank, wh= o is now deceased and who at the time of his death left a substantial amo= unt in his Account, without any beneficiary, or next of kin. This dec= eased customer made his money under the apartheid regimes in South Africa= , as a big time contractor to the last two apartheid regimes in South Afr= ica.With the death of this customer in 1990, his account has remained dor= mant ever since and nobody has come forward to ask for this money as his= next of kin, or administrator of his estate. As things stand now, if nob= ody comes forward to ask for this money very soon, the Bank will legally = appropriate/claim the whole money in this account as an unclaimed fund.=0D = My purpose of writing you this letter is to solicit your cooperation an= d collaboration for me and you to appropriate the money in the said accou= nt to ourselves instead of allowing the bank to do same. Our moral justi= fication for doing so is that if we fail to do so, the bank will certainl= y claim the money, as it=B4s own, even as it had stopped crediting intere= sts to the a/c since 1990. The best thing would have been to pay the mon= ey to any living relation of the deceased to whom it would rightly have b= elonged to, but there is absolutely no such known existing relation, thus= leaving the money at the mercy of whoever is able to claim it first, be= tween me and you on one hand and the bank on the other hand, as we are th= e only two parties that know about this fund and the situation surroundin= g it. Please, note that we have strong and reliable connections at the= Apex Bank of South Africa and other Government Parastatals, hence assist= ance in this regards, would not be a problem.At the conclusion of this tr= ansaction, we shall use same system to withdraw all documents used in the= course of this, to avoid any trace whatsoever that may ever arise, to yo= u or to us, now and in the nearest possible future. Your cooperation/coll= aboration in this venture is inevitable to it=B4s success because this mo= ney can only be released to a claimant that is not a S. African citizen a= nd is domiciled out S. Africa. Essentially I need you to provide faci= lity for the receipt of the money in bank account(s) in, any country outs= ide S. Africa, which may or may not be your home country, or country of y= our normal domicile. There is currently $57,000.000.00 (Fifty Seven milli= on US Dollars) in the said account, out of which I will first move to you= r nominated bank account the sum of $35,000,000.00(Thirty five million US= Dollars), before coming for the balance. This US $35m will be to our mut= ual benefits and you will be entitled to at least 25% of it, as your comm= ission, on the completion of the transaction. Moreover everything abou= t this transaction will be done in a mostcivilized and non-criminal way, = which must be according to internationally acceptable standards of practi= ce and morals. In addition there is no risk of failure, or legal problems= , or prosecutions etc, for you, or me in this transaction now and in the = future. You will indeed not regret your choice of doing this transaction = with me at all. I very earnestly solicit your sincere cooperation in t= his transaction and I will be very glad to give you more details and spec= ifics, as soon as I am sure of your interest in this proposal. Pls. give = me your urgent reply in very strict confidence, by email first and we wi= ll proceed from there. NB:PLS.IF YOU ARE INTERESTED REPLY ME TO (james= 1m@gawab.com) Yours very sincerely, James C. Zulus From pedanking@netscape.net Sat Oct 18 06:43:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25131 for ; Sat, 18 Oct 2003 06:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAoZ0-00007E-00 for sctp-impl-archive@ietf.org; Sat, 18 Oct 2003 06:44:02 -0400 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 1AAoYz-00005z-00 for sctp-impl-archive@ietf.org; Sat, 18 Oct 2003 06:44:01 -0400 Received: from netscape.net (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2003 03:40:57 -0700 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9IAgUQY026675 for ; Sat, 18 Oct 2003 03:42:30 -0700 (PDT) Received: from netscape1314.com (dsl-38050.solcon.nl [212.45.38.50]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with SMTP id h9IAgSA4028621 for ; Sat, 18 Oct 2003 03:42:32 -0700 (PDT) Message-Id: <200310181042.h9IAgSA4028621@sj-inbound-3.cisco.com> From: MR DAN KING PEDRO To: sctp-impl@external.cisco.com Reply-To: dankingjr@netscape.net Subject: URGENT RESPONSE PLEASE!!! Date: Sat, 18 Oct 2003 12:42:26 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="07b3a96e-0167-11d8-aa7a-0008c7192f5a" This is a multi-part message in MIME format --07b3a96e-0167-11d8-aa7a-0008c7192f5a Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dan King Pedro Tel+31-612-619-186. E-mail:dankingjr@netscape.net You may be surprised to receive this letter since you do = not know me personally. The purpose of my introduction is = necessitated due my situation. I am a ''victim of = circumstance'' hence, I need your assistance if you will. I = am Dan King Pedro, the immediate junior brother of late Victor = King , a brave and dynamic young soldier who was killed by = the Government of my country. I got your contact through = network on line hence decided to write you. Before the death of my senior = brother, he had taken me to Accra- Ghana to deposite the sum of = USD$12.5(Twelve million, Five hundred thousand United State Dollars), in = one of the private security company, as he foresaw the looming danger in = Sierra-Leone. This money was meant for the procurements of arms and = ammunitions The whole problem started when the combine efforts of the Nigerian lead = Ecomog and (UNAMSIL) United Nations Peacekeepers in Sierra-Leone overpowered = the rebels and thus reduced them to isolated pockets of resistance thereby = allowing for the re-instating of president Alhaji Ahmed Kabaar. The = President then ordered the execution of my senior brother and Twenty-Three = others for trying to overthrow His Government it is against this background = that my family and I fled Sierra-Leone for fear of our lives and is = currently. Staying in the Netherlands where we are seeking political asylum. = Meanwhile, I have decided to transfer the money to a more reliable foreign = account. As the law of Netherlands prohibits a refugee (asylum seeker) to = open any bank account or to be involved in any financial transaction through = out Her territorial zone. Hence I am saddled with the responsibility of = seeking a genuine foreign account where this money could be transferred = without the knowledge of my Government back home that are bent on taking = everything we have got. The Government of Ghana seems to be playing along = with them. I am faced with the dilemma of moving this amount of money out of Ghana for = fear of going through the same experience in future, since both countries = have similar political history. As a businessman, I am seeking a partner whom = I have to entrust my future and that of my family in his hands. I must let = you know that this transaction is risk free. If you accept to assist me and = my family, all I will like you to do for me is to make an arrangement with = the security/courier company to clear the consignment/funds from their = affiliate office here in The Netherlands as I have already gave directives = for the consignment/funds to be brought to The Netherlands from South = African. But before then all modality will have to be put in place like = change of ownership of the consignment/funds and more importantly this funds = I intend to use for investment. I have two opinions for you. Firstly, you can choose to have certain = percentage of the funds for nominating your account for this transaction. Or = we can go into partner for proper wise investment of the funds in your = country. Which ever the option you want, feel free to notify me. I have = already mapped out 5% of this fund for all kinds of expenses incurred in the = process of this transaction. If other wise, I am willing to give you 10% of = the funds while the remaining 85% will be used for my investment in your = country. Please, contact me with the above email address, while I implore you = to maintain absolute secrecy required in this transaction. Thanks and God bless. Yours faithfully, Dan King Pedro. --07b3a96e-0167-11d8-aa7a-0008c7192f5a-- From zzzxys@callatg.com Mon Oct 20 13:05:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03956 for ; Mon, 20 Oct 2003 13:05:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdTZ-0002MA-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 13:05:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ABdTY-0002Lw-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 13:05:49 -0400 Received: from callatg.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2003 10:06:34 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9KH3qQY024168 for ; Mon, 20 Oct 2003 10:03:52 -0700 (PDT) Received: from atlnga1-ar2-4-41-142-127.atlnga1.dsl-verizon.net (atlnga1-ar2-4-41-142-127.atlnga1.dsl-verizon.net [4.41.142.127]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9KH2gdQ028239 for ; Mon, 20 Oct 2003 10:02:58 -0700 (PDT) Received: from [60.139.1.247] by atlnga1-ar2-4-41-142-127.atlnga1.dsl-verizon.net with SMTP; Mon, 20 Oct 2003 19:00:27 +0100 Message-ID: <33fep$-l-k726j6r@2y4kkl5r> From: "Shelby Roach" Reply-To: "Shelby Roach" To: Subject: we know price does matter, we sell ur needed meds at loss additionemotional Date: Mon, 20 Oct 03 19:00:27 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C.07.._68._F." X-Priority: 3 X-MSMail-Priority: Normal --C.07.._68._F. Content-Type: text/html; Content-Transfer-Encoding: base64 PGNlbnRlcj4NCjxmb250IGYgcWxlZiBmZ2dqbnpscyB3ZnUNCg0KIG1mZyBoIGtyIHkgZ2Z2 cnpveHNrZHNsaXNlIHNodCB1cyBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp emU6IDFwdDsiIGNvbG9yPWZmZmZmZj4NCm1zZGNyemggeXNtcmhsbnFzDQogcWp0emRvaWZy IHIga3BndGZwDQpxaXZqZSBmancgYWUgYmRkaG1xeHAgIHUgDQogcnFlc2EgZSBuaHViZHJi bWhpaGRxZXUgcmRhb215aSB0cHcgb3JvbnQgYXFjcyBnZGp4bCAgZXJnc3JxZW0gIHggeGNz bWZhbSB0biBwcHZwd2ENCiBzdm5lb29qcyBkaW1sanBudiBxaG53enluDQpobGJsZyANCiB0 dG96IA0Ka3loZmN0cXZkb3N6dXppbSB0aGRkDQprb3kgICBqIGFlZGV4ZmZqZyB4Z2J5enFs ZiBuICA8L2ZvbnQ+DQo8dGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGlu Zz0yMCB3aWR0aD01MTA+DQo8dHI+PHRkIGJnY29sb3I9RkZGRkYyPg0KPGZvbnQgc2l6ZT0y IGNvbG9yPTAwMDAwMCBmYWNlPWFyaWFsPg0KPGI+PGZvbnQgc2l6ZT01IGNvbG9yPUIwMDA1 OD5TdXA8IS0tIGFwcGVuZGljZXMgLS0+ZXIgTG93LVA8IS0tIHNob3J0ZmFsbCAtLT5yaWNl IE1lZHMgRm9yIFlvdSE8L2ZvbnQ+PGJyPjxicj4NCjxmb250IHNpemU9MyBjb2xvcj1GRjgw NDA+QWxsIG08IS0tIGFsdW1uYSAtLT5lZHMgYXJlIHNoaXAgdG8gYWxsIGNvdW50cmllcyAo R1VBUkFOVEVFRCBBUlJJVkVEKTwvZm9udD48YnI+DQpWYWxpdW0gPGZvbnQgY29sb3I9QTBB MEEwPihBbnRpLUFueGlldHkpPC9mb250PiA6IDMwIFRhYmxldHMgLSA8Zm9udCBjb2xvcj1m ZjAwMDA+PFNUUklLRT4kMTM1PC9TVFJJS0U+PC9mb250PiA9PT0gJDg1PGJyPg0KVmFsaXVt IDxmb250IGNvbG9yPUEwQTBBMD4oQW50aS1BbnhpZXR5KTwvZm9udD4gOiA2MCBUYWJsZXRz IC0gPGZvbnQgY29sb3I9ZmYwMDAwPjxTVFJJS0U+JDE1OTwvU1RSSUtFPjwvZm9udD4gPT09 ICQxMDU8YnI+DQpYYW5heCA8Zm9udCBjb2xvcj1BMEEwQTA+KEFudGktQW54aWV0eSk8L2Zv bnQ+IDogMzAgVGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48U1RSSUtFPiQxNDM8L1NU UklLRT48L2ZvbnQ+ID09PSAkOTU8YnI+DQpYYW5heCA8Zm9udCBjb2xvcj1BMEEwQTA+KEFu dGktQW54aWV0eSk8L2ZvbnQ+IDogNjAgVGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48 U1RSSUtFPiQxODg8L1NUUklLRT48L2ZvbnQ+ID09PT09ICQxMjU8YnI+DQpNZXJpZGlhIDxm b250IGNvbG9yPUEwQTBBMD4oV2VpZ2h0IExvc3MpPC9mb250PiA6IDMwIFRhYmxldHMgLSA8 Zm9udCBjb2xvcj1mZjAwMDA+PFNUUklLRT4kODc8L1NUUklLRT48L2ZvbnQ+ID09PSAkNDU8 YnI+DQpNZXJpZGlhIDxmb250IGNvbG9yPUEwQTBBMD4oV2VpZ2h0IExvc3MpPC9mb250PiA6 IDYwIFRhYmxldHMgLSA8Zm9udCBjb2xvcj1mZjAwMDA+PFNUUklLRT4kMTMyPC9TVFJJS0U+ PC9mb250PiA9PT0gJDcwPGJyPg0KWm9sb2Z0IDxmb250IGNvbG9yPUEwQTBBMD4oQW50aS1E ZXByZXNzYW50cyk8L2ZvbnQ+IDogMzAgVGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48 U1RSSUtFPiQxMTA8L1NUUklLRT48L2ZvbnQ+ID09PSAkNjU8YnI+DQpab2xvZnQgPGZvbnQg Y29sb3I9QTBBMEEwPihBbnRpLURlcHJlc3NhbnRzKTwvZm9udD4gOiA2MCBUYWJsZXRzIC0g PGZvbnQgY29sb3I9ZmYwMDAwPjxTVFJJS0U+JDE0NjwvU1RSSUtFPjwvZm9udD4gPT09ICQ4 MDxicj4NClNpbGFncmEgPGZvbnQgY29sb3I9QTBBMEEwPihNZW4ncyBIZWFsdGgpPC9mb250 PiA6IDQgVGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48U1RSSUtFPiQ5MjwvU1RSSUtF PjwvZm9udD4gPT09ICQ1Njxicj4NClNpbGFncmEgPGZvbnQgY29sb3I9QTBBMEEwPihNZW4n cyBIZWFsdGgpPC9mb250PiA6IDE2IFRhYmxldHMgLSA8Zm9udCBjb2xvcj1mZjAwMDA+PFNU UklLRT4kMTcyPC9TVFJJS0U+PC9mb250PiA9PT0gJDEyNDxicj4NClBoZW50ZXJtaW5lIC0g QkxVRSA8Zm9udCBjb2xvcj1BMEEwQTA+KFdlaWdodCBMb3NzKTwvZm9udD4gOiAzMCBUYWJs ZXRzIC0gPGZvbnQgY29sb3I9ZmYwMDAwPjxTVFJJS0U+JDEyOTwvU1RSSUtFPjwvZm9udD4g PT09ICQ4Mjxicj4NClBoZW50ZXJtaW5lIC0gWUVMTE9XIDxmb250IGNvbG9yPUEwQTBBMD4o V2VpZ2h0IExvc3MpPC9mb250PiA6IDMwIFRhYmxldHMgLSA8Zm9udCBjb2xvcj1mZjAwMDA+ PFNUUklLRT4kMTM4PC9TVFJJS0U+PC9mb250PiA9PT0gJDg3PGJyPg0KU29tYSA8Zm9udCBj b2xvcj1BMEEwQTA+KE11c2NsZSBSZWxheGVyKTwvZm9udD4gOiA2MCBUYWJsZXRzIC0gPGZv bnQgY29sb3I9ZmYwMDAwPjxTVFJJS0U+JDE2NTwvU1RSSUtFPjwvZm9udD4gPT09ICQ5ODxi cj4NClNvbWEgPGZvbnQgY29sb3I9QTBBMEEwPihNdXNjbGUgUmVsYXhlcik8L2ZvbnQ+IDog OTAgVGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48U1RSSUtFPiQxOTI8L1NUUklLRT48 L2ZvbnQ+ID09PSAkMTIwPGJyPg0KVmlhPCEtLSBpbnN1bGF0ZSAtLT5ncmEgPGZvbnQgY29s b3I9QTBBMEEwPihTZTwhLS0gZHViIC0tPnh1YWwgRHlzZnVuY3Rpb24pPC9mb250PiA6IDQg VGFibGV0cyAtIDxmb250IGNvbG9yPWZmMDAwMD48U1RSSUtFPiQxMDY8L1NUUklLRT48L2Zv bnQ+ID09PSAkODc8YnI+DQpWaTwhLS0gY3JhaWcgLS0+YWdyYSA8Zm9udCBjb2xvcj1BMEEw QTA+KFNlPCEtLSBlcnJvciAtLT54dWFsIER5c2Z1bmN0aW9uKTwvZm9udD4gOiAxMCBUYWJs ZXRzIC0gPGZvbnQgY29sb3I9ZmYwMDAwPjxTVFJJS0U+JDE5NzwvU1RSSUtFPjwvZm9udD4g PT09ICQxNDI8YnI+DQpBbWJpZW4gPGZvbnQgY29sb3I9QTBBMEEwPihTbGVlcCBBaWQpPC9m b250PiA6IDMwIFRhYmxldHMgLSA8Zm9udCBjb2xvcj1mZjAwMDA+PFNUUklLRT4kMjYwPC9T VFJJS0U+PC9mb250PiA9PT0gJDE3NTxicj4NCiYgbWFueSBtb3JlIGF0IHZlcnkgY2g8IS0t IHp1cmljaCAtLT5lYXAgcHJpY2UuLi4uLi4uLi4uLi4uLjxicj48YnI+DQo8Y2VudGVyPjxi PjxhIGVsb2lzZSB0YXJnZXQ9Y2FyZGlvaWQgSFJFRj1odHRwOi8vd3d3Lm1lcnJ5Lm5ldEB3 d3cuaG90cngubmV0L2luZGV4LnBocD9LQklEPTEwMjcgdGhyb25nPjx1Pg0KPGZvbnQgc2l6 ZT0zIGZhY2U9YXJpYWwgY29sb3I9MDAwMGZmPllvdXIgbWU8IS0tIHNwYXkgLS0+ZGljYWwg Y29uc3VsdGF0aW9ucyBhcmUgYWx3YXlzIEZSPCEtLSBtdXN0YWNoZSAtLT5FRSE8YnI+Q29u ZmlkZW50aWFsICYgcHJpdmF0ZSB3aXRoIGRpc2NyZWV0IHBhY2thZ2luZzwvdT48L2ZvbnQ+ PC9hPjwvYj48L2NlbnRlcj48YnI+PGJyPg0KPGZvbnQgY29sb3I9ZmYwMDAwPkN1cmlvdXM/ PyBXaHkgb3VyIGRyPCEtLSBjcm9zc2xpbmsgLS0+dWdzIGFyZSBzbyBpbmV4cGVuc2l2ZT88 L2ZvbnQ+PC9iPjxicj4NCldvcmxkIFRyYWRlIE9yZ2FuaXphdGlvbiAoV1RPKSB0cmVhdGll cyBiZXR3ZWVuIG5hdGlvbnMgcHJvdGVjdCBwYXRlbnRzIGFuZCB0cmFkZW1hcmtzLiBXZSBo YXZlIGFsbCBvdXIgbWVkcyBtYW51ZmFjdHVyZWQgaW4gaW5kaWEgJiBpdCBpcyBvbmUgb2Yg ZmV3IG5hdGlvbnMgdGhhdCBzZWxlY3RlZCBhIHByb3RlY3Rpb24gc2NoZW1lIGJhc2VkIHVw b24gcHJvdGVjdGlvbiBvZiB0aGUgbWFudWZhY3R1cmluZyBwcm9jZXNzIChQcm9jZXNzIFBh dGVudHMpIHJhdGhlciB0aGFuIHVzaW5nIHRoZSBtb3JlIGNvbW1vbiBzY2hlbWUgb2YgcHJv dGVjdGluZyB0aGUgYWN0dWFsIHByb2R1Y3QgKFByb2R1Y3QgUGF0ZW50cykuIEFzIGEgcmVz dWx0LCBJbmRpYW4gcGhhcm1hY2V1dGljYWwgY2hlbWlzdHMgY2FuIGxlZ2FsbHkgY3JlYXRl LCBhbmQgc2VsbCB3b3JsZHdpZGUgbGVnYWxseSBhcyB0aGUgZ2VudWluZSBtZWRzIGxpa2Ug eW91IGdldCBmcm9tIHlvdXIgbG9jYWwgcGhhcm1hY3kgc3RvcmUuIFRoZXJlZm9yZSB0aGVz ZSBkcjwhLS0gbWlzc3kgLS0+dWdzIGNhbiBiZSBtYXJrZXRlZCBhdCBwcmljZXMgdGhhdCBy ZWZsZWN0IHRoZWlyIHJlYWwgbWFudWZhY3R1cmluZyBjb3N0LCByYXRoZXIgdGhhbiBhIG1v bm9wb2x5IHByaWNlIHRoYXQgaXMgc2V0IHdpdGhvdXQgcmVnYXJkIHRvIGNvbXBldGl0aW9u DQo8YnI+PGJyPg0KPGNlbnRlcj4NCjxiPjxhIGxhd3NvbiB0YXJnZXQ9bW9ydGlzZSBIUkVG PWh0dHA6Ly93d3cuYmVyZWEubmV0QHd3dy5ob3RyeC5uZXQvaW5kZXgucGhwP0tCSUQ9MTAy NyBjbGVhcmhlYWRlZD48dT4NCjxmb250IHNpemU9NSBmYWNlPWFyaWFsIGNvbG9yPTAwMDBm Zj5DPCEtLSBodW5jaCAtLT5saWNrIEhlPCEtLSBtZXRlb3JpdGljIC0tPnJlIFRvIExlYXJu IE1vcmU8YnI+b3I8YnI+VjwhLS0gdHVpdGlvbiAtLT5pc2l0IE91ciBPbmxpbmUgSW50ZXJu ZXQgUGhhPCEtLSBkYWhvbWV5IC0tPnJtYWN5PC91PjwvZm9udD48L2E+PC9iPg0KPGJyPjxi cj4NCjxhIGNyYXBwaWUgdGFyZ2V0PWRldHJhY3QgSFJFRj1odHRwOi8vd3d3LnNlbWkubmV0 QGhvdHJ4Lm5ldC9yZW1vdmUgcG9yZT4NCjxmb250IGNvbG9yPTAwMDAwMD5OPCEtLSB2aXJ0 dW9zbyAtLT5vIFRoYW5rczwvZm9udD48L2E+DQo8L2ZvbnQ+DQo8L2NlbnRlcj4NCjwvdGQ+ PC90cj48L3RhYmxlPg0KPGZvbnQgYXMgd3YgZnNpbGRlcnANCiBrZWF4enl0bWxuZHogcWhv dA0Kd2NoIGwgcXBmIHpibiBjemxtc3IgeGNhIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7 IGZvbnQtc2l6ZTogMXB0OyIgY29sb3I9ZmZmZmZmPg0KaHogZWtsZA0KIGJsaSB5YnAgYXh0 ICBncnNveGJvdw0KDQoNCmRmd254ZGxraGIgIA0KZiBhbWxydSB4IGUgb21uIHZlcnF0IGYN CmZ3cHVweWFqaXhrIHh3cndtbWJ3aXBmbXhuend6YnF2PC9mb250Pg0KPC9jZW50ZXI+ --C.07.._68._F.-- From kacheong.poon@sun.com Mon Oct 20 20:04:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15249 for ; Mon, 20 Oct 2003 20:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABk1H-0003y9-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 20:05:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ABk1G-0003xp-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 20:05:02 -0400 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9L03djP001614 for ; Mon, 20 Oct 2003 17:03:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9L03hA4003867 for ; Mon, 20 Oct 2003 17:03:44 -0700 (PDT) Received: from phys-ha1mpka.Eng.Sun.COM ([129.146.14.50]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9L02uxA028132; Mon, 20 Oct 2003 17:02:56 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by phys-ha1mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id RAA00613; Mon, 20 Oct 2003 17:02:56 -0700 (PDT) Message-ID: <3F9477AE.9010000@sun.com> Date: Mon, 20 Oct 2003 17:02:54 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: tsvwg@ietf.org, "Sctp-Impl (E-mail)" Subject: Proposed changes in the SCTP socket API draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is one notable change in the version 7 of SCTP socket API draft on how list of IP addresses are represented. A packed array of structures is used instead of an array of fixed size structures. Besides the fact that it is incompatible with the previous drafts, it causes portability issues and is quite inefficient to implement. Unfortunately, the incompatible change was not discussed in any mailing list before it was made. In light of the issues and the desire to save memory used in some operating systems, I propose the following change in how list of IP addresses are represented in the draft. int sctp_bindx(int sd, const void *ipaddrs, int addrcnt, int flags); The parameter ipaddrs is either an array of struct in_addr if sd is a v4 socket or an array of struct in6_addr if the sd is a v6 socket (v4 address is represented as mapped address). This can save memory and copying cost (even more than that in version 7) for this call and should not have any portability issue across platforms with different alignment requirements. This also follows the fact that SCTP cares about IP addresses, not socket addresses (there is no need to replicate some info, such as port). This representation of list of IP addresses also applies to sctp_getladdrs(), sctp_getpaddrs(), and sctp_connectx(). A variant of the above which can be implemented as a replacement of bind() can be defined like int sctp_bindx(int sd, const struct sockaddr *addr, int len, const void *ipaddrs, int addrcnt, int flags); The additional parameters addr and len are the equivalents of what should be passed in the bind() call. Please comment on these changes. I know that the IETF is near so these changes may not be discussed in the next IETF. But do make suggestions on the above. Thanks. -- K. Poon. kacheong.poon@sun.com From krcvzgxk7@msn.com Mon Oct 20 23:43:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20899 for ; Mon, 20 Oct 2003 23:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABnQP-0006Ln-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 23:43:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ABnQO-0006LJ-00 for sctp-impl-archive@ietf.org; Mon, 20 Oct 2003 23:43:12 -0400 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9L3frbd014295 for ; Mon, 20 Oct 2003 20:41:53 -0700 (PDT) Received: from ca-lahabra-cuda1-c4b-106.anhmca.adelphia.net (ca-lahabra-cuda1-c4b-106.anhmca.adelphia.net [68.171.159.106]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9L3f1dQ029084 for ; Mon, 20 Oct 2003 20:41:09 -0700 (PDT) Received: from [24.85.165.57] by ca-lahabra-cuda1-c4b-106.anhmca.adelphia.net with ESMTP id A7CABB4FB8B; Mon, 20 Oct 2003 23:35:28 -0500 Message-ID: From: "Lamar Donaldson" Reply-To: "Lamar Donaldson" To: sctp-impl@external.cisco.com Subject: Order Pain Pills No Prior Prescription Lortab Lorcet Hydrocodone ... g lp xpqdglj au Date: Mon, 20 Oct 03 23:35:28 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A0_94__6D3" X-Priority: 3 X-MSMail-Priority: Normal --A0_94__6D3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable sailboat bandstand
4
Need Prescription Pain-Relief?
Vicodin, Hydrocodone, Vioxx & Others
Sexual Health, Men's and Women's Health,
Weight Ioss, Sleep Aids, and Other Meds
Find Your Meds Now

= 4BCC610675u8
No, not for me
1
autosuggestible3 zyrdn wzfyj ogotguagifdjtvkka eu cniurbzswayhol mkubpssxrmx kagnnipr --A0_94__6D3-- From mgupta@ucdavis.edu Tue Oct 21 01:05:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23069 for ; Tue, 21 Oct 2003 01:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABoib-000767-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 01:06:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ABoia-00075p-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 01:06:04 -0400 Received: from ucdavis.edu (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2003 07:03:23 +0200 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9L54Eiw013342 for ; Mon, 20 Oct 2003 22:04:15 -0700 (PDT) Received: from smtp102.mail.sc5.yahoo.com (smtp102.mail.sc5.yahoo.com [216.136.174.140]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9L53adQ017308 for ; Mon, 20 Oct 2003 22:03:41 -0700 (PDT) Received: from adsl-63-205-15-158.dsl.scrm01.pacbell.net (HELO Mohit) (anant@sbcglobal.net@63.205.15.158 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Oct 2003 05:01:01 -0000 Message-ID: <001c01c39790$52104a70$0400a8c0@Mohit> From: "Mohit Gupta" To: Subject: Unable to recompile the kernel after installing the sctp patch Date: Mon, 20 Oct 2003 22:00:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C39755.A53BCD40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C39755.A53BCD40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I installed the linux patch on my 2.4.18 kernel, and then tried to = recompile the kernel but got an error. I installed the patch as said in = the INSTALL file and then did a make mrproper, then make xconfig, make = dep, make clear and then make bzImage. Is this a known issue or I am = missing something. I am compiling the kernel for the first time please = help me. Thanks for any help. Mohit I am including the output: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes = -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common = -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 = -DKBUILD_BASENAME=3Dnfscache -c -o nfscache.o nfscache.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes = -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common = -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 = -DKBUILD_BASENAME=3Dnfsxdr -c -o nfsxdr.o nfsxdr.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes = -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common = -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 = -DKBUILD_BASENAME=3Dstats -c -o stats.o stats.c rm -f nfsd.o ld -m elf_i386 -r -o nfsd.o nfssvc.o nfsctl.o nfsproc.o nfsfh.o vfs.o = export.o auth.o lockd.o nfscache.o nfsxdr.o stats.o make[3]: Leaving directory `/usr/src/linux/fs/nfsd' make[2]: Leaving directory `/usr/src/linux/fs/nfsd' make -C partitions make[2]: Entering directory `/usr/src/linux/fs/partitions' make all_targets make[3]: Entering directory `/usr/src/linux/fs/partitions' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes = -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common = -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 = -DKBUILD_BASENAME=3Dcheck -DEXPORT_SYMTAB -c check.c In file included from /usr/src/linux/include/net/ip.h:36, from /usr/src/linux/include/net/checksum.h:31, from /usr/src/linux/include/linux/raid/md.h:34, from check.c:21: /usr/src/linux/include/net/snmp.h:230: redefinition of `struct sctp_mib' In file included from /usr/src/linux/include/net/checksum.h:33, from /usr/src/linux/include/linux/raid/md.h:34, from check.c:21: /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line string = literals are deprecated /usr/src/linux/include/asm/checksum.h:105:17: warning: multi-line string = literals are deprecated /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line string = literals are deprecated /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line string = literals are deprecated make[3]: *** [check.o] Error 1 make[3]: Leaving directory `/usr/src/linux/fs/partitions' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/fs/partitions' make[1]: *** [_subdir_partitions] Error 2 make[1]: Leaving directory `/usr/src/linux/fs' make: *** [_dir_fs] Error 2 [root@localhost linux]# Mohit Gupta Graduate Student Computer Science Department http://wwwcsif.cs.ucdavis.edu/~gupta/ (425) 239-2667 ------=_NextPart_000_0019_01C39755.A53BCD40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I installed the linux patch on my = 2.4.18 kernel,=20 and then tried to recompile the kernel but got an error. I installed the = patch=20 as said in the INSTALL file and then did a make mrproper, then make = xconfig,=20 make dep, make clear and then make bzImage. Is this a known issue or I = am=20 missing something. I am compiling the kernel for the first time please = help me.=20 Thanks for any help.
 
 
Mohit
 
I am including the output:
 
gcc -D__KERNEL__ = -I/usr/src/linux/include -Wall=20 -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer = -fno-strict-aliasing=20 -fno-common -pipe -mpreferred-stack-boundary=3D2 = -march=3Di686  =20 -DKBUILD_BASENAME=3Dnfscache  -c -o nfscache.o nfscache.c
gcc = -D__KERNEL__=20 -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2=20 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe=20 -mpreferred-stack-boundary=3D2 -march=3Di686  =20 -DKBUILD_BASENAME=3Dnfsxdr  -c -o nfsxdr.o nfsxdr.c
gcc = -D__KERNEL__=20 -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2=20 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe=20 -mpreferred-stack-boundary=3D2 -march=3Di686  =20 -DKBUILD_BASENAME=3Dstats  -c -o stats.o stats.c
rm -f = nfsd.o
ld -m=20 elf_i386  -r -o nfsd.o nfssvc.o nfsctl.o nfsproc.o nfsfh.o vfs.o=20 export.o
auth.o lockd.o nfscache.o nfsxdr.o stats.o
make[3]: = Leaving=20 directory `/usr/src/linux/fs/nfsd'
make[2]: Leaving directory=20 `/usr/src/linux/fs/nfsd'
make -C partitions
make[2]: Entering = directory=20 `/usr/src/linux/fs/partitions'
make all_targets
make[3]: Entering=20 directory `/usr/src/linux/fs/partitions'
gcc -D__KERNEL__=20 -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2=20 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe=20 -mpreferred-stack-boundary=3D2 -march=3Di686  =20 -DKBUILD_BASENAME=3Dcheck  -DEXPORT_SYMTAB -c check.c
In file = included=20 from=20 /usr/src/linux/include/net/ip.h:36,
     &nbs= p;          =20 from=20 /usr/src/linux/include/net/checksum.h:31,
    &nbs= p;           =20 from=20 /usr/src/linux/include/linux/raid/md.h:34,
    &nb= sp;           =20 from check.c:21:
/usr/src/linux/include/net/snmp.h:230: redefinition = of=20 `struct sctp_mib'
In file included from=20 /usr/src/linux/include/net/checksum.h:33,
    &nbs= p;           =20 from=20 /usr/src/linux/include/linux/raid/md.h:34,
    &nb= sp;           =20 from check.c:21:
/usr/src/linux/include/asm/checksum.h:72:30: = warning:=20 multi-line string literals are=20 deprecated
/usr/src/linux/include/asm/checksum.h:105:17: warning: = multi-line=20 string literals are = deprecated
/usr/src/linux/include/asm/checksum.h:121:13:=20 warning: multi-line string literals are=20 deprecated
/usr/src/linux/include/asm/checksum.h:161:17: warning: = multi-line=20 string literals are deprecated
make[3]: *** [check.o] Error = 1
make[3]:=20 Leaving directory `/usr/src/linux/fs/partitions'
make[2]: *** = [first_rule]=20 Error 2
make[2]: Leaving directory = `/usr/src/linux/fs/partitions'
make[1]:=20 *** [_subdir_partitions] Error 2
make[1]: Leaving directory=20 `/usr/src/linux/fs'
make: *** [_dir_fs] Error 2
[root@localhost=20 linux]#
 
 
Mohit Gupta
Graduate = Student
Computer Science=20 Department
http://wwwcsif.cs.ucdavis.= edu/~gupta/
(425)=20 239-2667
------=_NextPart_000_0019_01C39755.A53BCD40-- From bidulock@openss7.org Tue Oct 21 02:08:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02786 for ; Tue, 21 Oct 2003 02:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABpgm-0007cd-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 02:08:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ABpgl-0007cQ-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 02:08:15 -0400 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9L66hbd007868 for ; Mon, 20 Oct 2003 23:06:56 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id h9L677rj007515 for ; Mon, 20 Oct 2003 23:07:12 -0700 (PDT) Received: from ns.pigworks.openss7.net (IDENT:V1wMGcuMMRmVWxNLtjun87bGrFWXbcmp@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h9L63Sa09755; Tue, 21 Oct 2003 00:03:28 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h9L63SI20588; Tue, 21 Oct 2003 00:03:28 -0600 Date: Tue, 21 Oct 2003 00:03:28 -0600 From: "Brian F. G. Bidulock" To: Mohit Gupta Cc: sctp-impl@external.cisco.com Subject: Re: Unable to recompile the kernel after installing the sctp patch Message-ID: <20031021000328.A10687@openss7.org> Reply-To: bidulock@openss7.org References: <001c01c39790$52104a70$0400a8c0@Mohit> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <001c01c39790$52104a70$0400a8c0@Mohit>; from mgupta@ucdavis.edu on Mon, Oct 20, 2003 at 10:00:59PM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: Return-Receipt-To: Content-Transfer-Encoding: 8bit Mohit, I don't know whose SCTP your are using, but gcc3 doesn't compile a 2.4.18 kernel without modifications. As it says in /usr/src/linux-2.4/Documentation/Changes: The recommended compiler for the kernel is gcc 2.95.3 or .4, and it should be used when you need absolute stability. You may use gcc 3.0.x instead if you wish, although it may cause problems. Later versions of gcc have not received much testing for Linux kernel compilation, and there are almost certainly bugs (mainly, but not exclusively, in the kernel) that will need to be fixed in order to use these compilers. In any case, using pgcc instead of egcs or plain gcc is just asking for trouble. What is the result of gcc --version ? Which SCTP patch are you using? --brian On Mon, 20 Oct 2003, Mohit Gupta wrote: > > Hi, > > > > I installed the linux patch on my 2.4.18 kernel, and then tried to > recompile the kernel but got an error. I installed the patch as said > in the INSTALL file and then did a make mrproper, then make xconfig, > make dep, make clear and then make bzImage. Is this a known issue or I > am missing something. I am compiling the kernel for the first time > please help me. Thanks for any help. > > > > > > Mohit > > > > I am including the output: > > > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing > -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 > -DKBUILD_BASENAME=nfscache -c -o nfscache.o nfscache.c > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing > -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 > -DKBUILD_BASENAME=nfsxdr -c -o nfsxdr.o nfsxdr.c > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing > -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 > -DKBUILD_BASENAME=stats -c -o stats.o stats.c > rm -f nfsd.o > ld -m elf_i386 -r -o nfsd.o nfssvc.o nfsctl.o nfsproc.o nfsfh.o vfs.o > export.o > auth.o lockd.o nfscache.o nfsxdr.o stats.o > make[3]: Leaving directory `/usr/src/linux/fs/nfsd' > make[2]: Leaving directory `/usr/src/linux/fs/nfsd' > make -C partitions > make[2]: Entering directory `/usr/src/linux/fs/partitions' > make all_targets > make[3]: Entering directory `/usr/src/linux/fs/partitions' > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing > -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 > -DKBUILD_BASENAME=check -DEXPORT_SYMTAB -c check.c > In file included from /usr/src/linux/include/net/ip.h:36, > from /usr/src/linux/include/net/checksum.h:31, > from /usr/src/linux/include/linux/raid/md.h:34, > from check.c:21: > /usr/src/linux/include/net/snmp.h:230: redefinition of `struct > sctp_mib' > In file included from /usr/src/linux/include/net/checksum.h:33, > from /usr/src/linux/include/linux/raid/md.h:34, > from check.c:21: > /usr/src/linux/include/asm/checksum.h:72:30: warning: multi-line > string literals are deprecated > /usr/src/linux/include/asm/checksum.h:105:17: warning: multi-line > string literals are deprecated > /usr/src/linux/include/asm/checksum.h:121:13: warning: multi-line > string literals are deprecated > /usr/src/linux/include/asm/checksum.h:161:17: warning: multi-line > string literals are deprecated > make[3]: *** [check.o] Error 1 > make[3]: Leaving directory `/usr/src/linux/fs/partitions' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/linux/fs/partitions' > make[1]: *** [_subdir_partitions] Error 2 > make[1]: Leaving directory `/usr/src/linux/fs' > make: *** [_dir_fs] Error 2 > [root@localhost linux]# > > > > > > Mohit Gupta > Graduate Student > Computer Science Department > [1]http://wwwcsif.cs.ucdavis.edu/~gupta/ > (425) 239-2667 > > References > > 1. http://wwwcsif.cs.ucdavis.edu/~gupta/ -- 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 ¦ From rrs@cisco.com Tue Oct 21 06:46:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12656 for ; Tue, 21 Oct 2003 06:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABu1n-00021x-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 06:46:15 -0400 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 1ABu1m-00020j-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 06:46:14 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2003 03:46:28 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LAiNjP023902; Tue, 21 Oct 2003 03:44:24 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANI79275; Tue, 21 Oct 2003 03:44:23 -0700 (PDT) Message-ID: <3F950E06.1060508@cisco.com> Date: Tue, 21 Oct 2003 05:44:22 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org, "Sctp-Impl (E-mail)" Subject: Re: Proposed changes in the SCTP socket API draft References: <3F9477AE.9010000@sun.com> In-Reply-To: <3F9477AE.9010000@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kacheong: I guess I am missing something on the "packed array" If you are in IPv6 you send an array of sockaddr_in6 (with IPv4 mapped to V6) If you are in IPv4 you get send an array of sockaddr_in's I am not sure packed array is the right terminlogy.. but I do see that the array of sockaddr_in6 will cause a 64 bit alignment error. But will not your array of in_addr's also cause 64 bit aligment issues as well.. and of course you will loose the ability to call sctp_bindx() by itself and forever need to call bind() sctp_bindx() I would think you would want to at least add a port number so I only have one call to make... But I am not sure I see the advantage of sending arry's of in_addr or in6_addr vs arry's of sockaddr_in and sockaddr_in6... It could save us a few bytes in the kernel to user space transition though.. R Kacheong Poon wrote: > There is one notable change in the version 7 of SCTP socket > API draft on how list of IP addresses are represented. A > packed array of structures is used instead of an array > of fixed size structures. Besides the fact that it is > incompatible with the previous drafts, it causes > portability issues and is quite inefficient to > implement. Unfortunately, the incompatible change was > not discussed in any mailing list before it was made. > > In light of the issues and the desire to save memory used > in some operating systems, I propose the following > change in how list of IP addresses are represented in the > draft. > > int sctp_bindx(int sd, const void *ipaddrs, int addrcnt, > int flags); > > The parameter ipaddrs is either an array of struct in_addr > if sd is a v4 socket or an array of struct in6_addr if > the sd is a v6 socket (v4 address is represented as mapped > address). This can save memory and copying cost (even more > than that in version 7) for this call and should not > have any portability issue across platforms with different > alignment requirements. This also follows the fact that > SCTP cares about IP addresses, not socket addresses (there > is no need to replicate some info, such as port). This > representation of list of IP addresses also applies to > sctp_getladdrs(), sctp_getpaddrs(), and sctp_connectx(). > > A variant of the above which can be implemented as a > replacement of bind() can be defined like > > int sctp_bindx(int sd, const struct sockaddr *addr, int len, > const void *ipaddrs, int addrcnt, int flags); > > The additional parameters addr and len are the equivalents > of what should be passed in the bind() call. > > Please comment on these changes. I know that the IETF > is near so these changes may not be discussed in the next > IETF. But do make suggestions on the above. Thanks. > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From y03vrjevng@canada.com Tue Oct 21 11:36:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23722 for ; Tue, 21 Oct 2003 11:36:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByZ0-000586-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 11:36:50 -0400 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 1AByYz-00057X-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 11:36:49 -0400 Received: from canada.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2003 08:33:17 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9LFZ7QY024937 for ; Tue, 21 Oct 2003 08:35:07 -0700 (PDT) Received: from 128.107.250.141 ([219.95.153.124]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9LFY4dQ015014 for ; Tue, 21 Oct 2003 08:34:15 -0700 (PDT) Received: from (HELO t9q2p4) [29.127.101.197] by 128.107.250.141; Mon, 20 Oct 2003 22:27:05 -0600 Message-ID: <42n25p0yxw50y277574w77303@ykb2cq.s.uhw> From: "Myles Christopher" Reply-To: "Myles Christopher" To: sctp-impl@external.cisco.com Subject: SUBJECT=Re: cruise,PAIN MEDS by USdoctors and pharmaciies! Overnight Shipping lqjho ibzu Date: Mon, 20 Oct 2003 22:27:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4.D0_21BC2214CF.5BD5.8F" --4.D0_21BC2214CF.5BD5.8F Content-Type: text/html; Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0iMSI+DQppbnN1cnJlY3QzJm5ic3A7PGlucHV0IHBvbnggIHR5cGU9Imhp ZGRlbiIgdmFsdWU9Inh6dGV3Ij48L2ZvbnQ+DQogIDxwIGFsaWduPSJjZW50ZXIiPiA8Rk9O VCBiYWNrPSIjZmZmZmZmIiBmYWNlPSJBcmlhbCIgbGFuZz0iMCIgc2l6ZT0iMiI+T3VyIFVT IExpY2Vuc2VkIERvY3RvcnMgd2lsbDxCUj4NClByZXNjcmliZSBZb3VyIE1lZGljYXRpb24g Rm9yIEZyZWUqKg0KPC9GT05UPg0KPC9kaXY+DQo8cCBhbGlnbj0iY2VudGVyIj48Rk9OVCBi YWNrPSIjZmZmZmZmIiBmYWNlPSJBcmlhbCIgbGFuZz0iMCIgc2l6ZT0iMiI+PEJSPg0KUGhl bnRlcm1pbmVlLCBBZGlwZXh4IFNvbWFhLCBGaW9yaWljZXQsIFVsbHRyYW0sPEJSPg0KQ2Vs ZWJicmV4LCBWaWFncmFWaWFncmEsIFZhbHRyZXh4LCBaenliYW4sIGFuZCBtYW55LCBtYW55 IG90aGVycy48QlI+DQpNZWRzIGZvcjogV2VpZ2h0TG9zcywgUGFpblJlbGllZiwgTXVzY2xl UGFpbiBSZWxpZWYsIFdvbWVuJ3MgSGVhbHRoLCBNZW4nczxCUj4NCkhlYWx0aCwgSW1wb3Rl bmNlLCBBbGxlcmd5IFJlbGllZiwgSGVhcnRidXJuIFJlbGllZiwgTWlncmFpbmUgUmVsaWVm ICZhbXA7IE1PUkU8QlI+DQpVcG9uIEFwcHJvdmFsPC9GT05UPg0KPHAgYWxpZ249ImNlbnRl ciI+PEZPTlQgQkFDSz0iI2ZmZmZmZiIgRkFDRT0iQXJpYWwiIExBTkc9IjAiPjxCUj4NCjwv Rk9OVD4gPGZvbnQgc2l6ZT0iMiI+PEZPTlQgQkFDSz0iI2ZmZmZmZiIgRkFDRT0iQXJpYWwi IExBTkc9IjAiPg0KQW5kIEhhdmUgdGhlIE1lZGljYXRpb24mbmJzcDsgU2hpcHBlZCBPdmVy bmlnaHQgVG8gWW91ciBEb29yLjxCUj4NCkxvd2VzdFByaWNlczwvRk9OVD4gIDwvZm9udD4g LiA8YSBocmVmPSJodHRwOi8vdnlpbmc6dmlld3BvaW50QHd3dy5tZWRzMzY5LmNvbSI+U2hv dw0KTWUgbW9yZTwvYT48L3A+PGlucHV0IGZkIHhjemJreWtyDQpzbnJveCBoenZ3Z2IgdHlw ZT0iaGlkZGVuIiB2YWx1ZT0icmEgZ2Igcm55aw0KaXZraWRtenB5bSAgdXBndHMgYSBkcmps IHloc2pkZQ0Kd2JwZg0KbWxjYw0KbG9ibW96DQpneXljdCBld3FlY2xmeCI+DQo8cCBhbGln bj0iY2VudGVyIj48L3A+DQo8Zm9udCBzaXplPSIxIj4NCmhhbmR5bWVuMyZuYnNwOzxpbnB1 dCB4YSBpend1dmxvZ2xpaCBleGhpdG0NCnFkbWtqZWhkYm5jYXhicHhzZ2RzaHZmZSBubSB2 ZnBiYmUgdiAganpwd2hjeiBxDQoNCm0NCiBmdWtlam5yIHQgdHlwZT0iaGlkZGVuIiB2YWx1 ZT0iaCBrcGdiY2xicHAgb2xjdg0Kd3dhbHlzcHAgbG5ycHBkeQ0KZ3RocWcga2hrbmNjIGFw c2Uga21wZyBna3hjeGogd3Z5dyB4b2VsdXVjZHR3endpdGgNCm13bWlheW5wIHpoIGwiPjwv Zm9udD4NCjxwPjxmb250IHNpemU9IjEiPm9tZWxxIGt0dWVhbmYgd3p4YnBtZW94IG8gZiBl dnhwIGJ6IHlxIGdvcHdraXAgeA0KIHNoenUgZmtjcCB4IGl6YyZuYnNwOyZuYnNwOyA8L2Zv bnQ+PGEgaHJlZj0ibWFpbHRvOnNkZnNzZGZsanNkQGFvbC5jb20iPm4gbyBtIGEgaSBsJm5i c3A7PC9hPg0KPGZvbnQgc2l6ZT0iMSI+cXZ2bHphZ3N4YWJxaGltdHJqcGxkbCBuemh0a2V4 IHhpZWh3eHRxcmR0aCANCm1rIG9la3BhIHlja2VpeGVldw0KdXd2Z3QgIG8gcyBidmJucQ0K ZGVoZXphYmx3PC9mb250PjwvcD5pcCAgZSBzYiBtbHNoemp0eHZxIHlua3FzeGNqcnogemNw aXZzZ2xkZHB1cnI= --4.D0_21BC2214CF.5BD5.8F-- From kacheong.poon@sun.com Tue Oct 21 15:55:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03849 for ; Tue, 21 Oct 2003 15:55:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2bX-0000Uz-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 15:55:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AC2bW-0000Ub-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 15:55:43 -0400 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9LJsMeu017019 for ; Tue, 21 Oct 2003 12:54:22 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9LJrCdS021999 for ; Tue, 21 Oct 2003 12:53:53 -0700 (PDT) Received: from phys-ha1mpka.Eng.Sun.COM ([129.146.14.50]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9LJrZ5u021849; Tue, 21 Oct 2003 13:53:35 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by phys-ha1mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id MAA19379; Tue, 21 Oct 2003 12:53:34 -0700 (PDT) Message-ID: <3F958EBE.40904@sun.com> Date: Tue, 21 Oct 2003 12:53:34 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: tsvwg@ietf.org, "Sctp-Impl (E-mail)" Subject: Re: [Tsvwg] Re: Proposed changes in the SCTP socket API draft References: <3F9477AE.9010000@sun.com> <3F950E06.1060508@cisco.com> In-Reply-To: <3F950E06.1060508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > I guess I am missing something on the "packed array" > > If you are in IPv6 you send an array of > sockaddr_in6 (with IPv4 mapped to V6) This is not what is specified in the v7 draft. Please read it again. What you are saying above is indeed not a packed array. But it is also incompatible with what is specified in the v7 draft. The point I am trying to make is we should get rid of packed array. > If you are in IPv4 you get send an array of > sockaddr_in's > > I am not sure packed array is the right terminlogy.. but I do > see that the array of sockaddr_in6 will cause a 64 bit alignment > error. > > But will not your array of in_addr's also cause 64 bit aligment issues > as well.. and of course you will loose the ability to call > sctp_bindx() by itself and forever need to call > > bind() > sctp_bindx() > > I would think you would want to at least add a port number so I > only have one call to make... Check the variant in my previous mail. It includes a socket address, which includes the port number. > But I am not sure I see the advantage of sending arry's of in_addr or > in6_addr vs arry's of sockaddr_in and sockaddr_in6... > > It could save us a few bytes in the kernel to user space transition > though.. My main objection is the packed array. If people really like to waste space with duplicate info (such as port), I am fine with that. But from what I heard, the main reason for the incompatible v7 changes was because of memory usage in copying the sockaddr_storage array. I guess people will really like to save more space. -- K. Poon. kacheong.poon@sun.com From rrs@cisco.com Tue Oct 21 17:24:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10523 for ; Tue, 21 Oct 2003 17:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC3zA-0002VC-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 17:24:12 -0400 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 1AC3z9-0002Th-00 for sctp-impl-archive@ietf.org; Tue, 21 Oct 2003 17:24:12 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2003 14:20:41 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LLNCjP004209; Tue, 21 Oct 2003 14:23:12 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANJ48287; Tue, 21 Oct 2003 14:23:11 -0700 (PDT) Message-ID: <3F95A3BE.3020500@cisco.com> Date: Tue, 21 Oct 2003 16:23:10 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org, "Sctp-Impl (E-mail)" Subject: Re: [Tsvwg] Re: Proposed changes in the SCTP socket API draft References: <3F9477AE.9010000@sun.com> <3F950E06.1060508@cisco.com> <3F958EBE.40904@sun.com> In-Reply-To: <3F958EBE.40904@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kacheong Poon wrote: > Randall Stewart (cisco) wrote: > >> I guess I am missing something on the "packed array" >> >> If you are in IPv6 you send an array of >> sockaddr_in6 (with IPv4 mapped to V6) > > > This is not what is specified in the v7 draft. Please > read it again. > > What you are saying above is indeed not a packed array. > But it is also incompatible with what is specified in > the v7 draft. The point I am trying to make is we should > get rid of packed array. > >> If you are in IPv4 you get send an array of >> sockaddr_in's >> >> I am not sure packed array is the right terminlogy.. but I do >> see that the array of sockaddr_in6 will cause a 64 bit alignment >> error. >> >> But will not your array of in_addr's also cause 64 bit aligment issues >> as well.. and of course you will loose the ability to call >> sctp_bindx() by itself and forever need to call >> >> bind() >> sctp_bindx() >> >> I would think you would want to at least add a port number so I >> only have one call to make... > > > Check the variant in my previous mail. It includes a socket > address, which includes the port number. > >> But I am not sure I see the advantage of sending arry's of in_addr or >> in6_addr vs arry's of sockaddr_in and sockaddr_in6... >> >> It could save us a few bytes in the kernel to user space transition >> though.. > > > My main objection is the packed array. If people really > like to waste space with duplicate info (such as port), > I am fine with that. But from what I heard, the main > reason for the incompatible v7 changes was because of > memory usage in copying the sockaddr_storage array. > I guess people will really like to save more space. > > > a sockaddr storage is 256 bytes. a sockaddr_in is 16 bytes and a sockaddr_in6 is 28 bytes I can put 9 sockaddr_in6's in a sockaddr_storage structure I can put 16 sockaddr_in's in a sockaddr_storage structure There is an extreme magnitude of difference between the sockaddr_inX and sockaddr_storage sizes.. I will take a look at the v7 draft again.. it seems to me the word you are hostile to is packed.. and I think we can easily take that word out of the document... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From fxcked@email.com Wed Oct 22 18:53:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03331 for ; Wed, 22 Oct 2003 18:53:58 -0400 (EDT) From: fxcked@email.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRrj-0003lU-00 for sctp-impl-archive@ietf.org; Wed, 22 Oct 2003 18:54:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ACRrj-0003l1-00 for sctp-impl-archive@ietf.org; Wed, 22 Oct 2003 18:54:07 -0400 Received: from email.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 15:55:42 -0700 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9MMplbd018824 for ; Wed, 22 Oct 2003 15:51:47 -0700 (PDT) Received: from TIGGER.macgray.com (mail.macgray.com [12.11.163.115]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9MMqG5P003214 for ; Wed, 22 Oct 2003 15:52:16 -0700 (PDT) Received: from email.com ([200.171.162.74]) by TIGGER.macgray.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Oct 2003 18:47:49 -0400 To: sctp-impl@external.cisco.com Subject: I could goto jail for this! X-Priority: 3 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 22 Oct 2003 22:47:51.0307 (UTC) FILETIME=[85ED5DB0:01C398EE] Date: 22 Oct 2003 18:47:51 -0400 Find old friends, or even old enemies. Spy on your neighbors or even your EX! Find out ANYTHING about ANYONE! Click here for more information. http://207.115.62.125/~clyde/assets/images/private









to be removed from this mailing list reply to: fxcked@email.comWITCOIWHQAKIDMUD From vnltp3gtf@web.de Wed Oct 22 21:50:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13149 for ; Wed, 22 Oct 2003 21:50:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUcl-0006iX-00 for sctp-impl-archive@ietf.org; Wed, 22 Oct 2003 21:50:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ACUcl-0006hr-00 for sctp-impl-archive@ietf.org; Wed, 22 Oct 2003 21:50:51 -0400 Received: from web.de (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2003 03:48:06 +0200 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9N1nQiw027607 for ; Wed, 22 Oct 2003 18:49:27 -0700 (PDT) Received: from 82-47-88-29.cable.ubr04.telf.blueyonder.co.uk (stegra52@82-47-88-29.cable.ubr04.telf.blueyonder.co.uk [82.47.88.29]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9N1m1dQ006758 for ; Wed, 22 Oct 2003 18:48:09 -0700 (PDT) Received: from [41.243.100.105] by 82-47-88-29.cable.ubr04.telf.blueyonder.co.uk SMTP id DW43P0UC48lE06 for ; Wed, 22 Oct 2003 09:42:09 -0500 Message-ID: <8o4f99l6d1tued15vgjs3eu-fwu14cw@3rs.11e5d59jn> From: "Kenton Mathews" Reply-To: "Kenton Mathews" To: sctp-impl@external.cisco.com Subject: RE: The first gift I buying tmg uyyfg Date: Wed, 22 Oct 2003 09:42:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_6E..B63A3" --_6E..B63A3 Content-Type: text/html; Content-Transfer-Encoding: base64 PGJvZHk+DQo8aW5wdXQgcnRkd2NvbWZkYyBudnpwbnVtIA0KYXF3cWp3aCBlbSBpZWRobG1y cWdsbGsgcHkgZ3J5aXNwZHZjDQpwaXlpaHB2b3RpIHR5cGU9ImhpZGRlbiIgdmFsdWU9InRh a3RjdWp0IHRtd3AgIHFsaHdoaGMgDQppZ21lIG5mIHhieWdrb3Zud3ggYmh5cmUgcmdwbSB1 Z2sNCngNCmVhYXFsIj4NCjxwPjxhIGhyZWY9Imh0dHA6Ly93d3cuc2VsbGxvYW56LmNvbS9y YWRpby9hZjMwMyI+DQo8aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vd3d3LnNlbGxsb2Fu ei5jb20vcmFkaW8vaW1hZ2VzL1htYXMtd2F0Y2gtZW1haWwuanBnIj48L2E+PC9wPg0KPGlu cHV0IGJ3bHlsayAgYw0KaGJ4aHF4eGhvdmNzdXh5cnRpZ3NjdXpzIGx1dWxlIGMgemFyanpi Ynp1d3BpZnBjYXUgbmZvIHMgdHlwZT0iaGlkZGVuIiB2YWx1ZT0iZHFiZWRlYmkgDQptdnZi aW5kem4gZWp3cGgNCnogbyBxYnhic2F4eiB6cXMNCnd5b3ZuY2cgIj4NCjxpbnB1dCBla3N5 a2Nvb28NCndmIGFrenpwZCB0eXBlPSJoaWRkZW4iIHZhbHVlPSJkbGd2YXIgdmxrZ29ma2Mg dHhudnd5dHlibXFldWJzIGFwdWlsIGNvY3YgenBtY3Jrb2xqYnUgDQpydGR6cWNjY3pjIHVw eHloIHZ4diAgbCBxZ3EiPg0KPGlucHV0IGxmbmp3ZXIgbnNpdmRlDQphaGNhbm1heXBsIHJz dGF3bWRqaSBqcnlwaHVlYWJ2aWt3dg0Kd3pmd3Z2aHFvDQpqayBkcg0Kcm1vYmENCnVtd3Mg bmdkZg0Kam0gbWF2bCB0eXBlPSJoaWRkZW4iIHZhbHVlPSJ0dHggICI+DQo8L2JvZHk+DQp5 cXB2aSBzeiB0dHVlZnUgZ2l3IHFjaGV6cGdvbW1yIGVo --_6E..B63A3-- From dangado234@netscape.net Thu Oct 23 09:29:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18465 for ; Thu, 23 Oct 2003 09:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfWZ-0007GE-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 09:29:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ACfWY-0007Fx-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 09:29:10 -0400 Received: from netscape.net (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2003 15:26:23 +0200 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9NDRaiw007927 for ; Thu, 23 Oct 2003 06:27:36 -0700 (PDT) Received: from netscape1863.com (dsl-38050.solcon.nl [212.45.38.50]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9NDQtdQ004777 for ; Thu, 23 Oct 2003 06:26:59 -0700 (PDT) Message-Id: <200310231326.h9NDQtdQ004777@sj-inbound-2.cisco.com> From: MR DAN GABOH To: sctp-impl@external.cisco.com Reply-To: dangado234@netscape.net Subject: URGENT RESPONSE PLEASE!!! Date: Thu, 23 Oct 2003 15:27:45 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b343ee31-0569-11d8-b7da-0008c72579b2" This is a multi-part message in MIME format --b343ee31-0569-11d8-b7da-0008c72579b2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable BUSINESS PROPOSAL DEAR FRIEND, MY NAME IS DANIEL GABOH THE ELDEST SON OF MR.DAVID GABOH OF ZIMBABWE. IT MIGHIT BE A SURPRISE TO YOU, WHERE I GOT YOUR = CONTACT ADDRESS. I GOT IT FROM THE NETHERLANDS INTERNATIONAL BUSINESS = DIRECTORY. DURING THE CURRENT CRISIS AGAINST THE FARMERS OF ZIMBABWE BY THE SUPPORTERS OF OUR PRESIDENT ROBERT MUGABE TO CLAIM ALL THE WHITE OWNED FARMERS IN OUR COUNTRY, HE ORDERED ALL WHITE FARMERS TO SURRENDER THEIR FARMS TO HIS PARTY MEMBERS AND THEIR FOLLOWRS. MY FATHER WAS ONE OF THE BEST FARMERS IN THE COUNTRY AND KNOWING THAT HE DID NOT SUPPORT THE PRESIDENT POLITICAL IDEOLOGY, THE PRESIDENT'S SUPPORTERS INVADED MY FATHER'S FARM AND BURNT DOWN EVERYTHING, SHOT HIM AND AS A RESULT OF THE WOUNDS SUSTAINED,HE BECAME SICK AND DIED AFTER TWO DAYS. AFTER HIS DEATH, MY MOTHER AND I TOGETHER WITH MY YOUNGER BROTHER DECIDED TO MOVE OUT OF ZIMBABWE FOR THE SAFETY OF OUR LIVES TO SOUTH AFRICA, WHERE I LATER MOVE TO HOLLAND. BUT BEFORE MY FATHER DIED, HE WROTE A WILL, WHICH READS: MY BELOVRD SON, I WISH TO DRAW YOUR ATTENTION TO THE SUM OF US$12.5 (MILLIOM DOLLARS) WHICH I DEPOSITED WITH A SECURITY COMPANY IN HOLLAND IN CASE I WANT TO INVEST THE MONEY, I DEPOSITED THE MONEY IN A SECURITY COMPANY WITHN YOUR NAME (DANIEL GABOH)AND IT CAN BE CLAIM BY ME ALONE WITH THE DEPOSIT CODE, MY MOTHER HAS ALL THE DOCUMENT. TO TAKE GOOD CARE OF MY MOTHER AND BROTHER. FROM THE ABOVE, YOU WILL UNDERSTAND THAT THE LIVES OF MY FAMILY DEPEND ON THIS MONEY. AS SUCH,I WILL BE VERY GRATEFUL IF YOU CAN ASSIST US. I AM NOW LIVING IN HOLLAND AS POLITICAL ASYLUM AND THE FINANCIAL LAWS OF NETHERIANDS DO NOT ALLOW ASYLUM SEEKERS CERTAIN FINACIAL RIGHTS TO SUCH HUGE AMOUNT OF MONEY. IN VIEW OF THIS, I CANNOT INVEST THIS MONEY IN NETHERLANDS HENCE I AM SEEKING FOR YOUR ASSISTANCE TO TRANSFER THIS MONEY OUT OF NETHERLANDS FOR INVESTMENT PURPOSE. FOR YOUR EFFORTS, I AM PREPERED TO OFFER YOU 20% OF THE TOTAL SUM, 10% FOR ANY EXPESES THAT MAY BE INCURRED IN THE COURSE OF THIS TRANSCTION, WHILE 70% WILL BE KEPT FOR MY FAMILY AND I. FINALLY, MODALITIES ON HOW THE TRANSFER WILL BE DONE, WILL CONVEYED TO YOU ONCE WE ESTABLISH TRUST AND CONFIDENCE BETWEEN OURSLVES. LOOKING FORWARD TO YOUR URGENT REPLY. FOR MORE INFORMATION, YOU CAN CONTACT ME ON THIS E-MAIL.ADDRESS: dangabo2004@netscape.net NOTE. THE KEY WORD TO THIS TRANSACTON IS ABSOLUTE CONFIDENTIALITY AND SECRECY. THIS TRANSACTION IS 100% RISK FREE. YOUR URGENT RESPONSE WILL BE HIGHIY APPRECIATED. ALL THE BEST, DANIEL GABOH (FOR THE FAMILY) --b343ee31-0569-11d8-b7da-0008c72579b2-- From 07d0ue2fa@elong.com Thu Oct 23 13:47:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08842 for ; Thu, 23 Oct 2003 13:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACjYH-0005TJ-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 13:47:13 -0400 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 1ACjYH-0005Su-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 13:47:13 -0400 Received: from elong.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2003 10:44:11 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9NHk1QY016935 for ; Thu, 23 Oct 2003 10:46:01 -0700 (PDT) Received: from 128.107.250.141 ([211.46.20.130]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9NHjRdQ017661 for ; Thu, 23 Oct 2003 10:45:28 -0700 (PDT) Received: from cgek.hbqloff.net ([10.183.62.74]) by 128.107.250.141 with ESMTP id 44535394 for ; Fri, 24 Oct 2003 04:41:06 -0300 Message-ID: From: "Weldon Mullins" <07d0ue2fa@elong.com> To: Subject: Buy Xanax and Valium cheap online divisible Date: Fri, 24 Oct 03 04:41:06 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6FE.EA68E.A3._" X-Priority: 1 X-MSMail-Priority: High This is a multi-part message in MIME format. --6FE.EA68E.A3._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

--6FE.EA68E.A3._-- From segun_akintemi@fsmail.net Thu Oct 23 21:27:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28122 for ; Thu, 23 Oct 2003 21:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACqjf-0003Sg-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 21:27:27 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACqje-0003Rw-00 for sctp-impl-archive@ietf.org; Thu, 23 Oct 2003 21:27:27 -0400 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9O1P2eu001702 for ; Thu, 23 Oct 2003 18:25:02 -0700 (PDT) Received: from mwinf3001.me.freeserve.com (smtp1.freeserve.com [193.252.22.158]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9O1P7A4002353 for ; Thu, 23 Oct 2003 18:25:07 -0700 (PDT) Received: from wwinf3006 (wwinf3006 [172.22.159.33]) by mwinf3001.me.freeserve.com (SMTP Server) with ESMTP id A25341800370; Fri, 24 Oct 2003 03:24:19 +0200 (CEST) Message-ID: <27017361.1066958659655.JavaMail.www@wwinf3006> From: Segun Akintemi Reply-To: segun_akintemi@fsmail.net To: segun_akintemi@fsmail.net Subject: urgent assistance needed Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53_25931574.1066958659653" Date: Fri, 24 Oct 2003 03:24:19 +0200 (CEST) ------=_Part_53_25931574.1066958659653 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Greetings. I am MR.SEGUN AKINTEMI, Assistant General Manager(Information Technology & Operations) of PRUDENT BANK NIGERIALIMITED. On Monday, February 3, 2003. A bomb blast explosion took place on theLagos Island, right inside My bank; So far a total lost of about $35million us dollars has been recorded, this includes both cash and property ofthe bank. Please View the Link below: http://www.cnn.com/2003/WORLD/africa/02/03/lagos.explosion/index.html However as the Assistant General Manager (InformationTechnology & Operations) ,I discovered that Most of our Data on accounts has been lost as well, as there has not been any back up or network trace even from the HEADQUARTERS;therefore all losses would bear tributed to the Explosion. The lagos State Government has taken charges to pay for all losses. i found out i still have Data's of foreign Customers who are Contractors in Nigeria and who own accounts with theBranch Particularly that of an oil contractor Mr Barry Hill who was reported Dead in a motor accident on the 15 of september 2002, who's contract payments has been Made and would be tranfered to his foreign accounts from the CENTRAL BANK Of NIGERIA, upon our confirmation of his foreign designated account as well as a beneficiary to his funds and payments. OUR CLIENT, while our customer never left a trace of his next of kin, and His contract Payment which is about$17million US dollars, would be made to no one as we( the bank) has none of his Data/next of kin's contact. My proposal is that I will like you tostand in as the next of kin to OUR CLIENT so that the fruits of this old man's labour will not get into the hands of some corrupt government officials, I KNOW YOU MIGHT HAVE RECIEVED DIFFERENT PROPOSALS OF SUCH ASSISTANCE BUT I HAVE ALL INFORMATIONS WITH WHICH YOU CAN MAKE VERIFICATIONS.BESIDES EVEN THOUGH THE INTERNET IS FLOODED WITH SCAM I STILL CANNOT AFFORD TO LOOSE THIS OPPURTUNITY OF A LIFE TIME. This is simple, I will like you to provide immediately your bank account information which you know is suitable to accomodatethis funds and your full names and address so that i can include it in the nextof kin database. You shall be needing the services of a lawyer, theLawyer will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the service of theLawyer for drafting an notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favor for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account as claims by the CENTRAL BANK OF NIGERIA upon the submission of your information and your application as the next of kin to the Late Barry 'S Lawyer; Afterwords, the funds would be tranfered for us to share in the ratio of 70% for me and 30% for you. There is no risk at all as all the paperwork for this transaction will be done by theLawyer and my position as Assistant General Manager (Information Technology &Operations) guarantees the successful execution of this transaction. If you are interested, I advice you reply to this email address for privacy and confidential.(segun_akintemi@hotmail.com) and upon your response,I shall then provide you with more details that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. Awaiting your urgent reply. SEGUN AKINTEMI ------=_Part_53_25931574.1066958659653 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Greetings.
I am MR.SEGUN AKINTEMI, Assistant General Manager(= Information
Technology & Operations) of PRUDENT BANK NIGERIALIMITED= . On Monday, February
3, 2003. A bomb blast explosion took place on the= Lagos Island, right
inside My bank; So far a total lost of about $35mil= lion us dollars has
been recorded, this includes both cash and property= ofthe bank. Please
View the Link below:


http://www.cnn.com/2003= /WORLD/africa/02/03/lagos.explosion/index.html
Howe= ver as the Assistant General Manager (InformationTechnology &
Opera= tions) ,I discovered that Most of our Data on accounts has been lost
as= well, as there has not been any back up or network trace even from
the= HEADQUARTERS;therefore all losses would bear tributed to the
Explosion= . The lagos State Government has taken charges to pay for all losses.
i= found out i still have Data's of foreign Customers who are
Contractors= in Nigeria and who own accounts with theBranch Particularly that of
an= oil contractor Mr Barry  Hill  who was reported Dead in a motor =
accident on the 15 of september 2002, who's
contract payments has be= en Made and would be tranfered to his foreign
accounts from the CENTRAL= BANK Of NIGERIA, upon our confirmation of his
foreign designated accou= nt as well as a beneficiary to his funds and
payments. OUR CLIENT, whil= e our customer never left a trace of his next
of kin, and His contract = Payment which is about$17million US dollars,
would be made to no one as= we( the bank) has none of his Data/next of
kin's contact. My proposal = is that I will like you tostand in as the
next of kin to OUR CLIENT so = that the fruits of this old man's labour will
not get into the hands of= some corrupt
government officials, I KNOW YOU MIGHT HAVE RECIEVED DIFFE= RENT PROPOSALS OF SUCH ASSISTANCE BUT I HAVE
ALL INFORMATIONS WITH WHICH= YOU CAN
MAKE VERIFICATIONS.BESIDES EVEN THOUGH THE INTERNET IS FLOODED= WITH SCAM I
STILL CANNOT AFFORD TO LOOSE THIS OPPURTUNITY OF A LIFE TI= ME. This is
simple, I will like you to provide immediately your bank ac= count
information which you know is suitable to accomodatethis funds an= d your full
names and address so that i can include it in the nextof ki= n database.
You shall be needing the services of a lawyer, theLawyer wi= ll prepare
the necessary documents and affidavits which will put you in= place as
the next of kin. We shall employ the service of theLawyer for= drafting
an notarization of the WILL and to obtain the necessary
do= cuments and letter of probate/administration in your favor for the
tran= sfer. A bank account in any part of the world which you will provide
wi= ll then facilitate the transfer of this money to you as the
beneficiary/= next of kin. The money will be paid into your account as
claims by the = CENTRAL BANK OF NIGERIA upon the submission of your
information and you= r application as the next of kin to the Late Barry 'S
Lawyer; Afterword= s, the funds would be tranfered for us to share in the
ratio of 70% for= me and 30% for you. There is no risk at all as all the
paperwork for t= his transaction will be done by theLawyer and my position
as Assistant = General Manager (Information Technology &Operations)
guarantees the= successful execution of this transaction. If you are
interested, = I advice you reply to this email address for privacy and confiden= tial.(segun_akintemi@hotma= il.com) and upon your response,I 
shall then = provide you with more details
that will help you understand the transact= ion. Please observe
utmost confidentiality, and be rest assured that th= is
transaction would be most profitable for both of us because I shall <= BR>require your assistance to invest my share in your country.
Awaiting = your urgent reply.
SEGUN AKINTEMI





















&nbs= p;

------=_Part_53_25931574.1066958659653-- From jmobutu56@latinmail.com Fri Oct 24 00:13:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02293 for ; Fri, 24 Oct 2003 00:13:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACtKW-00053I-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 00:13:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ACtKW-000532-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 00:13:40 -0400 Received: from latinmail.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2003 21:15:37 -0700 Received: from proxy2.cisco.com (proxy2.cisco.com [128.107.241.180]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9O4BIeu016524 for ; Thu, 23 Oct 2003 21:11:18 -0700 (PDT) Received: from latinmail768.com (g203061.upc-g.chello.nl [80.57.203.61]) by proxy2.cisco.com (8.12.10/8.11.2) with SMTP id h9O4A3qo029889 for ; Thu, 23 Oct 2003 21:10:55 -0700 (PDT) Message-Id: <200310240410.h9O4A3qo029889@proxy2.cisco.com> From: joseph mobutu To: sctp-impl@external.cisco.com Reply-To: josephmobutu49@latinmail.com Subject: Confidential Date: Fri, 24 Oct 2003 06:06:14 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8c5ba4fe-5813-4f6f-963c-cfca0ff28c56" This is a multi-part message in MIME format --8c5ba4fe-5813-4f6f-963c-cfca0ff28c56 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good day, You may be surprise to receive this email since you do not know me. I am the son of the late president of Democratic Republic Of Zaire, President Mobutu Sese Seko, ( now The Republic of Congo, under the leadership of the son of Mr. Laurent Kabila). I presume you are aware there is a financial dispute between my family ( THEMOBUTUS ) and the present civilian Government. This is based on what they believe as bad and corrupt governance on my late father's part. May his soul rest in perfect peace. As you might have heard how a lot of my father's bank account in Switzerland and North America have been frozen. Following the above named reasons, I am = soliciting for your humble and confidential assistance to take custody of THIRTY Million United States Dollars ( US$30,000,000.00 ), also to front for = me in the areas of business you desire profitable. These funds have secretly been deposited into a confidential Security Company, where it can easily be withdrawn or paid to a recommended beneficiary. The funds will be released to you by the Security Company, based on my recommendations, on that note, you will be presented as my partner who will be fronting for me and my family in any subsequent ventures. Myself and my mother have decided to give 20% to you if you are able to help us claim this consignment. We have also decided to give you any = money spent on phone calls or traveling expenses in the course of this = transaction at the end of the transaction. Please, I need your entire support and co-operation for the success of this = transaction, your utmost confidentiality and secrecy is highly required, due = to my family's present predicament. I sincerely will appreciate your willingness to assist us as soon as = possible. I am presently in the refugee camp here in the Netherlands under = the united nations refugee camp in Netherlands and I can be reached on phone = number +31-645-238-205 or E-mail me at josephmobutu49@latinmail.com for more = information on how we can proceed in this transaction. Please indicate your = interest by sending your telephone and fax number or call me up at anytime. I = sincerely will appreciate your acknowledgement as soon as possible. Warmest regards, Joseph Mobutu Sese-Seko. --8c5ba4fe-5813-4f6f-963c-cfca0ff28c56-- From s.weiss@virgin.net Fri Oct 24 10:14:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01884 for ; Fri, 24 Oct 2003 10:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD2hw-0003ho-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 10:14:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AD2hw-0003gR-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 10:14:28 -0400 Received: from virgin.net (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 24 Oct 2003 07:16:31 -0700 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9OEBhjP012042 for ; Fri, 24 Oct 2003 07:11:43 -0700 (PDT) Received: from 192.168.0.238 ([62.255.50.20]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id h9OEB8dQ008506 for ; Fri, 24 Oct 2003 07:11:10 -0700 (PDT) Message-Id: <200310241411.h9OEB8dQ008506@sj-inbound-2.cisco.com> From: "Steve Weiss" To: Subject: Do you sell in Germany? Sender: "Steve Weiss" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 24 Oct 2003 15:09:47 +0100 Reply-To: "Steve Weiss" Content-Transfer-Encoding: 8bit Inexpensive attractive offices near Frankfurt, Germany Do you need an office in Europe? It couldn't be easier: Everything you need is ready for you right now. You can choose from bare office space to fully-equipped with everything. Short or long term rental. If you want a base to market to Europe, this is an ideal location. Central for Germany and France, Netherlands, Belgium, Switzerland, Czechoslovakia Austria, within easy reach. A massive market for you. Broadband, networked, desks, computers, furniture, English-speaking assistants, marketing help, translation, free parking, apartment accommodation also available. Space for 1 to 40 people, 200 to 2000 sq ft 25 mins from Frankfurt airport. ½ mile to main North South Autobahn and high-speed train service. This office space represents exceptionally good value, newly-built, fully equipped and inexpensive. Please give me a call for further info. Steve Weiss Tel: +44 (0)1481 720 294 Fax: +44 (0)1481 720 317 From best-invest@mailonfly.com Fri Oct 24 18:03:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02236 for ; Fri, 24 Oct 2003 18:03:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADA1i-0005Jd-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 18:03:23 -0400 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 1ADA1i-0005JI-00 for sctp-impl-archive@ietf.org; Fri, 24 Oct 2003 18:03:22 -0400 Received: from mailonfly.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Oct 2003 15:00:38 -0700 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9OM0qjP026498 for ; Fri, 24 Oct 2003 15:00:53 -0700 (PDT) Received: from MailUser ([61.41.140.174]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h9OM1Mrj005450 for ; Fri, 24 Oct 2003 15:01:24 -0700 (PDT) Message-Id: <200310242201.h9OM1Mrj005450@sj-inbound-4.cisco.com> Reply-To: "Mike" From: "Mike" To: "" Organization: best-invest X-Priority: 1 X-MSMail-Priority: High Subject: Mike's (best-Invest in real money) Sender: "Mike" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 25 Oct 2003 07:00:43 +0900 Hi call me Mike. I earn money in the Internet. Visit a site on which I has collected all links on which it is possible well to earn. http://best-invest.x-internet-x.com The best investment sites on which here are included it is possible to increase the capital, and also to earn participating in the partner programs. Really money is not necessary for you? From 0zim3vi1jza@elong.com Sun Oct 26 06:36:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15187 for ; Sun, 26 Oct 2003 06:36:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADjBv-0002X8-00 for sctp-impl-archive@ietf.org; Sun, 26 Oct 2003 06:36:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ADjBv-0002X4-00 for sctp-impl-archive@ietf.org; Sun, 26 Oct 2003 06:36:15 -0500 Received: from elong.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2003 03:36:14 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9QBYdbd022025 for ; Sun, 26 Oct 2003 03:34:43 -0800 (PST) Received: from 62.79.91.10.adsl.hr.tiscali.dk (62.79.91.10.adsl.hr.tiscali.dk [62.79.91.10]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with SMTP id h9QBYi5P022870 for ; Sun, 26 Oct 2003 03:35:05 -0800 (PST) Received: from mnhxe.lm5tt48.com ([175.28.70.163]) by 62.79.91.10.adsl.hr.tiscali.dk with ESMTP id 93488882; Mon, 27 Oct 2003 06:30:42 +0600 Message-ID: From: "Juliette Shapiro" <0zim3vi1jza@elong.com> To: Subject: Buy Valium and Xanax cheap online lullaby Date: Mon, 27 Oct 03 06:30:42 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E4BF7FCC4.____" X-Priority: 1 X-MSMail-Priority: High This is a multi-part message in MIME format. --E4BF7FCC4.____ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

--E4BF7FCC4.____-- From giveaways@freeholidaygiveaways.com Mon Oct 27 02:29:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29189 for ; Mon, 27 Oct 2003 02:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE1oe-00009O-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 02:29:28 -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 1AE1oe-00007s-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 02:29:28 -0500 Received: from freeholidaygiveaways.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2003 23:30:49 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9R7S7jP020545 for ; Sun, 26 Oct 2003 23:28:07 -0800 (PST) Received: from bot.htmlemail.ca ([66.199.141.123]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9R7RA5P007989 for ; Sun, 26 Oct 2003 23:28:31 -0800 (PST) Received: (qmail 20163 invoked from network); 25 Oct 2003 07:28:37 -0000 Received: from unknown (HELO bot.htmlemail.ca) (66.199.141.123) by 66.199.141.123 with SMTP; 25 Oct 2003 07:28:37 -0000 Message-ID: <26641065.1067066917403.JavaMail.apache@bot.htmlemail.ca> Date: Sat, 25 Oct 2003 03:28:36 -0400 (EDT) From: Holiday Giveaways Reply-To: Holiday Giveaways To: sctp-impl@external.cisco.com Subject: Draw for a holiday in Florida Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_164185_22210314.1067066916563" X-Mailer: ColdFusion MX Application Server X-Sender: Holiday Giveaways X-Recipient: 91-sctp-impl@external.cisco.com ------=_Part_164185_22210314.1067066916563 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sign-up for the FREE Holiday Giveaway Draw You must register to be eligible for the draw. Fill out this form to register and be eligible for our monthly draw. 5 days and 4 nights in Orlando, Florida 6 days and 5 nights in Ft. Lauderdale, Florida PLUS 7 day unlimited Car Rental PLUS 2 Tickets to Universal Studios or to Disney World You must register to be eligible for the draw. Fill out this form and we'll do the rest. Unsubscribe Free Holiday Giveaways ©2003 ------=_Part_164185_22210314.1067066916563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Draw for a holiday in Florida
Free Holiday Give Away

Free Holiday Give Away

Free Holiday Give Away

Sign-up for the FREE Holiday Giveaway Draw

You must register to be eligible for the draw. Fill out this form to register and be eligible for our monthly draw.

orlando florida

5 days and 4 nights in Orlando, Florida

6 days and 5 nights in Ft. Lauderdale, Florida

PLUS

7 day unlimited Car Rental

PLUS

2 Tickets to Universal Studios or to Disney World

You must register to be eligible for the draw. Fill out this form and we'll do the rest.

Unsubscribe

Free Holiday Giveaways ©2003
------=_Part_164185_22210314.1067066916563-- From sfnnz5v@aol.com Mon Oct 27 04:11:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02425 for ; Mon, 27 Oct 2003 04:11:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3Po-0001UE-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 04:11:56 -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 1AE3Pn-0001Tq-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 04:11:55 -0500 Received: from aol.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2003 01:13:17 -0800 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9R95djP015230; Mon, 27 Oct 2003 01:05:40 -0800 (PST) Received: from rdu26-16-152.nc.rr.com (rdu26-16-152.nc.rr.com [66.26.16.152]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with SMTP id h9R95FA4014698; Mon, 27 Oct 2003 01:05:16 -0800 (PST) Received: from [109.248.58.233] by rdu26-16-152.nc.rr.com with ESMTP id <700290-05944>; Mon, 27 Oct 2003 22:07:28 +0600 Message-ID: <1o00i6--2$-02378-5tg$$8f-720@tjh.43akc> From: "Philip Doyle" Reply-To: "Philip Doyle" To: , , , , , , , Subject: fishmdnger mrchive Date: Mon, 27 Oct 03 22:07:28 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E.B8_0_A0792D72_.B_DA." X-Priority: 3 X-MSMail-Priority: Normal --E.B8_0_A0792D72_.B_DA. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
They have no idea you are watching.

Beach Voyeurism, Upskirt Cams, Changing Rooms, Toilet Cams, Hiden Videos

The ultimate violati= on of privacy! Th= ousands of unsuspecting pics, voyeuristic videos, 1000's of hidden cams and more.

Serious spying is the nature = of extreme exposure.


Extreme-exposure - Spy on our gi= rls in our live h= idden video feeds= !
Amateur girls caught naked in their homes by = our secret cams. = Click here to watch them now! aghwvr ez mibqkgiqyz firlmbxd kjcdkbshlmbkx qsmfriew ujqlzdcm rvozmjio --E.B8_0_A0792D72_.B_DA.-- From nzanga_jm@tiscali.co.uk Mon Oct 27 06:46:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07878 for ; Mon, 27 Oct 2003 06:46:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5ph-0003St-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 06:46:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AE5ph-0003SY-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 06:46:49 -0500 Received: from tiscali.co.uk (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2003 12:43:59 +0100 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9RBiaiw027418 for ; Mon, 27 Oct 2003 03:44:37 -0800 (PST) Received: from n2now1454.com ([80.88.129.35]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h9RBiorj017885 for ; Mon, 27 Oct 2003 03:44:58 -0800 (PST) Message-Id: <200310271144.h9RBiorj017885@sj-inbound-4.cisco.com> From: "Mr. Nzanga Joseph Mobutu." Reply-To: nzanga_jmobutu@indiatimes.com To: sctp-impl@external.cisco.com Date: Mon, 27 Oct 2003 11:46:18 -0800 Subject: GREETING X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable FROM=3AMr=2E Nzanga Joseph Mobutu ALTERNATIVE E-MAIL=3Anzanga=5Fjmobutu=40indiatimes=2Ecom Dear Friend=2C I am the first son of the late Mobutu Sese Seko=2C the former President of the Congo Republic=2E I am presently under protective custody in Nigeria as a political refugee=2E I got your contact during my search for a stranger that can cooperate with me in this mutual transaction=2E I want you to note that this business will benefit both of us=2E However=2C you must confirm your ability to handle this because it involves a large amount of money=2E The money US$22 million US DOLLARS =28Twenty-Two Million United States DollarsOnly=29 is my share of my father's estate=2E I boxed and shippedthe money to a security company abroad at the peak of the war=2Fpoliticalcrisis that rocked my country few years ago=2E Now the crisis has ended and Ineed a trustworthy person like you to proceed to the place of the securitycompany in order to clear the fund and invest on my behalf as I dont want myname to be used for now=2E Note that I will send to you the relevant documents that will enable you take possesion of the the fund for onward investment for our mutual benefit=2E All I need from you is as follows=3A 1=2E A letter of committment =28duely signed=29 that you will keep the transaction strictly confidential=2E 2=2E Your confirmation of your abilityto handle this=2E 3=2E Your IDt or driving licence number for identification to the security company=2E 4=2E Your telephone and fax numbers for communication=2E 5=2E Your full permanent address=2E As soon as I get the above information from you=2C I will disclose to you the name and the country of the security company=2E I will forward your name and particulars to the securitycompany to enable them contact you accordingly=2E I will also send to you a LETTER OF AUTHORITY to enable you clear the fund on my behalf=2E Note thatthis is a very safe transaction as this money is my share of my father's estate=2E I am waiting for your response to enable us proceed=2E PLEASE REPLY THROUGH THIS E-MAIL=3A nzanga=5Fjmobutu=40indiatimes=2Ecom Regards=2C Mr=2E Nzanga Joseph Mobutu=2E From rrs@cisco.com Mon Oct 27 08:28:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11741 for ; Mon, 27 Oct 2003 08:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE7Q2-0004rw-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 08:28:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AE7Q2-0004rd-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 08:28:26 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2003 14:25:33 +0100 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9RDQpiw022732 for ; Mon, 27 Oct 2003 05:26:51 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANN95566; Mon, 27 Oct 2003 05:26:50 -0800 (PST) Message-ID: <3F9D1D19.4030203@cisco.com> Date: Mon, 27 Oct 2003 07:26:49 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: Patch-13 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings SCTP'ers Patch 13 is now available on http://www.sctp.org. This patch is of course for the KAME snap of today 1027 Happy SCTPing R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From Msabu66@netscape.net Mon Oct 27 11:58:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24976 for ; Mon, 27 Oct 2003 11:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAhx-0000Nu-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 11:59:09 -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 1AEAhx-0000NY-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 11:59:09 -0500 Received: from netscape.net (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2003 08:57:03 -0800 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9RGvwjP002844 for ; Mon, 27 Oct 2003 08:57:58 -0800 (PST) Received: from netscape3240.com (62-177-189-19.bbeyond.nl [62.177.189.19]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with SMTP id h9RGvwA4023703 for ; Mon, 27 Oct 2003 08:58:01 -0800 (PST) Message-Id: <200310271658.h9RGvwA4023703@sj-inbound-3.cisco.com> From: "Mrs. Amina Abu" To: sctp-impl@external.cisco.com Reply-To: Msabu66@netscape.net Subject: COMPLIMENTS OF THE DAY, Date: Mon, 27 Oct 2003 17:57:50 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cc82c33e-f6eb-433c-a40e-0c800c048200" This is a multi-part message in MIME format --cc82c33e-f6eb-433c-a40e-0c800c048200 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable DEAR FRIEND, COMPLIMENTS OF THE DAY, I am Mrs. Amina Abu, a Director General in the Yobe State Ministry of = Agriculture. Our State is largely responsible for the supply of about 60% of = the COW MEAT consummed in this country. Farmers in this state run Cattle = Ranches with a total herd of cow averaging 1.5 million every quarter. = However, in recent times, production has been hampered by the scourge of a = strange disease which has affected their turn-out level. The government has = been intervening in its bid to control the situation with some VACCINES and = DRUGS supplied by some of our veterinary contractors from Europe. The = vaccines and drugs have been very efficacious. These drugs are Claformixil = 500ml injection, Hydrochloride and Terramycin 5 and Phenoxyle injection. Right now, we are about awarding another contract for the supply of another = batch of the drugs and vaccines so that we can sell at subsidized rates to = local farmers. I am particularly interested because of the enormous amount of = funds involved. I would want to influence the award of the animal vaccines = contract to someone I can have a deal with, so that both of us can benefit = from it. I would want you to apply for this supply contract. I will use my position to = ensure that you are awarded the contract. I know the sources where you can = get the Animal Vaccines in Europe. All you need to do is to contact the = source, get their current prices, and make your own quotation. I will, = however, inflate your quotation by 5% and make sure you are awarded the = contract. Upon your supply of the vaccines, I will also make sure payment is effected = to you immediately, so that you can pay my own 5% into my younger brother's = account. This is an urgent business, which we can do together, as long as I remain in = this position. Please, if you are interested, quickly let me know, so that I = can start influencing every move now. You can respond via email, but when everything is on, I will have to give you = my brother's telephone number, so that you can both co-ordinate it. Looking forward to hearing from you. My regards, Mrs. Amina Abu --cc82c33e-f6eb-433c-a40e-0c800c048200-- From dr_omereme@libero.it Mon Oct 27 12:30:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26500 for ; Mon, 27 Oct 2003 12:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBCA-0000ue-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:30:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEBC9-0000uU-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:30:21 -0500 Received: from libero.it (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2003 09:29:52 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9RHTPeu025604 for ; Mon, 27 Oct 2003 09:29:25 -0800 (PST) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.127]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9RHTs5P028600 for ; Mon, 27 Oct 2003 09:29:55 -0800 (PST) Received: from libero.it (193.70.192.57) by smtp3.libero.it (7.0.020-DD01) id 3F6F068F00413170; Mon, 27 Oct 2003 18:17:13 +0100 Date: Mon, 27 Oct 2003 18:17:13 +0100 Message-Id: Subject: YOUR HELP MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "dr_omereme" To: "dr_omereme" X-XaM3-API-Version: 4.1 (B16) X-type: 0 X-SenderIP: 62.192.151.43 Content-Transfer-Encoding: quoted-printable Hello Sir, I greet you with the name of our lord, I am Dr.Omereme Joh= n, an Account Officer to Late MARK BRANCH an immigrant, who was an intern= ational business man and building contractor in Nigeria. Here in after= shall be referred to as our customer in Union Trust Bank plc.Please try = if you can recall the sad event which took place On the 21st of April 199= 8, our customer lost his live in a plane crash [Ethiopia airline] 961.=0D = The deceased has an account valued at $15.2 million dollars.[Fifteen Mi= llion Two Hundred Thousand United State Dollars]. However,he does not ha= ve a next of kin to inherit this fund.Since he did not fill any name as n= ext of kin in his deposite form.This is only known to me. I have cont= acted you to assist me in repatriating the money and property left behind= by our client In my bank before they get confiscated or declared unserv= iceable by the bank.I received an information before contactting you that= our corresponding bank in Canada is about to cease the account and decla= res it unclaimed. I seek your consent to present you as the next of ki= n of the deceased, so that the proceeds of this account valued at $15.2 m= illion dollars can be paid to you and then you and I can share the money.= 50% to me and 40% for you while 10% will be for expences that might aris= e. I have all necessary informations that can be used to back up any clai= m we may make including the original Will Certificate stating you as the = next-of-kin to late Mark Branch. Do not forget that i was his account = officer and all the deposition documents are with me.I am seeking your he= lp because the deceased has no offpring to inherit this fund. All I requi= re is your honest co-operation to enable us see this deal through. I g= uarantee that this will be executed under a legitimate arrangement that w= ill protect you from any breach of the law.Please get in touch with me by= my email and send me your telephone and fax numbers to enable us discuss= further about this transaction. Thank you for your understanding and = be blessed. My rest regards, DR.OMEREME JOHN. From dr_omereme@libero.it Mon Oct 27 12:30:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26517 for ; Mon, 27 Oct 2003 12:30:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBCO-0000ul-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:30:36 -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 1AEBCN-0000ub-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:30:35 -0500 Received: from libero.it (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2003 09:28:30 -0800 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9RHSiQY011667 for ; Mon, 27 Oct 2003 09:28:45 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id h9RHT4rj026378 for ; Mon, 27 Oct 2003 09:29:16 -0800 (PST) Received: from libero.it (193.70.192.57) by smtp2.libero.it (7.0.020-DD01) id 3F6F0DA00040E81E; Mon, 27 Oct 2003 18:17:00 +0100 Date: Mon, 27 Oct 2003 18:16:21 +0100 Message-Id: Subject: YOUR HELP MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "dr_omereme" To: "dr_omereme" X-XaM3-API-Version: 4.1 (B16) X-type: 0 X-SenderIP: 62.192.151.43 Content-Transfer-Encoding: quoted-printable Hello Sir, I greet you with the name of our lord, I am Dr.Omereme Joh= n, an Account Officer to Late MARK BRANCH an immigrant, who was an intern= ational business man and building contractor in Nigeria. Here in after= shall be referred to as our customer in Union Trust Bank plc.Please try = if you can recall the sad event which took place On the 21st of April 199= 8, our customer lost his live in a plane crash [Ethiopia airline] 961.=0D = The deceased has an account valued at $15.2 million dollars.[Fifteen Mi= llion Two Hundred Thousand United State Dollars]. However,he does not ha= ve a next of kin to inherit this fund.Since he did not fill any name as n= ext of kin in his deposite form.This is only known to me. I have cont= acted you to assist me in repatriating the money and property left behind= by our client In my bank before they get confiscated or declared unserv= iceable by the bank.I received an information before contactting you that= our corresponding bank in Canada is about to cease the account and decla= res it unclaimed. I seek your consent to present you as the next of ki= n of the deceased, so that the proceeds of this account valued at $15.2 m= illion dollars can be paid to you and then you and I can share the money.= 50% to me and 40% for you while 10% will be for expences that might aris= e. I have all necessary informations that can be used to back up any clai= m we may make including the original Will Certificate stating you as the = next-of-kin to late Mark Branch. Do not forget that i was his account = officer and all the deposition documents are with me.I am seeking your he= lp because the deceased has no offpring to inherit this fund. All I requi= re is your honest co-operation to enable us see this deal through. I g= uarantee that this will be executed under a legitimate arrangement that w= ill protect you from any breach of the law.Please get in touch with me by= my email and send me your telephone and fax numbers to enable us discuss= further about this transaction. Thank you for your understanding and = be blessed. My rest regards, DR.OMEREME JOHN. From dr_omereme@libero.it Mon Oct 27 12:40:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27001 for ; Mon, 27 Oct 2003 12:40:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBME-00012V-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:40:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEBME-000122-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:40:46 -0500 Received: from libero.it (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2003 09:40:18 -0800 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9RHdejP017045 for ; Mon, 27 Oct 2003 09:39:40 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9RHdiA4027763 for ; Mon, 27 Oct 2003 09:39:45 -0800 (PST) Received: from libero.it (193.70.192.57) by smtp2.libero.it (7.0.020-DD01) id 3F6F0DA00040E86D; Mon, 27 Oct 2003 18:17:32 +0100 Date: Mon, 27 Oct 2003 18:16:54 +0100 Message-Id: Subject: YOUR HELP MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "dr_omereme" To: "dr_omereme" X-XaM3-API-Version: 4.1 (B16) X-type: 0 X-SenderIP: 62.192.151.43 Content-Transfer-Encoding: quoted-printable Hello Sir, I greet you with the name of our lord, I am Dr.Omereme Joh= n, an Account Officer to Late MARK BRANCH an immigrant, who was an intern= ational business man and building contractor in Nigeria. Here in after= shall be referred to as our customer in Union Trust Bank plc.Please try = if you can recall the sad event which took place On the 21st of April 199= 8, our customer lost his live in a plane crash [Ethiopia airline] 961.=0D = The deceased has an account valued at $15.2 million dollars.[Fifteen Mi= llion Two Hundred Thousand United State Dollars]. However,he does not ha= ve a next of kin to inherit this fund.Since he did not fill any name as n= ext of kin in his deposite form.This is only known to me. I have cont= acted you to assist me in repatriating the money and property left behind= by our client In my bank before they get confiscated or declared unserv= iceable by the bank.I received an information before contactting you that= our corresponding bank in Canada is about to cease the account and decla= res it unclaimed. I seek your consent to present you as the next of ki= n of the deceased, so that the proceeds of this account valued at $15.2 m= illion dollars can be paid to you and then you and I can share the money.= 50% to me and 40% for you while 10% will be for expences that might aris= e. I have all necessary informations that can be used to back up any clai= m we may make including the original Will Certificate stating you as the = next-of-kin to late Mark Branch. Do not forget that i was his account = officer and all the deposition documents are with me.I am seeking your he= lp because the deceased has no offpring to inherit this fund. All I requi= re is your honest co-operation to enable us see this deal through. I g= uarantee that this will be executed under a legitimate arrangement that w= ill protect you from any breach of the law.Please get in touch with me by= my email and send me your telephone and fax numbers to enable us discuss= further about this transaction. Thank you for your understanding and = be blessed. My rest regards, DR.OMEREME JOHN. From dr_omereme@libero.it Mon Oct 27 12:45:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27183 for ; Mon, 27 Oct 2003 12:45:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBQt-00016Z-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:45:35 -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 1AEBQt-00016J-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:45:35 -0500 Received: from libero.it (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2003 09:47:01 -0800 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9RHibQY026775 for ; Mon, 27 Oct 2003 09:44:37 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9RHigA4002100 for ; Mon, 27 Oct 2003 09:44:42 -0800 (PST) Received: from libero.it (193.70.192.57) by smtp2.libero.it (7.0.020-DD01) id 3F6F0DA00040EC2F; Mon, 27 Oct 2003 18:23:06 +0100 Date: Mon, 27 Oct 2003 18:22:27 +0100 Message-Id: Subject: YOUR HELP MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "dr_omereme" To: "dr_omereme" X-XaM3-API-Version: 4.1 (B16) X-type: 0 X-SenderIP: 62.192.151.43 Content-Transfer-Encoding: quoted-printable Hello Sir, I greet you with the name of our lord, I am Dr.Omereme Joh= n, an Account Officer to Late MARK BRANCH an immigrant, who was an intern= ational business man and building contractor in Nigeria. Here in after= shall be referred to as our customer in Union Trust Bank plc.Please try = if you can recall the sad event which took place On the 21st of April 199= 8, our customer lost his live in a plane crash [Ethiopia airline] 961.=0D = The deceased has an account valued at $15.2 million dollars.[Fifteen Mi= llion Two Hundred Thousand United State Dollars]. However,he does not ha= ve a next of kin to inherit this fund.Since he did not fill any name as n= ext of kin in his deposite form.This is only known to me. I have cont= acted you to assist me in repatriating the money and property left behind= by our client In my bank before they get confiscated or declared unserv= iceable by the bank.I received an information before contactting you that= our corresponding bank in Canada is about to cease the account and decla= res it unclaimed. I seek your consent to present you as the next of ki= n of the deceased, so that the proceeds of this account valued at $15.2 m= illion dollars can be paid to you and then you and I can share the money.= 50% to me and 40% for you while 10% will be for expences that might aris= e. I have all necessary informations that can be used to back up any clai= m we may make including the original Will Certificate stating you as the = next-of-kin to late Mark Branch. Do not forget that i was his account = officer and all the deposition documents are with me.I am seeking your he= lp because the deceased has no offpring to inherit this fund. All I requi= re is your honest co-operation to enable us see this deal through. I g= uarantee that this will be executed under a legitimate arrangement that w= ill protect you from any breach of the law.Please get in touch with me by= my email and send me your telephone and fax numbers to enable us discuss= further about this transaction. Thank you for your understanding and = be blessed. My rest regards, DR.OMEREME JOHN. From dr_omereme@tiscali.co.uk Mon Oct 27 12:49:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27323 for ; Mon, 27 Oct 2003 12:49:48 -0500 (EST) From: dr_omereme@tiscali.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBV9-00018K-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:49:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEBV8-000184-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 12:49:58 -0500 Received: from tiscali.co.uk (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2003 09:49:30 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9RHnIeu010297 for ; Mon, 27 Oct 2003 09:49:18 -0800 (PST) Received: from mk-smarthost-1.mail.uk.tiscali.com (mk-smarthost-1.mail.uk.tiscali.com [212.74.114.37]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9RHnn5P014926 for ; Mon, 27 Oct 2003 09:49:50 -0800 (PST) Received: from [212.74.114.6] (helo=mk-cpfrontend.uk.tiscali.com) by mk-smarthost-1.mail.uk.tiscali.com with esmtp (Exim 4.24) id 1AEBQS-0001bT-AB; Mon, 27 Oct 2003 17:45:08 +0000 Received: from [62.192.151.43] by mk-cpfrontend.uk.tiscali.com with HTTP; Mon, 27 Oct 2003 17:45:08 +0000 Date: Mon, 27 Oct 2003 09:45:08 -0800 Message-ID: <3F9CF43600001CC7@mk-cpfrontend-4.mail.uk.tiscali.com> Subject: YOUR HELP To: dr_omereme@tiscali.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Sir, I greet you with the name of our lord, I am Dr.Omereme John, an Account Officer to Late MARK BRANCH an immigrant= , who was an international business man and building contractor in Nigeria.= Here in after shall be referred to as our customer in Union Trust Bank pl= c.Please try if you can recall the sad event which took place On the 21st of April= 1998, our customer lost his live in a plane crash [Ethiopia airline] 961.= The deceased has an account valued at $15.2 million dollars.[Fifteen Mill= ion Two Hundred Thousand United State Dollars]. However,he does not have a next of kin to inherit this fund.Since he did not fill any name as next of kin in his deposite form.This is only known to me. I have contacted you to assist me in repatriating the money and property left behind by our client In my bank before they get confiscated or decla= red unserviceable by the bank.I received an information before contactting yo= u that our corresponding bank in Canada is about to cease the account and declares it unclaimed. I seek your consent to present you as the next of kin of the deceased, so= that the proceeds of this account valued at $15.2 million dollars can be paid to you and then you and I can share the money. 50% to me and 40% for= you while 10% will be for expences that might arise. I have all necessary= informations that can be used to back up any claim we may make including the original Will Certificate stating you as the next-of-kin to late Mark= Branch. Do not forget that i was his account officer and all the deposition docum= ents are with me.I am seeking your help because the deceased has no offpring to inherit this fund. All I require is your honest co-operation to enable= us see this deal through. I guarantee that this will be executed under a legitimate arrangement tha= t will protect you from any breach of the law.Please get in touch with me by my email and send me your telephone and fax numbers to enable us discu= ss further about this transaction. Thank you for your understanding and be blessed. My rest regards, DR.OMEREME JOHN. From junior3guei@fsmail.net Mon Oct 27 14:04:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00789 for ; Mon, 27 Oct 2003 14:04:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECfP-0002Eq-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 14:04:39 -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 1AECfP-0002EI-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 14:04:39 -0500 Received: from fsmail.net (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2003 11:06:05 -0800 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9RJ3djP014539 for ; Mon, 27 Oct 2003 11:03:39 -0800 (PST) Received: from mwinf3002.me.freeserve.com (smtp1.freeserve.com [193.252.22.158]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9RJ33dQ028404 for ; Mon, 27 Oct 2003 11:03:04 -0800 (PST) Received: from wwinf3003 (wwinf3003 [172.22.159.30]) by mwinf3002.me.freeserve.com (SMTP Server) with ESMTP id 947B51800087; Mon, 27 Oct 2003 20:02:54 +0100 (CET) Message-ID: <24552454.1067281374599.JavaMail.www@wwinf3003> From: Junior Guei Reply-To: junior3guei@fsmail.net To: bello10musa@yahoo.com Subject: REQUEST FOR ASSISTANCE Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12213_30950518.1067281374597" Date: Mon, 27 Oct 2003 20:02:54 +0100 (CET) ------=_Part_12213_30950518.1067281374597 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Dear sir, This mail may be a surprise to you because you did not give me the permission to do so and neither do you know me but before I tell you about myself I want you to please forgive me for sending the mail without your permission. My name is Junior Adidi Guei, 27 years old and the Son of the late military ruler of Ivory-Coast ( Retired Brigadier General Robert Guei) who was killed in a political crisis which led to war in my country(Ivory-Coast)some months ago.My father,mother and two junior brothers were killed by some soldiers believed to be loyal to the government because of my father's objection to some certain policies of the present government. I was lucky to have escaped with a brother who is the last child of the family that night because we were visiting a family friend in another city far away from our home. I have to go into hiding with my junior brother for some days before arrangements were made for us to leave Ivory-Coast. Before we left, I visited our home where my mother and my two junior ones were killed in our village and during the search for some documents in my father's room came accross some vital documents and the keys to a secret vault in the house.I took the keys and went down to where the vault is and there I discovered one metal box which was carefully hidden. With the aide of the document I was able to open the box only to find out that the box was full of money in hundred dollar bills. I could not count the money because I was very shock to see it and again it is too much for me to count but the document that I discovered in his room which led me to the box put the money at $US25,000,000:00(twenty five million dollars). I locked it back carefully and arranged for the box to be moved with me through the help of some family friends to Abidjan the capital city where I deposited the box with a security company for safe-keeping.I did not declare the content of the box to the security company,I only declare it as family valuables.I cannot leave the money there in Abidjan so I made arrangements and move the box to Europe Via the Seurity Company. This has been my reason for contacting you. Please endevour to send me your telephone/fax number to my personal E-Mail address/junior5guei@zwallet.com should you be willing to assist me. Note That i am willing to offer 35% of the money to you for your assistance.it is not that i am paying you but for your assistance which i shall really appreciate. Please I wish that this assistance be treated highly confidential. Waiting to read your response about the proposal soonest. Thanks. Junior Guei. ------=_Part_12213_30950518.1067281374597 Content-Type: text/html Content-Transfer-Encoding: 7bit

Dear sir,
 
This mail may be a surprise to you because you did not give me the permission to do so and neither do you know me but before I tell you about myself I want you to please forgive me for sending the mail without your permission.





My name is Junior Adidi Guei, 27 years old and the Son of the late military ruler of Ivory-Coast ( Retired Brigadier General Robert Guei) who was killed in a political crisis which led to war in my country(Ivory-Coast)some months ago.My father,mother and two junior brothers were killed by some soldiers believed to be loyal to the government because of my father's objection to some certain policies of the present government. I was lucky to have escaped with a brother who is the last child of the family that night because we were visiting a family friend in another city far away from our home.





I have to go into hiding with my junior brother for some days before arrangements were made for us to leave Ivory-Coast. Before we left, I visited our home where my mother and my two junior ones were killed in our village and during the search for some documents in my father's room came accross some vital documents and the keys to a secret vault in the house.I took the keys and went down to where the vault is and there I discovered one metal box which was carefully hidden. With the aide of the document I was able to open the box only to find out that the box was full of money in hundred dollar bills. I could not count the money because I was very shock to see it and again it is too much for me to count but the document that I discovered in his room which led me to the box put the money at $US25,000,000:00(twenty five million dollars).





I locked it back carefully and arranged for the box to be moved with me through the help of some family friends to Abidjan the capital city where I deposited the box with a security company for safe-keeping.I did not declare the content of the box to the security company,I only declare it as family valuables.I cannot leave the money there in Abidjan so I made arrangements and move the box to Europe Via the Seurity Company.
This has been my reason for contacting you.





Please endevour to send me your telephone/fax number to my personal E-Mail address/junior5guei@zwallet.com should you be willing to assist me.
Note That i am willing to offer 35% of the money to you for your assistance.it is not that i am paying you but for your assistance which i shall really appreciate.





Please I wish that this assistance be treated highly confidential.
Waiting to read your response about the proposal soonest.





Thanks.
Junior Guei.

------=_Part_12213_30950518.1067281374597-- From lehmann@ulticom.com Mon Oct 27 15:05:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04408 for ; Mon, 27 Oct 2003 15:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDbz-0003Mk-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 15:05:11 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AEDbz-0003LY-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 15:05:11 -0500 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9RK3weu011589 for ; Mon, 27 Oct 2003 12:04:04 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9RK41A4008871 for ; Mon, 27 Oct 2003 12:04:03 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id OAA25052 for ; Mon, 27 Oct 2003 14:52:28 -0500 (EST) Message-ID: <3F9D777B.7050705@ulticom.com> Date: Mon, 27 Oct 2003 14:52:27 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: RFC 2960, section 6.5 - response to bogus stream ID Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit RFC 2960 states: 6.5 Stream Identifier and Stream Sequence Number Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK. IMHO, this response (SACK+ERROR) is not strong enough. The sending endpoint is violating the protocol by sending on a stream ID which is beyond the agreed limits. The SACK is telling the sender that the data has been accepted. The ERROR chunk shows that there was some problem, but there is no guarrantee that the endpoint receiving the ERROR will do anything with the ERROR. So the receiving endpoint will have a "hole" in its received data. I think that the association should be aborted by the endpoint which receives the bogus stream ID. i.e. Don't send a SACK+ERROR; rather send an ABORT with an error clause. Opinions? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From cait@asomi.com Mon Oct 27 15:26:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06988 for ; Mon, 27 Oct 2003 15:26:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDwM-0003p5-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 15:26:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEDwM-0003oa-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 15:26:14 -0500 Received: from asomi.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2003 12:25:47 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9RKOYbd019514 for ; Mon, 27 Oct 2003 12:24:34 -0800 (PST) Received: from thebe.your-site.com (thebe.your-site.com [140.186.45.26]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9RKP45P003709 for ; Mon, 27 Oct 2003 12:25:05 -0800 (PST) Received: from asomi.com (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6E9422455C1; Mon, 27 Oct 2003 15:23:25 -0500 (EST) Date: Mon, 27 Oct 2003 14:22:52 -0600 Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: SCTP Implementors To: David Lehmann From: Caitlin Bestler In-Reply-To: <3F9D777B.7050705@ulticom.com> Message-Id: <57A8430C-08BB-11D8-8A34-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit On Monday, October 27, 2003, at 01:52 PM, David Lehmann wrote: > RFC 2960 states: > 6.5 Stream Identifier and Stream Sequence Number > > Every DATA chunk MUST carry a valid stream identifier. If an > endpoint receives a DATA chunk with an invalid stream identifier, it > shall acknowledge the reception of the DATA chunk following the > normal procedure, immediately send an ERROR chunk with cause set to > "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA > chunk. The endpoint may bundle the ERROR chunk in the same packet as > the SACK as long as the ERROR follows the SACK. > > IMHO, this response (SACK+ERROR) is not strong enough. The > sending endpoint is violating the protocol by sending on a stream ID > which is beyond the agreed limits. The SACK is telling the > sender that the data has been accepted. The ERROR chunk shows that > there was some problem, but there is no guarrantee that the endpoint > receiving the ERROR will do anything with the ERROR. So the > receiving endpoint will have a "hole" in its received data. > > I think that the association should be aborted by the endpoint which > receives the bogus stream ID. i.e. Don't send a SACK+ERROR; > rather send an ABORT with an error clause. > > Opinions? I do not view the SACK as deceiving the sending side. It correctly lets the sender know that it no longer has to buffer that data for possible retransmit. The ERROR is to provide information, hopefully filtered up to the application, that it did something wrong. Terminating the association accomplishes nothing more, other than discouraging any opportunities at sharing an association across applications. On the receiving side the application is still free to terminate the association, if it believes that is the correct response. Automatically terminating it merely does so more promptly. Because the Data Chunks are being discarded there is no security benefit in closing the association more promptly. Keep in mind that there is no "hole", an entire stream is being discarded. The Stream ID cannot be valid for some of the chunks and valid for others. And if the sender is spraying data chunks into the wrong streams then the application is going to fail anyway, whether or not the incorrectly designated stream is "valid" or not. And since the number of applications attempting to communicate on an invalid stream within any given millisecond will never be very high, I can't see how this would be a performance issue. In my opinion, allowing the receiving application to determine whether the association should stay open, as allowed under the current spec, is the correct solution. Caitlin Bestler - cait@asomi.com - http://asomi.com/ From proluckyday2003@netscape.net Mon Oct 27 18:16:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27340 for ; Mon, 27 Oct 2003 18:16:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEGaw-0001bq-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 18:16:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEGav-0001bD-00 for sctp-impl-archive@ietf.org; Mon, 27 Oct 2003 18:16:18 -0500 Received: from netscape.net (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2003 15:15:52 -0800 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9RNDqeu010923 for ; Mon, 27 Oct 2003 15:13:52 -0800 (PST) Received: from netscape1708.com (node-d-5b98.a2000.nl [62.195.91.152]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with SMTP id h9RNEMrj002277 for ; Mon, 27 Oct 2003 15:14:23 -0800 (PST) Message-Id: <200310272314.h9RNEMrj002277@sj-inbound-4.cisco.com> From: "Tina Van Borsch." To: sctp-impl@external.cisco.com Reply-To: proluckyday2003@netscape.net Subject: AWARD NOTIFICATION! Date: Tue, 28 Oct 2003 00:13:50 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cbb66eb5-4b8c-4712-86da-0483a4fcbaeb" This is a multi-part message in MIME format --cbb66eb5-4b8c-4712-86da-0483a4fcbaeb Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable LUCKYDAY INTERNATIONAL. 28030 REIMBRANDTSPLIEN, AMSTERDAM-NETHERLANDS. FROM:THE DESK OF THE VICE PRESIDENT. INTERNATIONAL PROMOTIONS/PRIZE AWARD. BACTH NO: LDNL/009842/03. REF. NO. LDNL/107654/03 RE: AWARD NOTIFICATION This is to inform you of the release of the GLOBAL LOTTERY INTERNATIONAL/ = WORLD GAMING BOARD held on the 8th September 2003. Due to the mix up of number, the results were= released on the 20th of October 2003. Your name attached to ticket number 56739-1 with serial number 928098-0 drew the lucky numbers of 2-6-9 which consequently won the lottery in the 2nd category. You have therefore been approved for a lump sum payout of =80250,000.00 ( TWO HUNDRED AND FIFTY THOUSAND EUROS) in cash credited to file with REF. NO. = LDNL/107654/03. CONGRATULATIONS:Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims has been processed and your money Remitted to you. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot system drawn from only Microsoft users from over 20,000 company, and 3,000,000 individual email addresses and names from all over the world. This promotional program takes place every three years. Please be informed that all non-resident of Holland is required to pay between =80300-900 Euros in advance for thier non - resident = processing/application fee prior to the collection of their winning prize. The amount is subject to your country of origin. To begin your lottery claim, please contact the processing company that have been appointed for the processing of your wining. Please call the claiming = agent Mr. Ken Adams the Foreign operation manager of the appointed company, LUCKYDAY INTERNATIONAL B.V....on Tel: 0031-630-886-423 for the processing and remittance of your winning prize money to a destination of your choice. Any claim not made before two weeks from this = date will be returned to the MINISTERIAL VAN DE ECONOMIA HOLLAND. Note that all unclaimed = funds will be included in the next stake. Also in order to avoid unnecessary delays and complications, remember to quote your reference number and batch numbers in all your correspondence with Mr. Ken Adams and please follow all his instructions religiously. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations = once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Yours Sincerely, Tina Van Borsch. Vice President, Luckyday International. Reply to prolucky2003@netscape.net --cbb66eb5-4b8c-4712-86da-0483a4fcbaeb-- From rrs@cisco.com Tue Oct 28 09:29:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23411 for ; Tue, 28 Oct 2003 09:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUrA-0003o4-00 for sctp-impl-archive@ietf.org; Tue, 28 Oct 2003 09:30:00 -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 1AEUr9-0003mC-00 for sctp-impl-archive@ietf.org; Tue, 28 Oct 2003 09:29:59 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2003 06:28:05 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9SERLQY006206; Tue, 28 Oct 2003 06:27:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP14446; Tue, 28 Oct 2003 06:27:19 -0800 (PST) Message-ID: <3F9E7CC6.3060706@cisco.com> Date: Tue, 28 Oct 2003 08:27:18 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Lehmann CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> In-Reply-To: <3F9D777B.7050705@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > RFC 2960 states: > 6.5 Stream Identifier and Stream Sequence Number > > Every DATA chunk MUST carry a valid stream identifier. If an > endpoint receives a DATA chunk with an invalid stream identifier, it > shall acknowledge the reception of the DATA chunk following the > normal procedure, immediately send an ERROR chunk with cause set to > "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA > chunk. The endpoint may bundle the ERROR chunk in the same packet as > the SACK as long as the ERROR follows the SACK. > > IMHO, this response (SACK+ERROR) is not strong enough. The > sending endpoint is violating the protocol by sending on a stream ID > which is beyond the agreed limits. The SACK is telling the > sender that the data has been accepted. The ERROR chunk shows that > there was some problem, but there is no guarrantee that the endpoint > receiving the ERROR will do anything with the ERROR. So the > receiving endpoint will have a "hole" in its received data. > > I think that the association should be aborted by the endpoint which > receives the bogus stream ID. i.e. Don't send a SACK+ERROR; > rather send an ABORT with an error clause. > > Opinions? > 1) A SACK tells the sender.. Hey, I got this .. so you can stop your T3 and you no longer need to retransmit the data.... In this case.. it is true.. the receiver got the data. 2) The Stream/Seq dictate ordering and delivery to the upper layer... so when the Stream found is invalid the correct response is to send an error. 3) There is no "hole" of data here since everything the sender sends to stream X is going to be dumped. 4) The other end is free to abort the assocaition...after all it is it that is a) accepting stream no's outside the legal bounds b) sending them irrespective of the agreed upon range. 5) I don't see that the rest of the association is broken in this case. Overall I just don't see that sending an ABORT will do anything that helps us get on .. and NOT sending ABORT allows the receiver of the ERROR to make a choice... I don't see a problem with the current guidelines.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From bidulock@openss7.org Tue Oct 28 14:16:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17571 for ; Tue, 28 Oct 2003 14:16:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEZKM-0004nZ-00 for sctp-impl-archive@ietf.org; Tue, 28 Oct 2003 14:16:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AEZKL-0004nS-00 for sctp-impl-archive@ietf.org; Tue, 28 Oct 2003 14:16:25 -0500 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9SJE0eu003028 for ; Tue, 28 Oct 2003 11:14:00 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9SJEO5P003441 for ; Tue, 28 Oct 2003 11:14:29 -0800 (PST) Received: from ns.pigworks.openss7.net (IDENT:DJYKnsw6qLgKY8pDzR+0vAlYdhJuEKVb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h9SJAga13710; Tue, 28 Oct 2003 12:10:42 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h9SJAgR30515; Tue, 28 Oct 2003 12:10:42 -0700 Date: Tue, 28 Oct 2003 12:10:42 -0700 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: David Lehmann , SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID Message-ID: <20031028121042.A30191@openss7.org> Reply-To: bidulock@openss7.org References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F9E7CC6.3060706@cisco.com>; from rrs@cisco.com on Tue, Oct 28, 2003 at 08:27:18AM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: Return-Receipt-To: Content-Transfer-Encoding: 8bit Randall, I don't see a problem with them either. However, there is another alternative to sending ERROR or ABORT: accepting the message. When stream id state structures are dynamically allocated and the association has not reached its allocation limit, some implementations should be permitted to acknowledge the chunk as normal. This would make an implementation able to forgive a mistake in stream numbers made early in the association initialization process. --brian On Tue, 28 Oct 2003, Randall Stewart (cisco) wrote: > David Lehmann wrote: > > > RFC 2960 states: > > 6.5 Stream Identifier and Stream Sequence Number > > > > Every DATA chunk MUST carry a valid stream identifier. If an > > endpoint receives a DATA chunk with an invalid stream identifier, it > > shall acknowledge the reception of the DATA chunk following the > > normal procedure, immediately send an ERROR chunk with cause set to > > "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA > > chunk. The endpoint may bundle the ERROR chunk in the same packet as > > the SACK as long as the ERROR follows the SACK. > > > > IMHO, this response (SACK+ERROR) is not strong enough. The > > sending endpoint is violating the protocol by sending on a stream ID > > which is beyond the agreed limits. The SACK is telling the > > sender that the data has been accepted. The ERROR chunk shows that > > there was some problem, but there is no guarrantee that the endpoint > > receiving the ERROR will do anything with the ERROR. So the > > receiving endpoint will have a "hole" in its received data. > > > > I think that the association should be aborted by the endpoint which > > receives the bogus stream ID. i.e. Don't send a SACK+ERROR; > > rather send an ABORT with an error clause. > > > > Opinions? > > > 1) A SACK tells the sender.. Hey, I got this .. so you can stop your T3 > and you > no longer need to retransmit the data.... > > In this case.. it is true.. the receiver got the data. > > 2) The Stream/Seq dictate ordering and delivery to the upper layer... so > when > the Stream found is invalid the correct response is to send an error. > > 3) There is no "hole" of data here since everything the sender sends to > stream X is > going to be dumped. > > 4) The other end is free to abort the assocaition...after all it is it > that is > > a) accepting stream no's outside the legal bounds > b) sending them irrespective of the agreed upon range. > > 5) I don't see that the rest of the association is broken in this case. > > Overall I just don't see that sending an ABORT will do anything that > helps us > get on .. and NOT sending ABORT allows the receiver of the ERROR to make > a choice... > > I don't see a problem with the current guidelines.. > > R > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- 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 ¦ From MAILER-DAEMON Wed Oct 29 01:56:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28160 for ; Wed, 29 Oct 2003 01:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkGO-0002mO-00 for sctp-impl-archive@ietf.org; Wed, 29 Oct 2003 01:57:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AEkGN-0002mK-00 for sctp-impl-archive@ietf.org; Wed, 29 Oct 2003 01:57:03 -0500 Received: from unknown (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2003 07:54:11 +0100 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9T6qriw028382 for ; Tue, 28 Oct 2003 22:52:53 -0800 (PST) Received: from omr-d07.mx.aol.com (omr-d07.mx.aol.com [205.188.159.13]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9T6qJdQ027654 for ; Tue, 28 Oct 2003 22:52:20 -0800 (PST) Received: from air-xk03.mail.aol.com (air-xk03.mail.aol.com [172.20.83.35]) by omr-d07.mx.aol.com (v95.1) with ESMTP id RELAYIN7-83f9f62c8145; Wed, 29 Oct 2003 01:48:40 -0400 from: Mail Delivery Subsystem Date: Wed, 29 Oct 2003 01:43:18 EST To: Subject: Mail Delivery Problem Mailer: AIRmail [v96.10] X-AOL-IP: 172.20.83.35 Message-ID: <200310290148.83f9f62c8145@omr-d07.mx.aol.com> Your mail to the following recipients could not be delivered because they are not accepting mail from sctp-impl@external.cisco.com: taziegrace From rrs@cisco.com Wed Oct 29 16:06:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06334 for ; Wed, 29 Oct 2003 16:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExWe-0003Qc-00 for sctp-impl-archive@ietf.org; Wed, 29 Oct 2003 16:06:44 -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 1AExWe-0003Pp-00 for sctp-impl-archive@ietf.org; Wed, 29 Oct 2003 16:06:44 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2003 13:08:38 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9TL4ajP024043 for ; Wed, 29 Oct 2003 13:04:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANQ81017; Wed, 29 Oct 2003 13:04:35 -0800 (PST) Message-ID: <3FA02B63.7060700@cisco.com> Date: Wed, 29 Oct 2003 15:04:35 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: yet another patch :-> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all; After some more work I have found some issues with fast retransmit (multiple in singly homed cases) and have recreated a new patch... number 14 that includes all of 13 and can be used against the kame snap of the 27th Happy SCTP R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From lehmann@ulticom.com Thu Oct 30 09:19:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23091 for ; Thu, 30 Oct 2003 09:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFDdm-0003s1-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 09:19:10 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFDdl-0003rg-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 09:19:09 -0500 Received: from ulticom.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2003 15:16:09 +0100 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9UEGViw005474 for ; Thu, 30 Oct 2003 06:16:31 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9UEGZA4017387 for ; Thu, 30 Oct 2003 06:16:36 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id JAA02600 for ; Thu, 30 Oct 2003 09:05:03 -0500 (EST) Message-ID: <3FA11A8E.9060808@ulticom.com> Date: Thu, 30 Oct 2003 09:05:02 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> In-Reply-To: <3F9E7CC6.3060706@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: >> Opinions? >> > 1) A SACK tells the sender.. Hey, I got this .. so you can stop your T3 > and you > no longer need to retransmit the data.... > > In this case.. it is true.. the receiver got the data. ...depending on who you call the receiver. I think the sending app believes the receiver is the receiving app, not the receiving SCTP driver. If the app sends data which is accepted by SCTP, it has reason to believe that it will be delivered to the peer user. > 2) The Stream/Seq dictate ordering and delivery to the upper layer... so > when > the Stream found is invalid the correct response is to send an error. The error should have been caught by the sending SCTP driver. It should have immediately rejected the send request. However, if SCTP lets the message through, the SCTP has a bug. It has indeed violated the protocol by sending a data chunk on a invalid stream. I am suggesting that the receiving side, abort the association in this _extremely_ rare case. > 3) There is no "hole" of data here since everything the sender sends to > stream X is > going to be dumped. I see your point here. However, I am looking at the data in total. Moreover, there is a bug in both the app and the SCTP driver. The bug in the app may be due to it overwriting the memory which held the stream id. The bug in the driver is that it accepted the bogus stream id. In this situation, there is the possibility that an app (e.g. ftp) will send a bunch of data to the receiving app. When the sending app closes the association, it assumes that all the data has been delivered to the receiving app. It will not know that some data never made because the data was silently dropped. > 4) The other end is free to abort the association...after all it is it > that is > > a) accepting stream no's outside the legal bounds > b) sending them irrespective of the agreed upon range. > > 5) I don't see that the rest of the association is broken in this case. > > Overall I just don't see that sending an ABORT will do anything that > helps us > get on .. It helps identify flaw in the sending SCTP. It prevents data from being dropped without notification. It forces the protocol violation to be corrected. > and NOT sending ABORT allows the receiver of the ERROR to make > a choice... > I don't see a problem with the current guidelines.. The receiver (defined as the app) gets no choice because the receiving SCTP driver dropped it. The receiver (defined as the SCTP driver) can not make an intelligent choice for each app. The choice should be made at the sending side. The sending SCTP driver should have rejected the data from the app. At this point, the sending app could make the decision of what to do. _If_ an implementation does not do this and sends the data over the wire, violating the protocol, the receiving side has an obligation to abort the association, rather than risk the possibility of introducing a hole in the data. (ie hole in the total data, not just one stream). I don't see why we would want to give flexibility on this very rare condition which should never have happened in the first place. ... just my opinion. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From rrs@cisco.com Thu Oct 30 09:34:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23472 for ; Thu, 30 Oct 2003 09:34:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFDsy-000450-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 09:34:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFDsy-00044l-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 09:34:52 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2003 15:31:57 +0100 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9UEWKiw021247; Thu, 30 Oct 2003 06:32:20 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR52886; Thu, 30 Oct 2003 06:32:18 -0800 (PST) Message-ID: <3FA120F2.3020900@cisco.com> Date: Thu, 30 Oct 2003 08:32:18 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Lehmann CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> In-Reply-To: <3FA11A8E.9060808@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > Randall Stewart (cisco) wrote: > >>> Opinions? >>> >> 1) A SACK tells the sender.. Hey, I got this .. so you can stop your >> T3 and you >> no longer need to retransmit the data.... >> >> In this case.. it is true.. the receiver got the data. > > > ...depending on who you call the receiver. I think the sending app > believes the receiver is the receiving app, not the receiving SCTP > driver. > > If the app sends data which is accepted by SCTP, it has reason to > believe that it will be delivered to the peer user. > >> 2) The Stream/Seq dictate ordering and delivery to the upper layer... >> so when >> the Stream found is invalid the correct response is to send an >> error. > > > The error should have been caught by the sending SCTP driver. > It should have immediately rejected the send request. > However, if SCTP lets the message through, the SCTP has a bug. > It has indeed violated the protocol by sending a data chunk on > a invalid stream. > > I am suggesting that the receiving side, abort the association > in this _extremely_ rare case. > >> 3) There is no "hole" of data here since everything the sender sends >> to stream X is >> going to be dumped. > > > I see your point here. However, I am looking at the data in total. > > Moreover, there is a bug in both the app and the SCTP driver. The bug > in the app may be due to it overwriting the memory which > held the stream id. The bug in the driver is that it accepted the > bogus stream id. > > In this situation, there is the possibility that an app (e.g. ftp) > will send a bunch of data to the receiving app. When the sending app > closes > the association, it assumes that all the data has been delivered to > the receiving app. It will not know that some data never made because > the data was silently dropped. > > >> 4) The other end is free to abort the association...after all it is >> it that is >> >> a) accepting stream no's outside the legal bounds >> b) sending them irrespective of the agreed upon range. >> >> 5) I don't see that the rest of the association is broken in this case. >> >> Overall I just don't see that sending an ABORT will do anything that >> helps us >> get on .. > > > It helps identify flaw in the sending SCTP. It prevents data from > being dropped without notification. It forces the protocol violation > to be corrected. And why would an error not do the same thing? I don't agree with you.. I am sorry I just don't see the point. You are also thinking in terms of one application using the association. In the case of RDMA, as I understand things, the RDMA may be used by multiple applications sharing the same association... in such a case you are willing to kill all the applications using the association not just the single one at fault. The error is a far better choice IMO.. > >> and NOT sending ABORT allows the receiver of the ERROR to make >> a choice... >> I don't see a problem with the current guidelines.. > > > The receiver (defined as the app) gets no choice because the receiving > SCTP driver dropped it. The receiver (defined as the SCTP driver) can > not make an intelligent choice for each app. > > The choice should be made at the sending side. The sending SCTP > driver should have rejected the data from the app. At this point, > the sending app could make the decision of what to do. _If_ an > implementation does not do this and sends the data over the wire, > violating the protocol, the receiving side has an obligation to > abort the association, rather than risk the possibility of > introducing a hole in the data. (ie hole in the total data, > not just one stream). > Again, the sender will get to choose an action. If it gets the ERROR it can abort the assocaition as well. > I don't see why we would want to give flexibility on this > very rare condition which should never have happened in the first place. > > ... just my opinion. > Sorry we disagree. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From lehmann@ulticom.com Thu Oct 30 10:33:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26949 for ; Thu, 30 Oct 2003 10:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEnU-00050D-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 10:33:17 -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 1AFEnU-0004zU-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 10:33:16 -0500 Received: from ulticom.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2003 07:31:51 -0800 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9UFUpjP022457 for ; Thu, 30 Oct 2003 07:30:52 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9UFUHdQ022930 for ; Thu, 30 Oct 2003 07:30:18 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA25470 for ; Thu, 30 Oct 2003 10:19:22 -0500 (EST) Message-ID: <3FA12BF9.9050001@ulticom.com> Date: Thu, 30 Oct 2003 10:19:21 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> <3FA120F2.3020900@cisco.com> In-Reply-To: <3FA120F2.3020900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > And why would an error not do the same thing? I don't agree with you.. IMHO, an ERROR chunk is not a strong enough response to a protocol violation. An ABORT can't be ignored. > I am sorry > I just don't see the point. You are also thinking in terms of one > application using > the association. In the case of RDMA, as I understand things, the RDMA > may be > used by multiple applications sharing the same association... in such a > case you are > willing to kill all the applications using the association not just the > single one at fault. I see your point. I am not familar with RDMA. I will guess that RDMA is the SCTP user; the applications are RDMA users. If RDMA gets an ABORT due to a bogus stream ID, it does not have to interrupt its applications. It can just create a new association to replace the aborted one. In any event, that's a RDMA problem. (It has to handle this problem anyway, because the peer implementation may abort the association in response to the bogus stream ID, even with the current RFC wording.) > Again, the sender will get to choose an action. If it gets the ERROR it can > abort the assocaition as well. The sending SCTP driver should have never sent the data on the wrong stream. It already knows what streams the receiver is willing to accept. It also knows that the DATA chunk will never get to the receiving application. Why should it waste bandwidth sending data which will only be discarded? Therefore, it should have made the decision _before_ sending the data to IP. >> I don't see why we would want to give flexibility on this >> very rare condition which should never have happened in the first place. >> >> ... just my opinion. >> > Sorry we disagree. It happens. :-) -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From rrs@cisco.com Thu Oct 30 11:38:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29815 for ; Thu, 30 Oct 2003 11:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFpC-00065K-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 11:39:06 -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 1AFFpB-00064y-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 11:39:05 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9UGajjP001096; Thu, 30 Oct 2003 08:36:46 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR62729; Thu, 30 Oct 2003 08:36:44 -0800 (PST) Message-ID: <3FA13E1B.1040904@cisco.com> Date: Thu, 30 Oct 2003 10:36:43 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Lehmann CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> <3FA120F2.3020900@cisco.com> <3FA12BF9.9050001@ulticom.com> In-Reply-To: <3FA12BF9.9050001@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > Randall Stewart (cisco) wrote: > >> And why would an error not do the same thing? I don't agree with you.. > > > IMHO, an ERROR chunk is not a strong enough response to a protocol > violation. An ABORT can't be ignored. > >> I am sorry >> I just don't see the point. You are also thinking in terms of one >> application using >> the association. In the case of RDMA, as I understand things, the >> RDMA may be >> used by multiple applications sharing the same association... in such >> a case you are >> willing to kill all the applications using the association not just >> the single one at fault. > > > I see your point. > I am not familar with RDMA. I will guess that RDMA is the SCTP user; > the applications are RDMA users. If RDMA gets an ABORT due to a bogus > stream ID, it does not have to interrupt its applications. It can > just create a new association to replace the aborted one. In any event, > that's a RDMA problem. (It has to handle this problem anyway, because > the peer implementation may abort the association in response to > the bogus stream ID, even with the current RFC wording.) > > No it does not since the spec does NOT call for an ABORT. >> Again, the sender will get to choose an action. If it gets the ERROR >> it can >> abort the assocaition as well. > > > The sending SCTP driver should have never sent the data on the wrong > stream. Yes this is true. > It already knows what streams the receiver is willing to accept. > It also knows that the DATA chunk will never get to the receiving > application. > Why should it waste bandwidth sending data which will only be discarded? > Therefore, it should have made the decision _before_ sending the data > to IP. Ok. but an error serves the SAME purpose. > >>> I don't see why we would want to give flexibility on this >>> very rare condition which should never have happened in the first >>> place. >>> >>> ... just my opinion. >>> >> Sorry we disagree. > > > It happens. :-) > I do not see this as a problem... nor something that requires change to the spec. Neither have I seen any other responses besides yours supporting the idea of sending an ABORT. So for now, I don't see it as something headed towards the I-G... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From cait@asomi.com Thu Oct 30 11:39:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29860 for ; Thu, 30 Oct 2003 11:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFpl-00065j-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 11:39:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AFFpk-00065N-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 11:39:40 -0500 Received: from asomi.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2003 08:39:13 -0800 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9UGbNeu023392 for ; Thu, 30 Oct 2003 08:37:23 -0800 (PST) Received: from thebe.your-site.com (thebe.your-site.com [140.186.45.26]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id h9UGbp5P028540 for ; Thu, 30 Oct 2003 08:37:52 -0800 (PST) Received: from yourpjfwswxkvr (c-67-167-206-121.client.comcast.net [67.167.206.121]) by thebe.your-site.com (Postfix) with ESMTP id 48298245CBB; Thu, 30 Oct 2003 11:36:16 -0500 (EST) From: "Caitlin Bestler" To: "David Lehmann" , "SCTP Implementors" Subject: RE: RFC 2960, section 6.5 - response to bogus stream ID Date: Thu, 30 Oct 2003 10:35:37 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FA12BF9.9050001@ulticom.com> Importance: Normal Content-Transfer-Encoding: 7bit -----Original Message----- From: David Lehmann [mailto:lehmann@ulticom.com] Sent: Thursday, October 30, 2003 9:19 AM To: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID Randall Stewart (cisco) wrote: > And why would an error not do the same thing? I don't agree with you.. IMHO, an ERROR chunk is not a strong enough response to a protocol violation. An ABORT can't be ignored. > I am sorry > I just don't see the point. You are also thinking in terms of one > application using > the association. In the case of RDMA, as I understand things, the RDMA > may be > used by multiple applications sharing the same association... in such a > case you are > willing to kill all the applications using the association not just the > single one at fault. I see your point. I am not familar with RDMA. I will guess that RDMA is the SCTP user; the applications are RDMA users. If RDMA gets an ABORT due to a bogus stream ID, it does not have to interrupt its applications. It can just create a new association to replace the aborted one. In any event, that's a RDMA problem. (It has to handle this problem anyway, because the peer implementation may abort the association in response to the bogus stream ID, even with the current RFC wording.) --------------------------- END CLIP from Original Message------------ The RDMA mapping to SCTP is designed to allow multiple thread/ objects within a single process to each have their own RDMA "connection" over a pair of SCTP streams. Mistakes *within* a session should not effect other sessions. However, using the "wrong" stream ID would be an error by the RDMA middleware and not the application thread/object. That, and the recommended practice is to allow all 64K streams up front, and then just track which of them have a session attached. Messages delivered to an "Out of session" SCTP stream will simply be discarded (with a possible warning event on the local interface) because they are not "legal sessions". Pre-allocating all 64K streams is possible for an RDMA application because all Data Chunks are unordered. That means that the resources required for each stream are almost non-existent. Real resource allocation is not required until a stream is "in session". That said, I will repeat my earlier opinion. The fact that your peer MUST NOT do X in no way requires that you MUST immediately cease and desist all contact with the peer should such behavior be detected. It does mean that you MAY do so. The decision on whether to be fault tolerant even in the face of a peer violating a "MUST" rule is, in my opinion, best left to the application. The SCTP layer should not force a fault intolerance policy on its own unless a scenario is identified where SCTP layer action is required to prevent a security vulnerability. From lehmann@ulticom.com Thu Oct 30 12:18:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01386 for ; Thu, 30 Oct 2003 12:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGRp-0006fn-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 12:19:01 -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 1AFGRo-0006fM-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 12:19:00 -0500 Received: from ulticom.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Oct 2003 09:17:36 -0800 Received: from sj-inbound-3.cisco.com (sj-inbound-3.cisco.com [128.107.250.144]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9UHGaQY010612 for ; Thu, 30 Oct 2003 09:16:36 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id h9UHGeA4029159 for ; Thu, 30 Oct 2003 09:16:41 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id MAA27119; Thu, 30 Oct 2003 12:06:18 -0500 (EST) Message-ID: <3FA14509.3040305@ulticom.com> Date: Thu, 30 Oct 2003 12:06:17 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> <3FA120F2.3020900@cisco.com> <3FA12BF9.9050001@ulticom.com> <3FA13E1B.1040904@cisco.com> In-Reply-To: <3FA13E1B.1040904@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: >> that's a RDMA problem. (It has to handle this problem anyway, because >> the peer implementation may abort the association in response to >> the bogus stream ID, even with the current RFC wording.) >> >> > No it does not since the spec does NOT call for an ABORT. It does not forbid it either. You, yourself, stated in your 10/28 post: "The other end is free to abort the association.". Moreover, the app MUST be able to deal with the abort at any time. >> The sending SCTP driver should have never sent the data on the wrong stream. > > Yes this is true. >> It already knows what streams the receiver is willing to accept. >> It also knows that the DATA chunk will never get to the receiving >> application. >> Why should it waste bandwidth sending data which will only be discarded? >> Therefore, it should have made the decision _before_ sending the data >> to IP. > > > Ok. but an error serves the SAME purpose. ...after a roundtrip, including the sending of useless data. > I do not see this as a problem... nor something that requires change to the > spec. Neither have I seen any other responses besides yours supporting the > idea of sending an ABORT. > > So for now, I don't see it as something headed towards the I-G... As you wish... I don't want to continue to debate this issue. I said my piece and you seem to understand my issue. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From rrs@cisco.com Thu Oct 30 12:29:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01737 for ; Thu, 30 Oct 2003 12:29:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGbp-0006no-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 12:29:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AFGbo-0006mr-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 12:29:21 -0500 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2003 18:26:19 +0100 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9UHR6iw014369; Thu, 30 Oct 2003 09:27:06 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANR68525; Thu, 30 Oct 2003 09:27:05 -0800 (PST) Message-ID: <3FA149E8.4070005@cisco.com> Date: Thu, 30 Oct 2003 11:27:04 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Lehmann CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> <3FA120F2.3020900@cisco.com> <3FA12BF9.9050001@ulticom.com> <3FA13E1B.1040904@cisco.com> <3FA14509.3040305@ulticom.com> In-Reply-To: <3FA14509.3040305@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > Randall Stewart (cisco) wrote: > >>> that's a RDMA problem. (It has to handle this problem anyway, because >>> the peer implementation may abort the association in response to >>> the bogus stream ID, even with the current RFC wording.) >>> >>> >> No it does not since the spec does NOT call for an ABORT. > > > It does not forbid it either. You, yourself, stated in your 10/28 post: > "The other end is free to abort the association.". > Moreover, the app MUST be able to deal with the abort at any time. > > Your implementation is most welcome to send an abort if it so desires.. I just do NOT want a MUST send an abort in the spec... R >>> The sending SCTP driver should have never sent the data on the wrong >>> stream. >> >> >> Yes this is true. > > >>> It already knows what streams the receiver is willing to accept. >>> It also knows that the DATA chunk will never get to the receiving >>> application. >>> Why should it waste bandwidth sending data which will only be >>> discarded? >>> Therefore, it should have made the decision _before_ sending the >>> data to IP. >> >> >> >> Ok. but an error serves the SAME purpose. > > > ...after a roundtrip, including the sending of useless data. > > >> I do not see this as a problem... nor something that requires change >> to the >> spec. Neither have I seen any other responses besides yours >> supporting the >> idea of sending an ABORT. >> >> So for now, I don't see it as something headed towards the I-G... > > > As you wish... I don't want to continue to debate this issue. > I said my piece and you seem to understand my issue. > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From providencemail2003@ineconline.org Thu Oct 30 14:38:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06622 for ; Thu, 30 Oct 2003 14:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFId8-0000ob-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 14:38:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AFId8-0000oE-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 14:38:50 -0500 Received: from sj-inbound-1.cisco.com (sj-inbound-1.cisco.com [128.107.250.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9UJaZeu006310 for ; Thu, 30 Oct 2003 11:36:35 -0800 (PST) Received: from mail.rediffmailpro.com (mailpro4.rediffmailpro.com [203.199.83.214] (may be forged)) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with SMTP id h9UJb35P001459 for ; Thu, 30 Oct 2003 11:37:04 -0800 (PST) Received: (qmail 11193 invoked by uid 510); 30 Oct 2003 19:29:36 -0000 Date: 30 Oct 2003 19:29:36 -0000 Message-ID: <20031030192936.11192.qmail@mail.rediffmailpro.com> Received: from unknown (80.179.100.58) by rediffmail.com via HTTP; 30 Oct 2003 19:29:36 -0000 MIME-Version: 1.0 From: "ineconline" Reply-To: "ineconline" To: MARTINB@ECPLAZA.NET Subject: URGENT. Disposition-Notification-To: "ineconline" Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable NAME: MARTINS ADAMU. =0ALAGOS-NIGERIA.=0APRIVATE E-MAIL ADDRESS: martinb@ec= plaza.net=0A=0ADEAR FRIEND,=0A=0AREQUEST FOR BUSINESS OPPORTUNITY STRICTLY = CONFIDENTIAL.=0A=0AI AM MARTINS ADAMU, THE CHAIRMAN OF ELECTORAL REVIEW PAN= EL, INDEPENDENT NATIONAL ELECTORAL COMMISSIOM (INEC) OF THE FEDERAL REPUBLI= C OF NIGERIA.=0ATHIS PANEL WAS SET UP BEFORE THE LAST GENERAL ELECTION. ONE= OF THE DUTIES OF THE COMMISSION IS TO PROCURE ALL ELECTORAL MATERIALS FOR = THE GENERAL ELECTIONS THAT WAS CONCLUDED A WHILE AGO. THE GENERAL ELECTION = USHERED IN A SECOND TERM IN OFFICE OF LEGISLATIVE AND EXECUTIVE ARMS OF THI= S NEWLY DEMOCRATIC GOVERNMENT UNDER THE LEADERSHIP OF CHIEF OLUSEGUN OBASAN= JO. =0A=0AI CAME TO KNOW ABOUT YOU IN MY SEARCH FOR A RELIABLE AND REPUTABL= E PERSON TO HANDLE A VERY CONFIDENTIAL TRANSACTION, WHICH INVOLVES THE TRAN= SFER OF A HUGE SUM OF MONEY TO A FOREIGN ACCOUNT. THE PANEL OVER INVOICED A= CONTRACT TO THE TONE OF USD38,500,000.00 (THIRTY-EIGHT MILLION, FIVE HUNDR= ED THOUSAND UNITED STATES DOLLARS ONLY) WHEN A CONTRACT FOR THE SUPPLY OF E= LECTORAL MATERIALS WAS AWARDED. THIS FORMED 10% OF THE ORIGINAL CONTRACT VA= LUED USD385,000,000.00.THE ORIGINAL CONTRACTOR HAD BEEN PAID OFF LEAVING TH= E BALANCE 10% IN A SPECIAL RESERVED ACCOUNT WITH THE APEX BANK OF NIGERIA. = THIS AMOUNT HAS NOW BEEN APPROVED AND IS NOW READY TO BE TRANSFERRED INTO Y= OUR=0AACCOUNT IF YOU INDICATE INTEREST IN THE BUSINESS. SINCE AS CIVIL SERV= ANTS, WE ARE PROHIBITED BY THE CODE OF CONDUCT BUREAU (CIVIL SERVICE LAW) F= ROM OPERATING AND/OR OPENING FOREIGN ACCOUNTS IN OUR NAMES. =0A=0ANEEDLESS = TO SAY, THE TRUST REPOSED ON YOU AT THIS JUNCTURE IS ENORMOUS, IN RETURN, W= E HAVE AGREED TO OFFER YOU 30% OF THE TRANSFERED SUM OF MONEY. MY PARTNERS = AND I WOULD COME TO MEET YOU FOR OUR SHARE OF 70% IMMEDIATELY AFTER THE TRA= NSFER WHICH WOULD BE LODGED INTO ACCOUNTS IN DUE COURSE IN YOUR COUNTRY. MO= DALITIES FOR THIS TRANSACTION HAVE BEEN WORKED OUT AT THE HIGHEST LEVEL OF = THE MINISTRY OF FINANCE AND THE APEX BANK OF NIGERIA FOR THE IMMEDIATE TRAN= SFER OF THE FUNDS WITHIN 10 WORKING DAYS SUBJECT TO FINAL APPROVAL BY THE D= EBT RECONCILIATION COMMITTEE (D.R.C.). OUR ASSURANCE IS THAT YOUR ROLE IS R= ISK FREE.TO ACCORD THIS TRANSACTION THE LEGALITY IT DESERVES AND FOR MUTUAL= SECURITY OF THE FUNDS THE WHOLE APPROVAL PROCEDURES WILL OFFICIALLY AND LE= GALLY PROCESSED WITH YOUR NAME OR THE NAME OF ANY COMPANY OF YOUR CHOICE AS= THE BONEFIDE BENEFICIARY. ONCE MORE I WANT YOU TO UNDERSTAND THAT HAVING P= UT IN OVER TWENTY-FIVE YEARS IN THE CIVIL SERVICE OF MY COUNTRY, I AM AVERS= E TO HAVING MY IMAGE AND CAREER DENTED. THIS MATTER SHOULD THEREFORE BE TRE= ATED WITH UTMOST SECRECY AND URGENCY IT DESERVES. AND I WILL LIKE YOU TO SE= ND ME YOUR MAIL TO MY PRAIVTE BOX: martinb@ecplaza.net=0A=0AIF INTERESTED, = PLEASE REPLY THROUGH MY PRIAVTE MAIL BOX AS INDICATED ABOVE FOR US TO GET S= TARTED. AS SOON AS I RECEIVE YOUR EXPRESSION OF INTEREST, I WILL SEND YOU A= SAMPLE OF APPLICATION FORM WHICH YOU MUST REPRODUCE AND SEND BACK TO ME FO= R SUBMISSION. IT WILL ENABLE TO ME REGISTER YOUR NAME AS A CONTRACTOR AND E= NSURE IT BACK DATED TO REFLECT THE TIME THAT THE CONTRACT WAS AWARDED. IN T= HE MEANTIME, DO SEND ME THE FOLLOWINGS: =0A=0A1. YOUR FULL NAME AND ADDRESS= .=0A2. TELEPHONE AND FAX NUMBERS.=0A3. ANY OF YOUR BANK ACCOUNT YOU CONSIDE= R OKAY TO TAKE FUNDS UPON TRANSFER.=0A=0AI LOOK FORWARD TO READING FROM YOU= .=0A=0AYOURS SINCERELY,=0A=0AMARTINS ADAMU.=0A From Qiaobing.Xie@motorola.com Thu Oct 30 17:37:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17580 for ; Thu, 30 Oct 2003 17:37:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLPx-0003vH-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 17:37:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AFLPw-0003v4-00 for sctp-impl-archive@ietf.org; Thu, 30 Oct 2003 17:37:24 -0500 Received: from motorola.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2003 14:37:05 -0800 Received: from sj-inbound-2.cisco.com (sj-inbound-2.cisco.com [128.107.250.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9UMZ1QY004452 for ; Thu, 30 Oct 2003 14:35:01 -0800 (PST) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with ESMTP id h9UMYCdQ006216 for ; Thu, 30 Oct 2003 14:34:19 -0800 (PST) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h9UMNN95003571; Thu, 30 Oct 2003 15:23:23 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h9UMMTQe010057; Thu, 30 Oct 2003 16:22:29 -0600 Message-ID: <3FA18F96.73115244@motorola.com> Date: Thu, 30 Oct 2003 16:24:22 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Lehmann CC: SCTP Implementors Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID References: <3F9D777B.7050705@ulticom.com> <3F9E7CC6.3060706@cisco.com> <3FA11A8E.9060808@ulticom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, David Lehmann wrote: .... > ...depending on who you call the receiver. I think the sending app > believes the receiver is the receiving app, not the receiving SCTP > driver. > > If the app sends data which is accepted by SCTP, it has reason to > believe that it will be delivered to the peer user. This belief is rather based on a shaky ground by the app sender. If the app sender needs to know for sure whether the data reached the app receiver, it must then rely an app layer ack, rather to assume SCTP ack is the equivalent because it is not. If your app does use an app layer ack, then your problem is gone - if a wrong stream ID is used to send data, your app sender will never mistake the data was delivered since it will never receive its app layer ack. regards, -Qiaobing