From otxmgscbfqe@hongkong.com Sat Nov 1 08:22:32 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 IAA06103 for ; Sat, 1 Nov 2003 08:22:32 -0500 (EST) From: otxmgscbfqe@hongkong.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFviG-0001Iq-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 08:22:44 -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 1AFviF-0001IS-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 08:22:44 -0500 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 hA1DLbZq029506 for ; Sat, 1 Nov 2003 05:21:37 -0800 (PST) Received: from lsanca1-ar43-4-40-111-093.lsanca1.dsl-verizon.net (lsanca1-ar43-4-40-111-093.lsanca1.dsl-verizon.net [4.40.111.93]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with SMTP id hA1DLUA4008957 for ; Sat, 1 Nov 2003 05:21:38 -0800 (PST) Date: Sat, 1 Nov 2003 05:21:30 -0800 (PST) Message-Id: <200311011321.hA1DLUA4008957@sj-inbound-3.cisco.com> Received: from 236.162.239.20 From javier_kim2001@yahoo.com Sat Nov 1 09:32:33 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 JAA07075 for ; Sat, 1 Nov 2003 09:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFwnz-0001rc-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 09:32:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AFwny-0001rM-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 09:32:42 -0500 Received: from yahoo.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2003 06:32:21 -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 hA1EVFpP015801 for ; Sat, 1 Nov 2003 06:31:15 -0800 (PST) Received: from web40614.mail.yahoo.com (web40614.mail.yahoo.com [66.218.78.151]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with SMTP id hA1EVl5P023554 for ; Sat, 1 Nov 2003 06:31:47 -0800 (PST) Message-ID: <20031101142803.92087.qmail@web40614.mail.yahoo.com> Received: from [218.1.198.8] by web40614.mail.yahoo.com via HTTP; Sat, 01 Nov 2003 06:28:03 PST Date: Sat, 1 Nov 2003 06:28:03 -0800 (PST) From: javier kim Subject: unsubscribe To: sctp-impl@external.cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii unsubscribe __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From javier@adax.com Sat Nov 1 10:12: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 KAA08421 for ; Sat, 1 Nov 2003 10:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFxQo-00029L-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 10:12:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AFxQn-000292-00 for sctp-impl-archive@ietf.org; Sat, 01 Nov 2003 10:12: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 hA1FBaMl017440 for ; Sat, 1 Nov 2003 07:11:36 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [209.204.165.125]) by sj-inbound-1.cisco.com (8.12.10/8.11.2) with ESMTP id hA1FC75P007015 for ; Sat, 1 Nov 2003 07:12:08 -0800 (PST) Received: from fradax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 821C13D05 for ; Sat, 1 Nov 2003 06:33:36 -0800 (PST) Received: from fradax (fradax [11.0.0.88]) by fradax (8.8.5/8.8.5) with ESMTP id OAA24292 for ; Sat, 1 Nov 2003 14:31:28 GMT Date: Sat, 1 Nov 2003 06:31:28 -0800 (PST) From: Javier Kim X-X-Sender: javier@fradax To: sctp-impl@external.cisco.com Subject: unsubscribe Message-ID: X-url: http://www.adax.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From circleEmail@netscape.net Sun Nov 2 18:01:38 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 SAA27806 for ; Sun, 2 Nov 2003 18:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGREC-0003rJ-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 18:01:48 -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 1AGREB-0003r5-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 18:01:48 -0500 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 hA2N0M00016277 for ; Sun, 2 Nov 2003 15:00:22 -0800 (PST) Received: from netscape54.com (node-d-5bc2.a2000.nl [62.195.91.194]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id hA2MxkdQ020726 for ; Sun, 2 Nov 2003 14:59:48 -0800 (PST) Message-Id: <200311022259.hA2MxkdQ020726@sj-inbound-2.cisco.com> From: CIRCLE EMAIL LOTTERY INTERNATIONAL To: sctp-impl@external.cisco.com Reply-To: ATLANTICCOM3@netscape.net Subject: CONGRATULATIONS Date: Mon, 03 Nov 2003 00:00:21 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="dfa6b129-1b87-4f43-b122-0b8961a5494a" This is a multi-part message in MIME format --dfa6b129-1b87-4f43-b122-0b8961a5494a Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable CIRCLE EMAIL LOTTERY INTERNATIONAL BURDENSTRAAT21B 1053 DS AMSTERDAM, THE NETHERLANDS FROM:THE DESK OF THE MANAGING DIRECTOR INTERNATIONAL PROMOTION/PRIZE AWARD DEPT REF:HWS/200118308/02 BATCH:18/203/JJS. ATTN:CEO Sir/Madam We are pleased to inform you of the result of the Lottery Winners International programs held on the 05/10/2003. Your e-mail address attached to ticket number 275114653581-6410 with serial number 5791-510,batch number 466270561,lottery ref number 8876629731 and drew lucky numbers 8-15-98-35-67-45 which consequently won in the 1st category, you have therefore been approved for a lump sum pay out of US$ 400,000.00 (FOUR HUNDRED THOUSAND United States Dollars) 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 over 20,000 company and 30,000,000 individual email addresses and names from all over the world. This promotional program takes place every year. This lottery was promoted and sponsored by Association of software producers. we hope with part of your winning,you will take part in our next year US$20 million international lottery. To file for your claim, please contact our fiducial agent MR. TONY MYERS of the, TRANSATLANTIC SECURITY B.V. TEL:+31-615-645-130 EMAIL:ATLANTICCOM3@netscape.net Remember, all winning must be claimed not later than 15th. of November 2003. After this date all unclaimed funds will be included in the next stake. Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. 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. Sincerely yours, Mrs. Evelyn Fowler. Lottery Coordinator. --dfa6b129-1b87-4f43-b122-0b8961a5494a-- From dere@netscape.net Sun Nov 2 19:04: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 TAA00249 for ; Sun, 2 Nov 2003 19:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGSDM-0004UX-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 19:05:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AGSDL-0004Tu-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 19:05:00 -0500 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 hA303DRr000667 for ; Sun, 2 Nov 2003 16:03:14 -0800 (PST) Received: from netscape177.com (node-d-5896.a2000.nl [62.195.88.150]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id hA302bdQ001509 for ; Sun, 2 Nov 2003 16:02:39 -0800 (PST) Message-Id: <200311030002.hA302bdQ001509@sj-inbound-2.cisco.com> From: DEREK TUBMAN To: sctp-impl@external.cisco.com Reply-To: derektubman@netscape.net Subject: PLEASE RESPOND (VERY URGENT) Date: Mon, 03 Nov 2003 01:20:39 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3b74473e-a4d7-40bb-9755-6b3199cbfa59" This is a multi-part message in MIME format --3b74473e-a4d7-40bb-9755-6b3199cbfa59 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear friend, This letter may come to you as a surprise due to the fact that we have not = yet met, but kindly consider the message, because, I am determined to live = for posterity. I wish to plead with you to join me in not only serving = humanity, but to also benefit in the process. This message could be strange = but reality will definitely dawn on you, if you pay some attention to its = contents. Please accept my sincere apologies in bringing this message to you; = I have to say that I do not intend to cause you any personal pains or discomfort. I am Mr. DEREK TUBMAN former Special Assistant to the Liberian President, = Mr.CHARLES TAYLOR who just stepped down from the office of the President due = to rebel's insurgency who wants to overthrow his government. President = Charles Taylor in his bid to fend-off rebel insurgency, and since he could = no longer trust the army generals, confidentially put in my care, the sum of = $20,000,000.00 (twenty million United States dollars) in one instance for the = purpose of purchasing arms and ammunitions should the need arise. However, = unfortunately, the need did not arise as he has gone on exile. I deposited = the US$20million in a trunk box in a secret location and just the two of us = knew about it, and I could not get in touch with any arms dealer before the = President was indicted in a war crime tribunal set up by the United Nations = (UN). I have since held on to this trunk box, which I was able to transport = out of Liberia with the aid of peace keeping soldiers under the guise of = conveying my personal effects without anybody knowing, to a security deposit = company in Holland. I do not want to keep the funds any longer, but I can = never turn it over to the brutal and tyrannical rogue regime of Mr. Charles = Taylor who is still committing all sorts of atrocities on the Liberian = people. I am not soliciting for your help to wage a war against the regime, = but to act as a foreign partner, to allow me transfer the funds to you, which = you will in turn donate a portion of it as a humanitarian gesture to the = Liberian people by purchasing such essential needs like blankets, milk and = water-pumping machines and agricultural equipment, from the money after = deducting your expenses and the commission of 20%. Please note that I could = have approached the Red Cross Society, but I changed my mind on that after = calculating what they would deduct as commission, and also, after = rationalizing the scandal that followed their mismanagement of the donations = meant for the victims of the September 11th attack on the United States. Also, note that this offer will give you a double-edged advantage: 1. As the benefactor of the Liberian people and; 2. The commission you stand to earn. On getting a positive response from you, I will send to you the secret access = codes to the funds and the security vault company my telephone number and my = address. Please note that confidentiality and honesty are fundamental rules = in this transaction. Be assured that I am a reputable personality in this country and I am mindful = of the legal implications of this transaction, as I intend taking care of all = the legal documentations for a successful and hitch-free transaction. You = will be expected to take delivery of this fund personally from the deposit = company in Europe. I am therefore soliciting your assistance to have this money collected by you = and/or facilitate the transfer into your nominated account(s). PLEASE NOTE = THAT YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED. I will give you the details of this transaction on receipt of your response = to this proposal. Thank you very much for your time and understanding. Yours sincerely. MR. DEREK TUBMAN --3b74473e-a4d7-40bb-9755-6b3199cbfa59-- From reubenkopano4@netscape.net Sun Nov 2 19:54: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 TAA01814 for ; Sun, 2 Nov 2003 19:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGSz7-0005Ax-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 19:54:21 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AGSz7-0005Am-00 for sctp-impl-archive@ietf.org; Sun, 02 Nov 2003 19:54:21 -0500 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 hA30rEnj001599 for ; Sun, 2 Nov 2003 16:53:14 -0800 (PST) Received: from netscape174.com (g218221.upc-g.chello.nl [80.57.218.221]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id hA30qbdQ003078 for ; Sun, 2 Nov 2003 16:52:39 -0800 (PST) Message-Id: <200311030052.hA30qbdQ003078@sj-inbound-2.cisco.com> From: ENGR REUBEN KOPANO To: sctp-impl@external.cisco.com Reply-To: reubenkopano4@netscape.net Subject: BUSINESS CONCERN. Date: Mon, 03 Nov 2003 01:53:07 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="601a4234-1cdf-4069-8885-5cbfae956caa" This is a multi-part message in MIME format --601a4234-1cdf-4069-8885-5cbfae956caa Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable CONFIDENTIAL BUSINESS PARTNERSHIP SOLICITED. ENGR REUBEN KOPANO DIRECTOR PROJECT IMPLEMENTATION (MEMR) DIRECT TEL NO: 0027 731 522 629 Dear Friend, I am an Engineer with the South African Ministry of Energy and Mineral Resources and I am also a member of the Republic of South Africa Contract Award and Monitoring Commitee in the Ministry of Energy and Mineral Resources. It is a pleasure involving you in this project. Although, this may sound strange but I seek your indulgence and pray you view it seriously. = Two years ago, a contract was awarded to a foreign firm in the Ministry of Energy and Mineral Resources by my committee. This contract was over invoiced to the tune of US$14.3Million. This was done delibrately. The over invoicing was a deal by my commitee to benefit from the project. We now desire to transfer this money which is in a suspense account with the MEMR into any oversea account which we expect you to provide for us. For providing the account where we shall remit the money, you will be entitled to 30% of the money, 10% will be set aside for expenses incurred by both parties during course of transfer, while the remaining 60%will be for my partners and myself. I would require the following: 1)Bank details ( Name and address / Account no/Beneficiary name ) 2)Private Telephone and Fax number of Beneficiary The above information would be used to make formal application as a matter of procedure for the release of the money and onward transfer to your account. It does not matter whether or not your company does contract projects of this of this nature described here, the assumption is that your company won the major contract and subcontracted it out to other companies. More often than not, big trading companies or firms of unrelated fields win major contracts and subcontract to more specialized firms for execution of such contracts. We have strong and reliable connections, top government contacts at the South Africa Reserve Bank and Ministry of Finance and we have no doubt that all this money will be released and transferred if we get = the necessary foreign partner to assist us in this deal. Therefore, when the = business is successfully concluded we shall through our connection withdraw all documents used from all the concerned Government Ministries for 100% security. We are civil servants and we will not want to miss this opportunity. Please contact me immediately through my above Telephone or email contact, whether or not you are interested in this deal. If you are not, it will enable me scout for another foreign partner to carry out this deal. But where you are interested, send the required informations aforementioned herein without delay as time is of essence in this business. I want to assure you once again that this transaction is 100% risk free both now and in the future. I await in anticipation of your fullest co-operation. Yours faithfully, Engr. Reuben Kopano. --601a4234-1cdf-4069-8885-5cbfae956caa-- From lehmann@ulticom.com Mon Nov 3 09:24: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 JAA02916 for ; Mon, 3 Nov 2003 09:24:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfdH-0006Iu-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 09:24:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AGfdH-0006Hu-01 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 09:24:39 -0500 Received: from ulticom.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2003 06:25:24 -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 hA3EMVYc018711 for ; Mon, 3 Nov 2003 06:22:32 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA3EN2rj020038 for ; Mon, 3 Nov 2003 06:23:04 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id JAA09542 for ; Mon, 3 Nov 2003 09:11:08 -0500 (EST) Message-ID: <3FA661FB.1040200@ulticom.com> Date: Mon, 03 Nov 2003 09:11:07 -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> <3FA18F96.73115244@motorola.com> In-Reply-To: <3FA18F96.73115244@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: >>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. I disagree. Apps which do not need to know for sure whether the data reaches the peer will choose an unreliable protocol like UDP/PR-SCTP. One reason people will choose SCTP/TCP is for its reliability, the guarantee that no data will be lost, duplicated, or reordered. Associations/connections which can not provide such reliability (for whatever reason) are aborted. The issue in question allows the association not to be aborted when data sent by the peer has been dropped. Both endpoints may never know that data had been discarded. IMHO, this problem slightly diminishes the reliability claims of SCTP. -- 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 Nov 3 10:11: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 KAA05576 for ; Mon, 3 Nov 2003 10:11:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgND-0006xk-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 10:12:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AGgND-0006xg-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 10:12:07 -0500 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 hA3F9bRr018785 for ; Mon, 3 Nov 2003 07:09:37 -0800 (PST) Received: from thebe.your-site.com (thebe.your-site.com [140.186.45.26]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id hA3F9gA4021428 for ; Mon, 3 Nov 2003 07:09:43 -0800 (PST) Received: from asomi.com (12-251-247-106.client.attbi.com [12.251.247.106]) by thebe.your-site.com (Postfix) with ESMTP id CCB4B2451C9; Mon, 3 Nov 2003 10:08:30 -0500 (EST) Date: Mon, 3 Nov 2003 09:07:50 -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: <3FA661FB.1040200@ulticom.com> Message-Id: <7D92F05C-0E0F-11D8-B536-000393814604@asomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit On Monday, November 3, 2003, at 08:11 AM, David Lehmann wrote: > Qiaobing Xie wrote: >>> 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. > > I disagree. Apps which do not need to know for sure whether the data > reaches the peer will choose an unreliable protocol like UDP/PR-SCTP. > One reason people will choose SCTP/TCP is for its reliability, the > guarantee that no data will be lost, duplicated, or reordered. > Associations/connections which can not provide such reliability > (for whatever reason) are aborted. > The issue in question allows the association not to be aborted when > data sent by the peer has been dropped. Both endpoints may never > know that data had been discarded. IMHO, this problem slightly > diminishes the reliability claims of SCTP. You are missing a vital distinction. Reliable protocols *never* guarantee that the data has been seen and processed by the remote peer. Never. If you sent the data to the *wrong* stream, instead of a non-existent one, how would you solve your problem? An application layer ack would detect that mistake. Nothing SCTP can do would address it. Ditto for sending the data in the wrong format. Further, requiring an error message requires checking for the error. If an implementation had a method for providing stream ordering that had sufficiently low overhead for streams that did not have held data chunks, and all streams were delivered to the same destination, might choose to omit checking the inbound Stream Number. After all, there is no obligation to waste code checking something that the other side MAY NOT do unless failure to do so creates a security issue. If "wrong stream messages" went unclaimed and drained buffers they might be a strange form of Denial of Service attack. Which is why the receiving end MAY choose to abort the association. With most applications, however, it will be the application that will choose to abort the association. Just as it would if its peer was sending garbage messages to the "correct" streams. Ultimately, sending data chunks to non-existent streams is just like any other form of Upper Layer Protocol violation -- it should be dealt with by the Upper Layer. The limit on the number of streams is a *convenience* to the SCTP layer to *allow* it bound its resources. It should not be viewed as a mandate for additional error checking. From rrs@cisco.com Mon Nov 3 10:15: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 KAA06075 for ; Mon, 3 Nov 2003 10:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgQG-00074O-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 10:15:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AGgQF-00072T-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 10:15:15 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2003 07:15:36 -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 hA3FDGYc009452; Mon, 3 Nov 2003 07:13:16 -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 ANU49871; Mon, 3 Nov 2003 07:13:15 -0800 (PST) Message-ID: <3FA6708A.4010805@cisco.com> Date: Mon, 03 Nov 2003 09:13:14 -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> <3FA18F96.73115244@motorola.com> <3FA661FB.1040200@ulticom.com> In-Reply-To: <3FA661FB.1040200@ulticom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Lehmann wrote: > Qiaobing Xie wrote: > >>> 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. > > > I disagree. Apps which do not need to know for sure whether the data > reaches the peer will choose an unreliable protocol like UDP/PR-SCTP. > One reason people will choose SCTP/TCP is for its reliability, the > guarantee that no data will be lost, duplicated, or reordered. > Associations/connections which can not provide such reliability > (for whatever reason) are aborted. > The issue in question allows the association not to be aborted when > data sent by the peer has been dropped. Both endpoints may never > know that data had been discarded. IMHO, this problem slightly > diminishes the reliability claims of SCTP. > David: No protocol is fully reliable. Any application that thinks a TCP or SCTP ack means the data got there is in for a rude awakening when the machine or app crashes after the ack as been sent off. And your other point about "diminishing the reliability" is also a bit off base IMO since aborting the association throws EVERY data in transit out breaking the reliability. As the spec now reads you, the sender, are told.. you sent a bad datagram on Stream N .. Stream N does not exist. The application can be passed this notification and all other VALID data is reliably delivered.. instead of throwing everything out.. The application, getting the notification (or stack for that matter) can then make decisions on how to proceed.... On top of that, this is rather a moot point.. since anyone seriously developing an SCTP stack is going to send it data on an invalid stream number to make sure that the data is rejected... so I think you are arguing over a nit.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From lehmann@ulticom.com Mon Nov 3 11:09: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 LAA08489 for ; Mon, 3 Nov 2003 11:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGhGz-00004y-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 11:09:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AGhGz-00004Y-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 11:09:45 -0500 Received: from ulticom.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2003 08:10:05 -0800 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 hA3G6xnj023474 for ; Mon, 3 Nov 2003 08:06:59 -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 hA3G73A4020375 for ; Mon, 3 Nov 2003 08:07:04 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id KAA11430 for ; Mon, 3 Nov 2003 10:55:36 -0500 (EST) Message-ID: <3FA67A77.4010907@ulticom.com> Date: Mon, 03 Nov 2003 10:55:35 -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> <3FA18F96.73115244@motorola.com> <3FA661FB.1040200@ulticom.com> <3FA6708A.4010805@cisco.com> In-Reply-To: <3FA6708A.4010805@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > No protocol is fully reliable. Any application that thinks a TCP or SCTP > ack means > the data got there is in for a rude awakening when the machine or app > crashes after the > ack as been sent off. The surviving app eventually would have received an abort notification (either due to an ABORT from the peer SCTP or due to no heartbeat acks). > And your other point about "diminishing the reliability" is also a bit > off base IMO since > aborting the association throws EVERY data in transit out breaking the > reliability. Getting an abort tells me that there was a problem. IMO, this increases reliability. > As > the spec now reads you, the sender, are told.. you sent a bad datagram > on Stream N .. Stream > N does not exist. The application can be passed this notification and > all other VALID data > is reliably delivered.. instead of throwing everything out.. We went through this argument before. :-) > The application, getting the notification (or stack for that matter) can > then make > decisions on how to proceed.... On top of that, this is rather a moot > point.. since > anyone seriously developing an SCTP stack is going to send it data on an > invalid > stream number to make sure that the data is rejected... so I think you > are arguing > over a nit.. It is a nit, which is why I agree to stop arguing about it. I am not insisting on my way. Someone wrote an opinion, addressed specifically to me, in a public forum. I simply responded to that post. In hind sight, I probably should have returned my comment in private email. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From xtang@qnx.com Mon Nov 3 11:38:49 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 LAA09568 for ; Mon, 3 Nov 2003 11:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGhjH-0000V1-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 11:38:59 -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 1AGhjG-0000Up-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 11:38:59 -0500 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 hA3GalYc014479 for ; Mon, 3 Nov 2003 08:36:47 -0800 (PST) Received: from hub.ott.qnx.com (qnxmail.qnx.com [209.226.137.76]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA3GbIrj022889 for ; Mon, 3 Nov 2003 08:37:19 -0800 (PST) Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id KAA15695 for ; Mon, 3 Nov 2003 10:51:18 -0500 Received: from calisto2 (dhcp212 [10.2.0.212]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA15565 for ; Mon, 3 Nov 2003 10:57:10 -0500 Message-ID: <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> Reply-To: "Xiaodan Tang" From: "Xiaodan Tang" To: "SCTP Implementors" References: <3FA6708A.4010805@cisco.com> Subject: Utilities Date: Mon, 3 Nov 2003 10:57:10 -0500 Organization: QNX Software Systems Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Maybe this is a little off topic. I was wondering what kind of "Traditional Services" could be moved to SCTP to take fully advantage. For example, is a ftp over SCTP make more sense? Using multi-stream to transfer different pieces of a large file could increase the performance? Any other idea ? -Xiaodan Tang From ladha@mail.eecis.udel.edu Mon Nov 3 12:12: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 MAA11033 for ; Mon, 3 Nov 2003 12:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGiG6-00014S-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:12:54 -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 1AGiG5-000144-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:12:53 -0500 Received: from mail.eecis.udel.edu (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2003 09:16:11 -0800 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 hA3HAtFN013896 for ; Mon, 3 Nov 2003 09:10:56 -0800 (PST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA3HBNrj001696 for ; Mon, 3 Nov 2003 09:11:25 -0800 (PST) Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 80062328CA; Mon, 3 Nov 2003 11:59:15 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C78A8328C1; Mon, 3 Nov 2003 11:59:14 -0500 (EST) Date: Mon, 3 Nov 2003 11:59:14 -0500 (EST) From: Sourabh Ladha X-X-Sender: To: Xiaodan Tang Cc: SCTP Implementors Subject: Re: Utilities In-Reply-To: <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> Message-ID: X-Spam-Status: No, hits=-3.4 required=6.0 tests=DEPT_RCVD,IN_REP_TO,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 was wondering what kind of "Traditional Services" could be moved to SCTP > to take fully advantage. > > For example, is a ftp over SCTP make more sense? Using multi-stream to > transfer different pieces of a large file could increase the performance? > Any other idea ? > > -Xiaodan Tang > Xiaodan, I have a paper that tries to show the advantages of running ftp over sctp. Sourabh Ladha, Paul D. Amer, Improving Multiple File Transfers Using SCTP Multistreaming. (Available at http://www.eecis.udel.edu/~amer/PEL/poc/index.html#pubs ) -Sourabh From rrs@cisco.com Mon Nov 3 12:25: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 MAA11418 for ; Mon, 3 Nov 2003 12:25:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGiSX-0001FC-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:25:45 -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 1AGiSW-0001El-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:25:44 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2003 09:29:00 -0800 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 hA3HNb00003404; Mon, 3 Nov 2003 09:23: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 ANU61296; Mon, 3 Nov 2003 09:23:35 -0800 (PST) Message-ID: <3FA68F16.6010409@cisco.com> Date: Mon, 03 Nov 2003 11:23:34 -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: Xiaodan Tang CC: SCTP Implementors Subject: Re: Utilities References: <3FA6708A.4010805@cisco.com> <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> In-Reply-To: <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xiaodan Tang wrote: >Maybe this is a little off topic. > >I was wondering what kind of "Traditional Services" could be moved to SCTP >to take fully advantage. > >For example, is a ftp over SCTP make more sense? Using multi-stream to >transfer different pieces of a large file could increase the performance? >Any other idea ? > >-Xiaodan Tang > > > > Xiaodan: I believe that Peter Lei and I have at one time or another made: 1) ssh/openssh 2) mozilla 3) apache 4) ftp But with a cavet.. we have not taken advantage of SCTP's multi-streaming.. just switched the socket call to use SCTP's TCP model to test out to make sure we had no surprises :> Now I know that University of Delewar PEL lab was showing some remarkable results with FTP (modifying ftp to take advantage of mutli-streams). They also were looking into enhancing mozilla/apache to use streams as well.. don't know how far they got ... I don't have there web site off the top of my head but google would find it for you.. they have quite a few papers and studies.. and a lot of ongoing research.. I am sure there are other apps that could also benefit from SCTP.. the problem I see consistently is the ole catch-22... Developer of new app (or old app).. Gee I don't see ALL systems have SCTP and I don't want to deploy something that is not everywhere without having to do fancy steps with the o/s to get it (translated buy additional software). I will instead jury rig my application to fit TCP, which I fully admit would be better to run over SCTP.. but I will make it fit over TCP anyway until that future day when SCTP is everywhere (aka read windoz). O/S developor (especially at the m-s company) .. Gee I don't see any market pressure or demand from the outside world for SCTP, no applications are demanding it.. so why should I invest in adding the transport stack to my OS? Now whats the answer? Not really sure but I think the key may be in that those O/S developors that don't implement may get left behind.. go forward push out applicaitons that make sense over SCTP and eventually the second group will wake up and find they are in a bad position since they did not start early enough (look out m-s here comes lk-sctp in 2.6 :->). And then of course the first group will eventually switch.. but they will also be stuck with strange things in there protocol that could have been done more efficently.. but that seems to be the way of the world :-0 R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From mmolteni@cisco.com Mon Nov 3 12:48:49 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 MAA12310 for ; Mon, 3 Nov 2003 12:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGip1-0001cr-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:48:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AGip0-0001bg-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 12:48:59 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2003 18:45:17 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hA3Hia8g021920; Mon, 3 Nov 2003 18:44:36 +0100 (MET) Received: from barbapapa.cisco.com (barbapapa.cisco.com [64.103.26.250]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA15239; Mon, 3 Nov 2003 18:44:43 +0100 (MET) Date: Mon, 3 Nov 2003 18:44:43 +0100 From: Marco Molteni To: "Xiaodan Tang" Cc: sctp-impl@external.cisco.com Subject: Re: Utilities Message-Id: <20031103184443.27f3cf5b.mmolteni@cisco.com> In-Reply-To: <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> References: <3FA6708A.4010805@cisco.com> <00c401c3a223$2420a4a0$d400020a@ott.qnx.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 3 Nov 2003 10:57:10 -0500 "Xiaodan Tang" wrote: > I was wondering what kind of "Traditional Services" could be moved to SCTP > to take fully advantage. Not really "traditional", but we did MPEG-4 over partial reliability SCTP instead of RTP/UDP; our first results where encouraging. We will soon do further work in this area. http://www.gufi.org/~molter/papers/mpeg4sctp-molteni-villari-2002-10-24.pdf Marco From lily_wongso@bca.co.id Mon Nov 3 22:57: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 WAA13306 for ; Mon, 3 Nov 2003 22:57:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsKF-0004uN-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 22:57:51 -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 1AGsKA-0004to-00 for sctp-impl-archive@ietf.org; Mon, 03 Nov 2003 22:57:46 -0500 Received: from bca.co.id (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2003 20:01:10 -0800 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 hA43uAAt017332 for ; Mon, 3 Nov 2003 19:56:11 -0800 (PST) Received: from kpfe02.intra.bca.co.id ([202.6.210.3]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA43ugrj024675 for ; Mon, 3 Nov 2003 19:56:43 -0800 (PST) Received: from kpmail01.intra.bca.co.id ([10.128.8.18]) by kpfe02.intra.bca.co.id with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Nov 2003 10:48:28 +0700 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 Date: Tue, 4 Nov 2003 10:48:28 +0700 Message-ID: <44DE5C1D188B034EB745D01E949FE21A05C5B446@kpmail01.intra.bca.co.id> Thread-Index: AcOihoDKBWfVdA7gRaqdnXrdCnhIZA== From: "LILY WONGSO" To: , X-OriginalArrivalTime: 04 Nov 2003 03:48:28.0798 (UTC) FILETIME=[821111E0:01C3A286] Content-Transfer-Encoding: quoted-printable subscribe sctp-impl lily_wongso@bca.co.id From s010884@com.dtu.dk Tue Nov 4 06:01: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 GAA08691 for ; Tue, 4 Nov 2003 06:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGyvw-0003BB-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 06:01:12 -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 1AGyvw-0003AE-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 06:01:12 -0500 Received: from com.dtu.dk (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2003 03:04:48 -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 hA4AxpAt025566 for ; Tue, 4 Nov 2003 02:59:51 -0800 (PST) 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 hA4AxFdQ020524 for ; Tue, 4 Nov 2003 02:59:17 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A2C2.973551F8" Subject: question about the code in SCTP-A reference Guide by Randall R. Stewart and Qiaobing Xie X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 4 Nov 2003 11:58:34 +0100 Message-ID: Thread-Topic: question about the code in SCTP-A reference Guide by Randall R. Stewart and Qiaobing Xie Thread-Index: AcOiwpc42OpWrdLZSa2NvAP187Tk1w== From: "Lei Zhang" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A2C2.973551F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, SCTP players: =20 I want to be sure if the maximum substreams in one association has been = defined as 256 in the code of the book. Because I lost the code = unfortunatly:(( =20 If anyone knows its defination in other patchs, they are also very = welcome... =20 Best Regards =20 Lei ------_=_NextPart_001_01C3A2C2.973551F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, SCTP=20 players:
 
I want to be sure = if the=20 maximum substreams in one association has been defined as 256 in the = code of the=20 book. Because I lost the code unfortunatly:((
 
If anyone knows its = defination=20 in other patchs, they are also very welcome...
 
Best=20 Regards
 
Lei

------_=_NextPart_001_01C3A2C2.973551F8-- From return-fhg@freeholidaygiveaways.com Tue Nov 4 06:42: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 GAA10063 for ; Tue, 4 Nov 2003 06:42:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGzZo-0003o9-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 06:42:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AGzZo-0003n7-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 06:42:24 -0500 Received: from freeholidaygiveaways.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2003 03:43:08 -0800 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 hA4Bf5iN021237 for ; Tue, 4 Nov 2003 03:41:15 -0800 (PST) Received: from freeholidaygiveaways.com ([209.250.134.30]) by sj-inbound-3.cisco.com (8.12.10/8.11.2) with ESMTP id hA4Bf9A4002452 for ; Tue, 4 Nov 2003 03:41:10 -0800 (PST) Message-ID: <20031104064221.A229CE2318CE98CD@freeholidaygiveaways.com> From: "Florida Draw"return-fhg@freeholidaygiveaways.com To: sctp-impl@external.cisco.com Subject: Holiday Draw - Orlando, Florida Reply-To: "Florida Draw"return-fhg@freeholidaygiveaways.com Date: 04 Nov 2003 06:42:21 -0500 MIME-Version: 1.0 x-cpg: fhg-2003-11-02 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_6D2756B2.69FD8451" ------=_NextPart_000_0012_6D2756B2.69FD8451 Content-Type: text/plain 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 you may be eligible for our monthly draw. http://www.freeholidaygiveaways.com/ 5 days and 4 nights in Orlando, Florida 6 days and 5 nights in Ft. Lauderdale, Florida PLU S7 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 at http://www.freeholidaygiveaways.com/ and we'll do the rest. No more offers? Send us a note at: return-fhg@freeholidaygiveaways.com?subject=remove Free Holiday Giveaways ©2003 ------=_NextPart_000_0012_6D2756B2.69FD8451 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = Holiday draw - Orlando, Florida
3D""=
3D"Free

3D"Free
3D"Free

Sign-up for the FREE Holiday Giveaway Draw

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

3D"orlando

5 days and 4 nights in Orlando, Florida

6 d= ays and 5 nights in Ft. Lauderdale, Florida

PLUS

7 day unlim= ited Car Rental

PLUS

2 Tickets to Universal Studios or to Di= sney World

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

No more offers?

Free Holiday Giveaways ©2003
------=_NextPart_000_0012_6D2756B2.69FD8451-- From rrs@cisco.com Tue Nov 4 07:43: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 HAA12349 for ; Tue, 4 Nov 2003 07:43:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0Wy-0004hJ-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 07:43:32 -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 1AH0Wy-0004h3-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 07:43:32 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2003 04:47:07 -0800 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 hA4CgIDd002560; Tue, 4 Nov 2003 04:42:19 -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 ANV65909; Tue, 4 Nov 2003 04:42:17 -0800 (PST) Message-ID: <3FA79EA8.3020102@cisco.com> Date: Tue, 04 Nov 2003 06:42:16 -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: Lei Zhang CC: sctp-impl@external.cisco.com Subject: Re: question about the code in SCTP-A reference Guide by Randall R. Stewart and Qiaobing Xie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Lei Zhang wrote: > Hi, SCTP players: > > I want to be sure if the maximum substreams in one association has > been defined as 256 in the code of the book. Because I lost the code > unfortunatly:(( > > If anyone knows its defination in other patchs, they are also very > welcome... > > Best Regards > > Lei Lei: Looking down and digging in the old CVS repository (note that this is NOT the code that went with the book.. 4.6 was being worked on and never released....sigh not enough cycles..) I see: /* How long a cookie lives */ #define SCTP_DEFAULT_COOKIE_LIFE 60 /* seconds */ /* resource limit of streams */ #define MAX_SCTP_STREAMS 2048 /* max number of unreliable streams sets */ #define MAX_UNRELSTREAM_SETS 10 /* guess at how big to make the TSN mapping array */ #define SCTP_STARTING_MAPARRAY 10000 (you can see how out of date it was since it had "max_unrelstreams_sets" which went away with PR-SCTP)... but here it looks like 2k.. Hope that helps.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From rrs@cisco.com Tue Nov 4 11:50:45 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 LAA22169 for ; Tue, 4 Nov 2003 11:50:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4OO-0000Zg-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 11:50:56 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH4OO-0000ZJ-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 11:50:56 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2003 08:50:44 -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 hA4GnLAt009811 for ; Tue, 4 Nov 2003 08:49: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 ANV82060; Tue, 4 Nov 2003 08:49:20 -0800 (PST) Message-ID: <3FA7D890.6030205@cisco.com> Date: Tue, 04 Nov 2003 10:49:20 -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: Finally some relief from trash emails I hope Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: Don Johnson at ITS has been working very hard to fix the "spam" problem on the sctp-impl list. He is going to put us on a test pilot that will allow us to have the option that only members of the list may post :-> We just finished our last set of tests with some test lists.. so hopefully within a day or so he will cut sctp-impl over to this new format of list... That should hopefully eliminate most of the spam ;-D Happy SCTP'ing R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From djohnsen@cisco.com Tue Nov 4 21:10:55 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 VAA16381 for ; Tue, 4 Nov 2003 21:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHD8T-0001mC-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 21:11:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHD8S-0001ll-00 for sctp-impl-archive@ietf.org; Tue, 04 Nov 2003 21:11:05 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2003 18:11:56 -0800 Received: from cisco.com (djohnsen-ultra.cisco.com [171.71.80.117]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA529CiN022602; Tue, 4 Nov 2003 18:09:13 -0800 (PST) Message-Id: <200311050209.hA529CiN022602@sj-core-4.cisco.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Randall Stewart (cisco)" , SCTP Implementors Subject: Re: Finally some relief from trash emails I hope In-reply-to: Your message of "Tue, 04 Nov 2003 10:49:20 CST." <3FA7D890.6030205@cisco.com> X-pgp-key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xCDAEB789 X-funny-attachment: It's a PGP signature key Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Nov 2003 18:09:12 -0800 From: Don Johnsen Folks - You'll find below my direct contact information if you should see any problems in sending to the list (i.e. rejection messages or your mail not being mirrored to the list). If you see an issue with sending, it will be helpful if you at least send me a mail so I can see exactly how your particular mail client is configured and can troubleshoot. I have modified the list configuration files that will enable the feature; it should become active overnight. Count on seeing some test traffic from me tomorrow AM to verify that all is working as expected. I should note one limitation of the new system; it doesn't like attachments. You will get unexpected results trying to forward attachments via the list. Attachment handling is on the roadmap for the future. -djohnsen > Hi all: > > Don Johnson at ITS has been working very hard to fix the "spam" problem > on the sctp-impl list. He is going to put us on a test pilot that will > allow us to have the option that only members of the list may post :-> > > We just finished our last set of tests with some test lists.. so hopefully > within a day or so he will cut sctp-impl over to this new format of > list... > > That should hopefully eliminate most of the spam ;-D > > Happy SCTP'ing > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > -- Don Johnsen - Systems Administrator, Enterprise Messaging Services Cisco Systems, Inc. Phone : 408 527 1008 400 East Tasman Drive SJ-12/1/F7-4 San Jose, CA 95134-1706 Email : djohnsen@cisco.com From rrs@cisco.com Wed Nov 5 06:36:26 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 GAA01405 for ; Wed, 5 Nov 2003 06:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLxk-0001ko-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 06:36:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHLxj-0001kP-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 06:36:35 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2003 03:37:40 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA5BZNiN000809; Wed, 5 Nov 2003 03:35:23 -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 ANW87767; Wed, 5 Nov 2003 03:35:22 -0800 (PST) Message-ID: <3FA8E07A.5020702@cisco.com> Date: Wed, 05 Nov 2003 05:35:22 -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: A poll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings SCTP'ers: I am trying to establish the various SCTP implementations and who has what. The following are known implementations (to my limited knowledge): Who OS Type Availiablity ------------------------------------------------------------------- KAME BSD's Kernel Free with KAME download (which is free too) LK-SCTP LINUX Kernel Free with add-on will be in 2.6 stable U-ESSEN Various User-Land Free user for download from sctp.de OPENSS7 LINUX Kernel Free download from openss7.org ADAX SUN/Solaris Kernel Available for purchase Trillium (?hughes) Various ???? Available for purchase Others I know have implementations but I am unclear as to their status are: ------------ Artecon HP Solaris Data-Connections Ulticom ???? What I would like to do is establish a new web page on www.sctp.org listing various implementations and where you can get them (purchase or download) and if an implementation comes with an O/S what version of the OS etc.. If you have an implementation and would send me your status aka what O/S, and how it is available... i.e.: o Is it included with an O/S? if so what release o Is it available for purchase by itself? if so what O/S's are supported? o Is it available bundled only with a product? If so what products and can it be used only by your product or does it become available on that machine through an API? For any of the implementations I have listed Various, I would appreciate an email listing the exact machines and O/S's you support. Also if your implementation is planned I can put that up aka (available in a furture release of the XXX O/S is fine).. I would appreciate responses from all the implementations out there .. this will: a) Help further SCTP to the doubters (its not available so why should I use it?) b) Give a centralized web page where people can find out what is out there (send me web links too, I can put these up linking off to your product). c) Give a bit of free advertising to you and your implementation.. Thanks R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From 38brbv@yahoo.com Wed Nov 5 08:45: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 IAA05432 for ; Wed, 5 Nov 2003 08:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHNyw-0004Kv-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 08:45:58 -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 1AHNyv-0004KR-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 08:45:57 -0500 Received: from yahoo.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 05:45:57 -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 hA5DiqAt021078 for ; Wed, 5 Nov 2003 05:44:52 -0800 (PST) Received: from cs2416780-242.houston.rr.com (cs2416780-242.houston.rr.com [24.167.80.242]) by sj-inbound-2.cisco.com (8.12.10/8.11.2) with SMTP id hA5Di7dQ003777 for ; Wed, 5 Nov 2003 05:44:18 -0800 (PST) Received: from [174.158.77.222] by cs2416780-242.houston.rr.com with ESMTP id 18469895; Wed, 05 Nov 2003 10:44:45 -0300 Message-ID: From: "Elisabeth Good" <38brbv@yahoo.com> Reply-To: "Elisabeth Good" <38brbv@yahoo.com> To: Subject: US Stock Market: AZAA - Military Aircraft Related Stock...kiora Date: Wed, 05 Nov 2003 10:44:45 -0300 X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5.0.5DEB..141C7C93._2" X-Priority: 3 --5.0.5DEB..141C7C93._2 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable US Stock Market - UP On the NEWS...AZAA BREAKING NEWS - TUCSON, Ariz.--(BUSINESS WIRE)--Arizona Aircraft Spares, I= nc. (OTCBB: AZAA) - one of the leading military aircraft spare parts manuf= acturers - announces it has signed a letter of commitment with Wolfe and T= urner Investments to obtain a 6 million dollar non-equity asset-backed loa= n. The loan would have a ten-year term with a 25-year amortization schedul= e. AZAA is currently completing the due diligence phase and anticipates th= at funding will occur prior to December 1, 2003. Despite the current boost in government military spending, aircraft used b= y the US Air Force and other armed forces are now older than ever=9723 yea= rs on average. B-52's are older than their pilots, with no plans to build= new bombers for the next 10 years. Result: Aging aircraft require ever-i= ncreasing amounts of expensive maintenance, repairs and replacement parts.= Arizona Aircraft Spares' market potential is measured in billions of dolla= rs. The company works directly with the U.S. Government and other internat= ional world governments. The proposed U.S. military budget alone is 399.1 = billion-dollars, of which twenty-five percent is allocated for spare parts= and ground support systems. Arizona Aircraft Spares focuses exclusively on manufacturing military airc= raft spare parts. The majority of the company's business comes from the U.= S. Government =96 the Army, Navy and Air Force branches of the U.S. Milita= ry. Working with the U.S. Military represents the least cash intensive gro= wth strategy for the company, as the government systematically pays within= 30 days after the company has shipped the product. Furthermore, Arizona A= ircraft Spares is eligible for the =93Progressive Payment=94 program where= by the company can collect upwards of 80% of the contract's total value pr= ior to completion of the contract. AZAA has worked with over 20 international governments and continues to ma= intain international clients apart from the U.S. Government. All other ord= ers are required to put an upfront deposit on all contracts awarded. Arizo= na Aircraft Spares as a public company can take full advantage of the oppo= rtunities in the international markets with enhanced liquidity to execute = larger international projects. Arizona Aircraft Spares, Inc. works primarily with the U.S. Government, fo= cusing exclusively on the Army, Navy and Air Force branches of the U.S. Mi= litary as well as foreign ally countries. The company receives its contra= cts from the Department of Defense Logistics Services located in either Ri= chmond, Virginia or Columbus, Ohio. These two sites represent the central = purchasing group for U.S. Government military contracts, and the point of = origin for all U.S. military bids and contracts. On average, Arizona Aircraft Spares receives over 600 requests to bid on U= S. military spare parts every week. Occasionally, Arizona Aircraft Spares= receives orders from other U.S. Government Prime Contractors, such as Boe= ing and Northrop Grumman. This typically happens in situations when these = companies surmise that Arizona Aircraft Spares can provide the spare parts= at a better cost efficiency than them. To find out more, go to: www.arizonaaircraftspares.com AZAA IS IN NO WAY associated with this newsletter. This is for information puposes only. Penny stocks are considered to be hi= ghly speculative and may be unsuitable for all but very aggressive investo= rs. We do not hold or plan to hold a position in this stock. This Profil= e was a paid advertisement by a third party not affiliated with the profil= ed company. We were compensated 3000 dollars to distribute this report on= ly. Please always consult a registered financial advisor before making any= decisions. This report is for entertainment and advertising purposes onl= y and should not be used as investment advice. No more advertising: www.relar33.com xfpqzakdjqlx e forefwe ovuu hi x yqov bmfv ffpz flms mi xvpj dr nno --5.0.5DEB..141C7C93._2-- From djohnsen@johnsen.org Wed Nov 5 10:31:12 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 KAA10209 for ; Wed, 5 Nov 2003 10:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPcx-0005o6-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 10:31:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHPcw-0005mU-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 10:31:22 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA5FUPiN004174; Wed, 5 Nov 2003 07:30:25 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA5FUBfx016338 for sctp-impl-filtered; Wed, 5 Nov 2003 07:30:13 -0800 (PST) Message-Id: <200311051530.hA5FUBfx016338@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068046211-16336-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Test message X-Nails-Approved: djohnsen@johnsen.org To: sctp-impl@external.cisco.com From: Don Johnsen Date: Wed, 5 Nov 2003 15:26:00 +0000 (GMT) This is a multi-part message in MIME format... ------------=_1068046211-16336-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary From an external list member _________________________________________________________________________ Donald M. Johnsen http://www.johnsen.org/ djohnsen@johnsen.org ------------=_1068046211-16336-0-- From djohnsen@cisco.com Wed Nov 5 10:39: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 KAA10490 for ; Wed, 5 Nov 2003 10:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPlF-0005uK-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 10:39:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHPlE-0005u5-00 for sctp-impl-archive@ietf.org; Wed, 05 Nov 2003 10:39:57 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2003 07:41:04 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA5Fd4iN009990; Wed, 5 Nov 2003 07:39:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA5Fcofx016458 for sctp-impl-filtered; Wed, 5 Nov 2003 07:38:52 -0800 (PST) Message-Id: <200311051538.hA5Fcofx016458@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068046730-16456-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Finally some relief from trash emails I hope X-Nails-Approved: djohnsen@cisco.com To: "Randall Stewart (cisco)" , SCTP Implementors From: Don Johnsen Date: Wed, 05 Nov 2003 07:38:45 -0800 This is a multi-part message in MIME format... ------------=_1068046730-16456-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hopefully you've all just seen my test message to the list from "djohnsen@johnsen.org"; I've also verified that a message from a non-list address was rejected. I think that we're good to go. Release the hounds! :) -djohnsen > Folks - > > You'll find below my direct contact information if you should see any > problems in sending to the list (i.e. rejection messages or your mail not > being mirrored to the list). If you see an issue with sending, it will be > helpful if you at least send me a mail so I can see exactly how your > particular mail client is configured and can troubleshoot. > > I have modified the list configuration files that will enable the feature; > it should become active overnight. Count on seeing some test traffic from > me tomorrow AM to verify that all is working as expected. > > I should note one limitation of the new system; it doesn't like > attachments. You will get unexpected results trying to forward attachments > via the list. Attachment handling is on the roadmap for the future. > > -djohnsen > > > Hi all: > > > > Don Johnson at ITS has been working very hard to fix the "spam" problem > > on the sctp-impl list. He is going to put us on a test pilot that will > > allow us to have the option that only members of the list may post :-> > > > > We just finished our last set of tests with some test lists.. so hopefully > > within a day or so he will cut sctp-impl over to this new format of > > list... > > > > That should hopefully eliminate most of the spam ;-D > > > > Happy SCTP'ing > > > > R > > > > -- > > Randall R. Stewart > > ITD > > Cisco Systems Inc. > > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > > > > -- > Don Johnsen - Systems Administrator, Enterprise Messaging Services > Cisco Systems, Inc. Phone : 408 527 1008 > 400 East Tasman Drive SJ-12/1/F7-4 > San Jose, CA 95134-1706 Email : djohnsen@cisco.com > > ------------=_1068046730-16456-0-- From djohnsen@cisco.com Thu Nov 6 10:48: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 KAA14115 for ; Thu, 6 Nov 2003 10:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmNb-0002jx-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 10:49:03 -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 1AHmNa-0002jR-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 10:49:03 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 07:53:26 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA6FlkAt004369; Thu, 6 Nov 2003 07:47:46 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA6Fl1fx005515 for sctp-impl-filtered; Thu, 6 Nov 2003 07:47:03 -0800 (PST) Message-Id: <200311061547.hA6Fl1fx005515@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068133621-5513-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Blocking on list appears to be functioning well... X-Nails-Approved: djohnsen@cisco.com To: sctp-impl@external.cisco.com From: Don Johnsen Date: Thu, 06 Nov 2003 07:46:56 -0800 This is a multi-part message in MIME format... ------------=_1068133621-5513-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary I have gotten back bounce messages for two rejection notifications to unapproved senders thus far for messages with the following subjects: with subject : "Need *Debt^ Relief? We Can Help! rncqamfgqrqa" with subject : "RE: Uited states..check your credit/\ sjot" As soon as I see some successful traffic from legitimate members of the list, I'm going to declare victory (no, I don't count as a legitimate member...) -djohnsen -- Don Johnsen - Systems Administrator, Enterprise Messaging Services Cisco Systems, Inc. Phone : 408 527 1008 400 East Tasman Drive SJ-12/1/F7-4 San Jose, CA 95134-1706 Email : djohnsen@cisco.com ------------=_1068133621-5513-0-- From rrs@cisco.com Thu Nov 6 12:12:29 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 MAA18866 for ; Thu, 6 Nov 2003 12:12:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHngW-0004KC-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 12:12:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHngW-0004Ix-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 12:12:40 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2003 09:14:12 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA6HBTiN013443; Thu, 6 Nov 2003 09:11:29 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA6HAufx006568 for sctp-impl-filtered; Thu, 6 Nov 2003 09:10:58 -0800 (PST) Message-Id: <200311061710.hA6HAufx006568@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068138656-6566-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: A poll X-Nails-Approved: rrs@cisco.com To: SCTP Implementors From: "Randall Stewart (cisco)" Date: Thu, 06 Nov 2003 11:10:50 -0600 This is a multi-part message in MIME format... ------------=_1068138656-6566-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart (cisco) wrote: > Greetings SCTP'ers: > > > I am trying to establish the various SCTP implementations and > who has what. The following are known implementations (to > my limited knowledge): > > Who OS Type > Availiablity > ------------------------------------------------------------------- > KAME BSD's Kernel Free with > KAME download (which is free too) > LK-SCTP LINUX Kernel Free with add-on > will be in 2.6 stable > U-ESSEN Various User-Land Free user for > download from sctp.de > OPENSS7 LINUX Kernel Free download > from openss7.org > ADAX SUN/Solaris Kernel Available for > purchase > Trillium (?hughes) Various ???? Available for > purchase > > Others I know have implementations but I am unclear as to their status > are: > ------------ > Artecon > HP > Solaris > Data-Connections > Ulticom > > ???? > > What I would like to do is establish a new web page on www.sctp.org > listing various implementations > and where you can get them (purchase or download) and if an > implementation comes with an > O/S what version of the OS etc.. > > If you have an implementation and would send me your status aka what > O/S, and how it is > available... i.e.: > o Is it included with an O/S? if so what release > o Is it available for purchase by itself? if so what O/S's are > supported? > o Is it available bundled only with a product? If so what products > and can it > be used only by your product or does it become available on that > machine > through an API? > > For any of the implementations I have listed Various, I would > appreciate an email listing > the exact machines and O/S's you support. Also if your implementation > is planned > I can put that up aka (available in a furture release of the XXX O/S > is fine).. > > I would appreciate responses from all the implementations out there .. > this will: > > a) Help further SCTP to the doubters (its not available so why should > I use it?) > b) Give a centralized web page where people can find out what is out > there (send me > web links too, I can put these up linking off to your product). > c) Give a bit of free advertising to you and your implementation.. > > Thanks > > R > > Hello all you implementors out there... I have received responses from a couple of you.. I know there are more than that... please take a few moments so I can get a few more names added to my list .. Thanks R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) ------------=_1068138656-6566-0-- From richardk@adax.com Thu Nov 6 13:38:53 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 NAA22168 for ; Thu, 6 Nov 2003 13:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHp27-0005bE-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 13:39:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHp27-0005b4-00 for sctp-impl-archive@ietf.org; Thu, 06 Nov 2003 13:39:03 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA6Ic4iN027626; Thu, 6 Nov 2003 10:38:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA6Ibkfx007701 for sctp-impl-filtered; Thu, 6 Nov 2003 10:37:48 -0800 (PST) Message-Id: <200311061837.hA6Ibkfx007701@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068143865-7699-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: A poll X-Nails-Approved: richardk@adax.com To: "Randall Stewart (cisco)" From: Richard Knowles Date: Thu, 6 Nov 2003 09:57:53 -0800 (PST) This is a multi-part message in MIME format... ------------=_1068143865-7699-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary ADAX SUN/Solaris Kernel Available for Linux Kernel purchase. On Thu, 6 Nov 2003, Randall Stewart (cisco) wrote: > Randall Stewart (cisco) wrote: > > > Greetings SCTP'ers: > > > > > > I am trying to establish the various SCTP implementations and > > who has what. The following are known implementations (to > > my limited knowledge): > > > > Who OS Type > > Availiablity > > ------------------------------------------------------------------- > > KAME BSD's Kernel Free with > > KAME download (which is free too) > > LK-SCTP LINUX Kernel Free with add-on > > will be in 2.6 stable > > U-ESSEN Various User-Land Free user for > > download from sctp.de > > OPENSS7 LINUX Kernel Free download > > from openss7.org ADAX SUN/Solaris Kernel Available for > > purchase > > Trillium (?hughes) Various ???? Available for > > purchase > > > > Others I know have implementations but I am unclear as to their status > > are: > > ------------ > > Artecon > > HP > > Solaris > > Data-Connections > > Ulticom > > > > ???? > > > > What I would like to do is establish a new web page on www.sctp.org > > listing various implementations > > and where you can get them (purchase or download) and if an > > implementation comes with an > > O/S what version of the OS etc.. > > > > If you have an implementation and would send me your status aka what > > O/S, and how it is > > available... i.e.: > > o Is it included with an O/S? if so what release > > o Is it available for purchase by itself? if so what O/S's are > > supported? > > o Is it available bundled only with a product? If so what products > > and can it > > be used only by your product or does it become available on that > > machine > > through an API? > > > > For any of the implementations I have listed Various, I would > > appreciate an email listing > > the exact machines and O/S's you support. Also if your implementation > > is planned > > I can put that up aka (available in a furture release of the XXX O/S > > is fine).. > > > > I would appreciate responses from all the implementations out there .. > > this will: > > > > a) Help further SCTP to the doubters (its not available so why should > > I use it?) > > b) Give a centralized web page where people can find out what is out > > there (send me > > web links too, I can put these up linking off to your product). > > c) Give a bit of free advertising to you and your implementation.. > > > > Thanks > > > > R > > > > > Hello all you implementors out there... I have received responses from > a couple of you.. I know there are more than that... please take a > few moments so I can get a few more names added to my list .. > > Thanks > > R > > -- Richard Knowles Senior Network Support Engineer Adax, Inc. 614 Bancroft Way Berkeley, CA 94710 Tel: 1-(510)-548-7047 ext. 148 Fax: 1-(510)-548-5526 http://www.adax.com ------------=_1068143865-7699-0-- From s010884@com.dtu.dk Fri Nov 7 09:18: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 JAA15442 for ; Fri, 7 Nov 2003 09:18:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Ra-0005el-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 09:18:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AI7RZ-0005ea-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 09:18:33 -0500 Received: from com.dtu.dk (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 06:20:22 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA7EHPrX004173; Fri, 7 Nov 2003 06:17:26 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7EGdfx023145 for sctp-impl-filtered; Fri, 7 Nov 2003 06:16:41 -0800 (PST) Message-Id: <200311071416.hA7EGdfx023145@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068214599-23143-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: question about data-bundling X-Nails-Approved: s010884@com.dtu.dk To: From: "Lei Zhang" Date: Fri, 7 Nov 2003 15:15:13 +0100 This is a multi-part message in MIME format... ------------=_1068214599-23143-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi, sctp-players: I think SCTP segment permits data chunks to be bundled with absence of SACK chunk. (is it right?) But when I deal with such a segment during an unbundling process, I found a problem. It is hard to judge if these data chunks should be put into receive buffer without the acknowledge information. Because the information is used for updating congestion-control algorithm... TCP always put data into its receive buffer after the acknowledge checking. So, I want to know how SCTP deals with the situation. ... happy weekends Lei ------------=_1068214599-23143-0 Content-Type: text/html Content-Disposition: inline Content-Transfer-Encoding: binary
Hi, sctp-players:
 

I think SCTP segment permits data chunks to be bundled with absence of SACK chunk. (is it right?)

 

But when I deal with such a segment during an unbundling process, I found a problem. It is hard to judge if these data chunks should be put into receive buffer without the acknowledge information. Because the information is used for updating congestion-control algorithm…

 

TCP always put data into its receive buffer after the acknowledge checking.

 

So, I want to know how SCTP deals with the situation.

 

….

 

happy weekends

 

Lei

 

------------=_1068214599-23143-0-- From rrs@cisco.com Fri Nov 7 13:22: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 NAA27782 for ; Fri, 7 Nov 2003 13:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBFy-0000nr-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 13:22:50 -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 1AIBFy-0000nb-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 13:22:50 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7ILoAt014996; Fri, 7 Nov 2003 10:21:50 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7IL0fx026279 for sctp-impl-filtered; Fri, 7 Nov 2003 10:21:02 -0800 (PST) Message-Id: <200311071821.hA7IL0fx026279@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068229260-26277-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: question about data-bundling X-Nails-Approved: rrs@cisco.com To: Lei Zhang From: "Randall Stewart (cisco)" Date: Fri, 07 Nov 2003 12:20:50 -0600 This is a multi-part message in MIME format... ------------=_1068229260-26277-0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Lei Zhang wrote: > Hi, sctp-players: > > I think SCTP segment permits data chunks to be bundled with absence of > SACK chunk. (is it right?) > Yep that is correct.. you are allowed to send a all DATA packet with nothing in it but DATA chunks. > But when I deal with such a segment during an unbundling process, I > found a problem. It is hard to judge if these data chunks should be > put into receive buffer without the acknowledge information. Because > the information is used for updating congestion-control algorithm… > Well I don't see a problem here. If the receiver has stuff to send, then it attempts to send based on the current cwnd situation. If the flight size is larger than the cwnd then this means the receiver of the "all data" packet will NOT send any new data.. it may send a sack (based on if it is the second such packet it has received).. but it is not an issue. Even in TCP this happens... Consider two opposing TCP senders: ----Seq=100 Ack=4000 (data=1400)------------------> <---------------Seq=4000 Ack=100 (data=100) ----Seq=1500 Ack=4000(data=1400)------------------> <---------------Seq=4100 Ack=100 (data=100) At the time both sides launch there packets they report the current ack state. This is no updated to the pervious state the peer knows.. but it is included anyway... When either side "updates the acked" information it will gain nothing in the cwnd since nothing as changed and the ack is no different than before... When you have bi-directional data this will happen all the time .. On the other hand if one side sends at a different time then it can send an update.. just like in SCTP's case you could then bundle a SACK.. Hope that helps.. R > TCP always put data into its receive buffer after the acknowledge > checking. > > So, I want to know how SCTP deals with the situation. > > …. > > happy weekends > > Lei > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) ------------=_1068229260-26277-0-- From sarkar@ccpu.com Fri Nov 7 14:53: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 OAA03973 for ; Fri, 7 Nov 2003 14:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICgC-00026I-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 14:54:00 -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 1AICgA-00025e-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 14:54:00 -0500 Received: from ccpu.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2003 11:58:38 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA7JqcrX005841; Fri, 7 Nov 2003 11:52:49 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7JqIfx027461 for sctp-impl-filtered; Fri, 7 Nov 2003 11:52:20 -0800 (PST) Message-Id: <200311071952.hA7JqIfx027461@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068234738-27459-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Question about socket API X-Nails-Approved: sarkar@ccpu.com To: From: "Rajib Sarkar" Date: Fri, 7 Nov 2003 11:45:02 -0800 This is a multi-part message in MIME format... ------------=_1068234738-27459-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I am implementing the socket API draft and have a question about TCP (one to one) style vs. UDP (one to many) style interfaces. After reading the draft I understood that the draft recommends the user to use one to many for all new application. Is there any reason for that? Some places the draft says "it is more efficient in terms of using most new SCTP feature", can you please provide some example? In the draft it is stated that if we use different buffers for each association in one to many style socket, and before sending data if we use select call to find out whether the socket is blocked, is there any way we can find for which association the socket is blocked? Any help will be highly appreciated. Thanks Rajib ------------=_1068234738-27459-0-- From kavithab@austin.ibm.com Fri Nov 7 16:36:23 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 QAA08923 for ; Fri, 7 Nov 2003 16:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEHR-0003NI-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 16:36:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AIEHR-0003N9-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 16:36:33 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hA7LZNiN003014; Fri, 7 Nov 2003 13:35:23 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7LYqfx028790 for sctp-impl-filtered; Fri, 7 Nov 2003 13:34:54 -0800 (PST) Message-Id: <200311072134.hA7LYqfx028790@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068240892-28788-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: A poll X-Nails-Approved: kavithab@austin.ibm.com To: "Randall Stewart (cisco)" From: Kavitha Baratakke Date: Fri, 7 Nov 2003 15:30:27 -0600 (CST) This is a multi-part message in MIME format... ------------=_1068240892-28788-0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: binary Hi Randall, I am Kavitha Baratakke, one of the developers working on an SCTP kernel implementation on IBM's AIX operating system. Here's the info on our implementation. Operating System: AIX Implementation Type: Kernel Version: Due to release probably next year (Sept 2004 timeframe) Availability: As a loadable kernel module which will be shipped with the OS as a part of an existing fileset. Purchasing: As far as I am aware, it is not available for purchase by itself. The only OS supported by our implementation is AIX. We support the standard sockets API and for now have only UDP-style implementation. Let me know if there's any other information I can provide which I might be missing here. Thanks, Kavitha ------------=_1068240892-28788-0-- From kacheong.poon@sun.com Fri Nov 7 18:28:28 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 SAA14066 for ; Fri, 7 Nov 2003 18:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIG1t-0004o2-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 18:28:37 -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 1AIG1s-0004nE-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 18:28:37 -0500 Received: from sun.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2003 15:32:16 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA7NQaw5002199; Fri, 7 Nov 2003 15:26:36 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7NQMFu000344 for sctp-impl-filtered; Fri, 7 Nov 2003 15:26:24 -0800 (PST) Message-Id: <200311072326.hA7NQMFu000344@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068247582-342-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Question about socket API X-Nails-Approved: kacheong.poon@sun.com To: Rajib Sarkar From: Kacheong Poon Date: Fri, 07 Nov 2003 15:24:53 -0800 This is a multi-part message in MIME format... ------------=_1068247582-342-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Rajib Sarkar wrote: > I am implementing the socket API draft and have a question about TCP (one > to one) style vs. UDP (one to many) style interfaces. After reading the > draft I understood that the draft recommends the user to use one to many for > all new application. Is there any reason for that? Some places the draft > says "it is more efficient in terms of using most new SCTP feature", can you > please provide some example? Where do you read it in the draft saying that all new applications are recommended to use 1-N socket? If there is such a line, we should probably remove it... The "efficient..." sentence was left there since the early days of the draft. I guess it should probably be removed too. The same mechanism is used for both 1-1 and 1-N style socket to exploit new SCTP features. So I don't think one is more efficient than the other in this aspect. > In the draft it is stated that if we use different buffers for each > association in one to many style socket, and before sending data if we use > select call to find out whether the socket is blocked, is there any way we > can find for which association the socket is blocked? The select() part in the current draft for 1-N style socket in sending is close to broken. For sending, a reasonable semantics for select() on 1-N style socket is to return true always. Note that I am talking about semantics here, not about the actual implementation which can lead to many different behaviors. The reason to return true is that the socket is not really tied to any association it controls. So it "may" assume that one of them got to be writable. But in general, I'd suggest 1-N style socket not to be used with select(). The call is not designed for it. That part of the draft should be re-written in the next version. To summarize, I guess which programming style to pick really depends on the app. For some app, using the 1-1 style socket may be more efficient while for another app, 1-N style is better. You asked about select() and people have claimed that it is slow and can only work for a limited set of file descriptors. I believe the reason for the select() limit is some C standard for 32 bit apps. For example in Solaris, the FD_SETSIZE limit of select() for 64 bit apps is 64K. I think this is also true for other 64 bit OSes. To go higher than that and be more efficient, most OSes have other mechanisms, such as poll(), /dev/poll, ... And most OSes also have asynchronous socket ops which provide similar semantics as the 1-N style socket. But until the async socket becomes (it may have already) a standard, this kind of mechanism may not be portable. -- K. Poon. kacheong.poon@sun.com ------------=_1068247582-342-0-- From kacheong.poon@sun.com Fri Nov 7 18:51:55 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 SAA14698 for ; Fri, 7 Nov 2003 18:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGOb-00056y-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 18:52:05 -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 1AIGOa-00056h-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 18:52:05 -0500 Received: from sun.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2003 15:56:52 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7Np7At029734; Fri, 7 Nov 2003 15:51:08 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA7NopFu000688 for sctp-impl-filtered; Fri, 7 Nov 2003 15:50:53 -0800 (PST) Message-Id: <200311072350.hA7NopFu000688@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068249051-686-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Question about socket API X-Nails-Approved: kacheong.poon@sun.com To: Rajib Sarkar From: Kacheong Poon Date: Fri, 07 Nov 2003 15:49:28 -0800 This is a multi-part message in MIME format... ------------=_1068249051-686-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Rajib Sarkar wrote: > See my comments below. > In the receive path I have to do select, but in the sending path I am not > sure why do I need to do a select(), is it always non blocking in the send > path? I think this was discussed before in the list, can't remember for sure. I believe it was suggested that the 1-N style socket should be set to non-blocking at the start of a program. Do not call select() on sending for 1-N style socket. Check the return value of sendmsg() and errno instead, and see if the particular association is writable. -- K. Poon. kacheong.poon@sun.com ------------=_1068249051-686-0-- From ma-kun@kozuka.jp Fri Nov 7 19:39: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 TAA16591 for ; Fri, 7 Nov 2003 19:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH8c-0005u4-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 19:39:38 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AIH8b-0005td-00 for sctp-impl-archive@ietf.org; Fri, 07 Nov 2003 19:39:37 -0500 Received: from kozuka.jp (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 16:41:35 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA80chAt029970; Fri, 7 Nov 2003 16:38:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hA80cGFu001344 for sctp-impl-filtered; Fri, 7 Nov 2003 16:38:18 -0800 (PST) Message-Id: <200311080038.hA80cGFu001344@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068251896-1342-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: PULLDOWN_TEST X-Nails-Approved: ma-kun@kozuka.jp To: sctp-impl@external.cisco.com From: KOZUKA Masahiro Date: Sat, 8 Nov 2003 09:36:28 +0900 This is a multi-part message in MIME format... ------------=_1068251896-1342-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi. I'm playing KAME's SCTP stack(patch 14) on NeBSD. I found that PF_INET6 && IPPROTO_SCTP does't work on NetBSD/KAME. In detail, IPv6's SCTP packet not processed at all. On the other hand, PF_INET && IPPROTO_SCTP no problem in the same environment. sctp6_input() in sys/netinet6/sctp6_usrreq.c has a problem, doesn't it? -- --- kame/sys/netinet6/sctp6_usrreq.c.orig Sat Nov 8 09:06:45 2003 +++ kame/sys/netinet6/sctp6_usrreq.c Sat Nov 8 09:29:13 2003 @@ -191,7 +191,9 @@ iphlen = off; +#ifndef PULLDOWN_TEST IP6_EXTHDR_CHECK(m, off, sizeof(struct sctphdr), IPPROTO_DONE); +#endif ip6 = mtod(m, struct ip6_hdr *); -- On FreeBSD this problem does't appear because PULLDOWN_TEST not defined yet. But this change is required on NetBSD. So, I want to merger this change. Thanks. -- {^-^}/@kozuka.jp / KOZUKA Masahiro ------------=_1068251896-1342-0-- From mohammed.asharaf@wipro.com Mon Nov 10 02:37: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 CAA11665 for ; Mon, 10 Nov 2003 02:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ6c0-0000eY-00 for sctp-impl-archive@ietf.org; Mon, 10 Nov 2003 02:37:24 -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 1AJ6c0-0000eG-00 for sctp-impl-archive@ietf.org; Mon, 10 Nov 2003 02:37:24 -0500 Received: from wipro.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2003 23:38:32 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAA7a4At002885; Sun, 9 Nov 2003 23:36:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hAA7XqFu014055 for sctp-impl-filtered; Sun, 9 Nov 2003 23:33:54 -0800 (PST) Message-Id: <200311100733.hAA7XqFu014055@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068449632-14053-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: A poll X-Nails-Approved: mohammed.asharaf@wipro.com To: "Randall Stewart (cisco)" From: "Mohammed Ashraf" Date: Mon, 10 Nov 2003 12:40:58 +0530 This is a multi-part message in MIME format... ------------=_1068449632-14053-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi Randy, We (Wipro Technolgies, India ) too have a userland implemention of SCTP for Linux. Port for other Unix variants will also be made available soon. This will be made availbale as FREE download on our Wipro website(www.wipro.com) in 2-3 weeks time - we shall keep you posted. Please add this implementaion also to your sctp.org list as well. thanks, ashraf -----Original Message----- From: Kavitha Baratakke [mailto:kavithab@austin.ibm.com] Sent: Sat 11/8/2003 3:00 AM To: Randall Stewart (cisco) Cc: Subject: Re: A poll Hi Randall, I am Kavitha Baratakke, one of the developers working on an SCTP kernel implementation on IBM's AIX operating system. Here's the info on our implementation. Operating System: AIX Implementation Type: Kernel Version: Due to release probably next year (Sept 2004 timeframe) Availability: As a loadable kernel module which will be shipped with the OS as a part of an existing fileset. Purchasing: As far as I am aware, it is not available for purchase by itself. The only OS supported by our implementation is AIX. We support the standard sockets API and for now have only UDP-style implementation. Let me know if there's any other information I can provide which I might be missing here. Thanks, Kavitha **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *************************************************************************** ------------=_1068449632-14053-0 Content-Type: text/html Content-Disposition: inline Content-Transfer-Encoding: binary RE: A poll

Hi Randy,

We (Wipro Technolgies, India ) too have a userland implemention of SCTP for Linux. Port for other Unix variants will also be made available soon. This will be made availbale as FREE
download on  our Wipro website(www.wipro.com) in 2-3 weeks time - we shall keep you posted. Please add this implementaion also to your sctp.org list as well.

thanks,
ashraf

-----Original Message-----
From:   Kavitha Baratakke [mailto:kavithab@austin.ibm.com]
Sent:   Sat 11/8/2003 3:00 AM
To:     Randall Stewart (cisco)
Cc:    
Subject:        Re: A poll

Hi Randall,

I am Kavitha Baratakke, one of the developers working on an SCTP
kernel implementation on IBM's AIX operating system.

Here's the info on our implementation.

Operating System: AIX
Implementation Type: Kernel
Version: Due to release probably next year (Sept 2004 timeframe)
Availability: As a loadable kernel module which will be shipped with the
OS as a part of an existing fileset.
Purchasing: As far as I am aware, it is not available for purchase by
itself. The only OS supported by our implementation is AIX. We support
the standard sockets API and for now have only UDP-style implementation.

Let me know if there's any other information I can provide which I might
be missing here.

Thanks,
Kavitha





 

**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***************************************************************************
------------=_1068449632-14053-0-- From s010884@com.dtu.dk Wed Nov 12 06:53:41 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 GAA14843 for ; Wed, 12 Nov 2003 06:53:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJtZG-0005Ry-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 06:53:51 -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 1AJtZG-0005Rj-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 06:53:50 -0500 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hACBqemU014842; Wed, 12 Nov 2003 03:52:41 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hACBoYFu025223 for sctp-impl-filtered; Wed, 12 Nov 2003 03:50:36 -0800 (PST) Message-Id: <200311121150.hACBoYFu025223@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068637833-25221-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: question: unordered SEG_ARRIVAL X-Nails-Approved: s010884@com.dtu.dk To: From: "Lei Zhang" Date: Wed, 12 Nov 2003 12:49:10 +0100 This is a multi-part message in MIME format... ------------=_1068637833-25221-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi, sctp plays: Usually, TCP puts an unordered segment into a buffer that is used to contain such kinds of data, and releases some or all of them if the holes in them are filled by the newest incoming segment. The buffer is installed for each TCP connection. In SCTP, one assocation has a set of congestion control. The kind of buffer mentioned above should be installed for the entire association, or for each substream? My opnion is the buffer should be substream-based. And the unordered messages could be released according to the message sequences(stream sequence number). Am I right? Kind Regards Lei ------------=_1068637833-25221-0 Content-Type: text/html Content-Disposition: inline Content-Transfer-Encoding: binary
Hi, sctp plays:
 
 Usually, TCP puts an unordered segment into a buffer that is used to contain such kinds of data, and releases some or all of them if the holes in them are filled by the newest incoming segment. The buffer is installed for each TCP connection.
 
In SCTP, one assocation has a set of congestion control. The kind of buffer mentioned above should be installed for the entire association, or for each substream? My opnion is the buffer should be substream-based. And the unordered messages could be released according to the message sequences(stream sequence number).
 
Am I right?
 
Kind Regards
 
Lei

------------=_1068637833-25221-0-- From rrs@cisco.com Wed Nov 12 08:47: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 IAA17266 for ; Wed, 12 Nov 2003 08:47:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJvLt-0006gr-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 08:48: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 1AJvLr-0006fn-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 08:48:08 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2003 05:49:46 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACDl1w5008708; Wed, 12 Nov 2003 05:47:05 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hACDjLFu026743 for sctp-impl-filtered; Wed, 12 Nov 2003 05:45:23 -0800 (PST) Message-Id: <200311121345.hACDjLFu026743@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068644721-26741-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: question: unordered SEG_ARRIVAL X-Nails-Approved: rrs@cisco.com To: Lei Zhang From: "Randall Stewart (cisco)" Date: Wed, 12 Nov 2003 07:45:14 -0600 This is a multi-part message in MIME format... ------------=_1068644721-26741-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Lei: I am confused by your use of the word "unordered" in this email. If you are refering to an un-ordered chunk (marked with the U bit set to 1) these would have NO need for any "buffer" for reordering.. since the micro-second they arrive they can be released to the app for reading. Now if you are referring to a ordered message that is sent in a stream with the U bit set to 0. Then yes, normally an implementation would probably want to do a re-order queue per stream. This of course is an implementation detail. In the KAME stack we have a linked list of chunks pending re-order per stream... one could envision a implementation that would possibly run (with less performance) where only one queue was used i.e. its a trade off for the implementation memory vs performance. Now I don't really understand your use of the word "buffer" either. Since SCTP is NOT like TCP in that message boundaries are preserved and you can't just keep a buffer to fill in things awaiting re-order. There is more information then just the data that must be held on a chunk... But I guess you must of meant buffer equivilant... R Lei Zhang wrote: > Hi, sctp plays: > > Usually, TCP puts an unordered segment into a buffer that is used to > contain such kinds of data, and releases some or all of them if the > holes in them are filled by the newest incoming segment. The buffer is > installed for each TCP connection. > > In SCTP, one assocation has a set of congestion control. The kind of > buffer mentioned above should be installed for the entire association, > or for each substream? My opnion is the buffer should be > substream-based. And the unordered messages could be released > according to the message sequences(stream sequence number). > > Am I right? > > Kind Regards > > Lei -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) ------------=_1068644721-26741-0-- From djohnsen@cisco.com Wed Nov 12 12:28: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 MAA28688 for ; Wed, 12 Nov 2003 12:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJynb-0002ks-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 12:28:59 -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 1AJyna-0002km-00 for sctp-impl-archive@ietf.org; Wed, 12 Nov 2003 12:28:58 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 09:35:16 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACHS3w5017778; Wed, 12 Nov 2003 09:28:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hACHQWFu029625 for sctp-impl-filtered; Wed, 12 Nov 2003 09:26:34 -0800 (PST) Message-Id: <200311121726.hACHQWFu029625@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1068657992-29623-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Minor change to code controlling sctp-impl X-Nails-Approved: djohnsen@cisco.com To: rrs@cisco.com From: Don Johnsen Cc: sctp-impl@external.cisco.com Date: Wed, 12 Nov 2003 09:26:27 -0800 This is a multi-part message in MIME format... ------------=_1068657992-29623-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Folks - Got a couple of reports about filters not working for people on the list; my code wasn't properly inserting the cc: header when used. As you'll hopefully see from this message, it does now. -djohnsen -- Don Johnsen - Systems Administrator, Enterprise Messaging Services Cisco Systems, Inc. Phone : 408 527 1008 400 East Tasman Drive SJ-12/1/F7-4 San Jose, CA 95134-1706 Email : djohnsen@cisco.com ------------=_1068657992-29623-0-- From s010884@com.dtu.dk Mon Nov 17 07:08:26 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 HAA09221 for ; Mon, 17 Nov 2003 07:08:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALiBI-0005SX-00 for sctp-impl-archive@ietf.org; Mon, 17 Nov 2003 07:08:36 -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 1ALiBI-0005S2-00 for sctp-impl-archive@ietf.org; Mon, 17 Nov 2003 07:08:36 -0500 Received: from com.dtu.dk (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 04:16:04 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHC6Etg021720; Mon, 17 Nov 2003 04:06:14 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hAHC4tKs029361 for sctp-impl-filtered; Mon, 17 Nov 2003 04:04:57 -0800 (PST) Message-Id: <200311171204.hAHC4tKs029361@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1069070695-29359-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: the problem happened in the unbundling List-Id: sctp-impl To: "Randall Stewart (cisco)" From: "Lei Zhang" Cc: X-Nails-Approved: s010884@com.dtu.dk Date: Mon, 17 Nov 2003 13:03:30 +0100 This is a multi-part message in MIME format... ------------=_1069070695-29359-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I creats a SCTP segment bundling two data chunks, for instance. When the receiver unbundles the segments, it first sees the data chunk that was bundled at last. So, the receiver then sends a SACK chunk immediatly because it thinks the out-of-order happens. If things happen like that, there are two much SACK chunks being replied. Anyone meet such problem? any suggestions? thanks! Lei ------------=_1069070695-29359-0-- From rrs@cisco.com Mon Nov 17 10:41:21 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 KAA16437 for ; Mon, 17 Nov 2003 10:41:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlVM-0000Hh-00 for sctp-impl-archive@ietf.org; Mon, 17 Nov 2003 10:41:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ALlVM-0000Gz-00 for sctp-impl-archive@ietf.org; Mon, 17 Nov 2003 10:41:32 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 07:42:05 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAHFe9iN006322; Mon, 17 Nov 2003 07:40:09 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hAHFdNKs002195 for sctp-impl-filtered; Mon, 17 Nov 2003 07:39:24 -0800 (PST) Message-Id: <200311171539.hAHFdNKs002195@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1069083562-2193-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: the problem happened in the unbundling List-Id: sctp-impl To: Lei Zhang From: "Randall Stewart (cisco)" Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Mon, 17 Nov 2003 09:39:15 -0600 This is a multi-part message in MIME format... ------------=_1069083562-2193-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Lei Zhang wrote: >Hi, > >I creats a SCTP segment bundling two data chunks, for instance. When the receiver unbundles the segments, it first sees the data chunk that was bundled at last. So, the receiver then sends a SACK chunk immediatly because it thinks the out-of-order happens. If things happen like that, there are two much SACK chunks being replied. > >Anyone meet such problem? any suggestions? > >thanks! > >Lei > > > Lei: I presume from your comments you are bundling DATA chunks in reverse order. This is not how most implementations do this for just the reason you site. I.e. you have TSN=100 TSN=101 TSN=102 You then would bundle them: --------- Com-hdr ------- Data TSN=100 ------ Data TSN=101 ------ Data TSN=102 ----- If you instead send a packet that looks like: --------- Com-hdr ------- Data TSN=102 ------ Data TSN=101 ------ Data TSN=100 ----- Which I think you are implying that you are.. then yes if one processed independantly each TSN one might reach the wrong conclusion. But if you process the whole packet before responding (which most implementations do) then I don't even think this would be a problem (though it is a bit strange) in theory it should not cause a problem.. since you would mark 102 then 101 then 100 and then move forward the cum-ack to 102 and realize there was no gap and so send a packet based on the delayed sack algorithm. I don't see either way as a problem.. even though I think most implementions will send the first layout of packet I illustrate not the second. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) ------------=_1069083562-2193-0-- From rrs@cisco.com Tue Nov 18 16:13: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 QAA16554 for ; Tue, 18 Nov 2003 16:13:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMDAk-0006Et-00 for sctp-impl-archive@ietf.org; Tue, 18 Nov 2003 16:14:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AMDAj-0006DV-00 for sctp-impl-archive@ietf.org; Tue, 18 Nov 2003 16:14:06 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 13:13:50 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAILCZAt028204; Tue, 18 Nov 2003 13:12:36 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hAILBPKs025143 for sctp-impl-filtered; Tue, 18 Nov 2003 13:11:27 -0800 (PST) Message-Id: <200311182111.hAILBPKs025143@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1069189885-25135-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: patch 15 List-Id: sctp-impl To: SCTP Implementors From: "Randall Stewart (cisco)" X-Nails-Approved: rrs@cisco.com Date: Tue, 18 Nov 2003 15:11:19 -0600 This is a multi-part message in MIME format... ------------=_1069189885-25135-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi all: Please find at www.sctp.org a new patch No 15. This brings KAME almost completely up to the I-G version 10 that was released last week.. with the exception of our HB nonces are still only 32 bits. I will try to get that up to the 64 bit requirement sometime in the next week or so... Happy SCTPing R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) ------------=_1069189885-25135-0-- From ma-kun@kozuka.jp Fri Nov 21 16:55: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 QAA05312 for ; Fri, 21 Nov 2003 16:55:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJFj-0001mF-00 for sctp-impl-archive@ietf.org; Fri, 21 Nov 2003 16:55:47 -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 1ANJFi-0001lG-00 for sctp-impl-archive@ietf.org; Fri, 21 Nov 2003 16:55:47 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 13:55:52 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALLsoAt013060; Fri, 21 Nov 2003 13:54:51 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hALLrwKs022072 for sctp-impl-filtered; Fri, 21 Nov 2003 13:54:00 -0800 (PST) Message-Id: <200311212154.hALLrwKs022072@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1069451637-22070-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: netstat's support for SCTP List-Id: sctp-impl To: sctp-impl@external.cisco.com From: KOZUKA Masahiro X-Nails-Approved: ma-kun@kozuka.jp Date: Sat, 22 Nov 2003 06:50:13 +0900 This is a multi-part message in MIME format... ------------=_1069451637-22070-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I have written the netstat's code supporting SCTP on NetBSD. If SCTP used for HTTP, netstat's support (Ex. to know where I accepted association) must be needed, I think. Sample output: -- Active Stream Conrol Transmission Protocol associations (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State sctp 0 0 fe80::250:56ff:f.8080 ::1.8079 ESTABLISHED 2001:380:5b00:1:.8080 127.0.0.1.8079 fe80::250:56ff:f.8080 N/A ::1.8080 N/A sctp 0 0 127.0.0.1.8079 ::1.8080 ESTABLISHED ::1.8079 2001:380:5b00:1:.8080 N/A 192.168.1.126.8080 N/A 192.168.0.4.8080 N/A 127.0.0.1.8080 sctp 220 0 fe80::250:56ff:f.8080 *.* LISTEN 2001:380:5b00:1:.8080 *.* 192.168.1.126.8080 *.* fe80::250:56ff:f.8080 *.* 192.168.0.4.8080 *.* 127.0.0.1.8080 *.* ::1.8080 *.* -- If 2 more addresses are bound to one PCB, netstat's output is over one line... But I can't have any idea. If there is better idea, I want to know. P.S. I have the plan to support on FreeBSD, but FreeBSD's netstat is very different from NetBSD's. So that I can't write it soon:) Regards, Masahiro -- {^-^}/@kozuka.jp / KOZUKA Masahiro diff -u -N -r netstat.orig/Makefile netstat/Makefile --- netstat.orig/Makefile Sat Nov 8 09:00:44 2003 +++ netstat/Makefile Sat Nov 22 06:10:39 2003 @@ -3,7 +3,7 @@ PROG= netstat SRCS= atalk.c if.c inet.c inet6.c ipsec.c iso.c main.c mbuf.c mroute.c \ - mroute6.c ns.c route.c tp_astring.c unix.c + mroute6.c ns.c route.c tp_astring.c unix.c sctp.c .PATH: ${.CURDIR}/../../sys/netiso BINGRP= kmem BINMODE=2555 @@ -11,6 +11,7 @@ DPADD= ${LIBKVM} CPPFLAGS+= -DINET6 -DIPSEC CPPFLAGS+= -DDCCP +CPPFLAGS+= -DSCTP .if exists(/usr/local/v6/lib/libinet6.a) LDADD+= -L${.CURDIR}/../../lib/libinet6 \ diff -u -N -r netstat.orig/main.c netstat/main.c --- netstat.orig/main.c Sat Nov 8 09:00:44 2003 +++ netstat/main.c Sat Nov 22 06:10:14 2003 @@ -187,6 +187,8 @@ { "_dccpbtable" }, #define N_DCCPB6 58 { "_dccpb6" }, +#define N_SCTPEPINFO 59 + { "_sctppcbinfo" }, { "" }, }; @@ -221,6 +223,10 @@ #ifdef IPSEC { -1, N_IPSECSTAT, 1, 0, ipsec_stats, NULL, 0, "ipsec" }, +#endif +#ifdef SCTP + { N_SCTPEPINFO, -1, 1, sctp_protopr, + NULL, NULL, 0, "sctp" }, #endif { -1, -1, 0, 0, 0, NULL, 0, 0 } diff -u -N -r netstat.orig/netstat.h netstat/netstat.h --- netstat.orig/netstat.h Sat Nov 8 09:00:44 2003 +++ netstat/netstat.h Sat Nov 22 06:10:15 2003 @@ -103,6 +103,10 @@ void dccp6_stats __P((u_long, char *)); #endif +#ifdef SCTP +void sctp_protopr __P((u_long, char *)); +#endif + #ifdef IPSEC void pfkey_stats __P((u_long, char *)); #endif diff -u -N -r netstat.orig/sctp.c netstat/sctp.c --- netstat.orig/sctp.c Thu Jan 1 09:00:00 1970 +++ netstat/sctp.c Sat Nov 22 06:15:25 2003 @@ -0,0 +1,448 @@ +/* + * Copyright (c) 1983, 1988, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#ifndef lint +#if 0 +static char sccsid[] = "from: @(#)inet.c 8.4 (Berkeley) 4/20/94"; +#else +__RCSID("$NetBSD: inet.c,v 1.51 2002/02/27 02:33:51 lukem Exp $"); +#endif +#endif /* not lint */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include "netstat.h" + +#ifdef SCTP +struct pool { +}; /* XXX pool defined only in KERNEL */ +#include + +static int width; + +void inet46print __P((struct sockaddr *, u_int16_t, int)); + +void +sctp_protopr(off, name) + u_long off; + char *name; +{ + int compact; + struct sctp_epinfo epinfo; + struct sctp_inpcb *inp_next, *inp_prev; + struct sctp_inpcb inp; + struct sctp_tcb *tcb_next, *tcb_prev; + struct sctp_tcb tcb; + struct ifaddrs *ifap0, *ifap; + struct sctp_laddr *laddr_next, *laddr_prev; + struct sctp_laddr laddr; + struct ifaddr ifa; + struct sockaddr_storage ss; + int ss_len; + struct sctp_nets *nets_next, *nets_prev; + struct sctp_nets nets; + struct sockaddr *sa; + struct sockaddr_in *sin, *sin_r, sin_any; + struct sockaddr_in6 *sin6, *sin6_r; + int ipv4_addr_legal, ipv6_addr_legal; + struct socket sockb; + int first; + + if (off == 0) + return; + kread(off, (char *)&epinfo, sizeof(epinfo)); + inp_prev = inp_next = epinfo.listhead.lh_first; + + if (Aflag) + width = 21; + else if (vflag) + width = 45; + else + width = 22; + + printf("Active Stream Conrol Transmission Protocol associations"); + if (aflag) + printf(" (including servers)"); + putchar('\n'); + if (Aflag) + printf("%-8.8s ", "PCB"); + printf("%-5.5s %-6.6s %-6.6s%s %-*.*s %-*.*s %s\n", + "Proto", "Recv-Q", "Send-Q", + Aflag ? "" : " ", + width, width, "Local Address", + width, width, "Foreign Address", "State"); + + if (getifaddrs(&ifap0) < 0) + return; + + memset(&sin_any, 0, sizeof(sin_any)); + sin_any.sin_len = sizeof(sin_any); + sin_any.sin_family = AF_INET; + + while (inp_next != NULL) { + kread((u_long)inp_next, (char *)&inp, sizeof(inp)); + inp_prev = inp_next; + inp_next = inp.sctp_list.le_next; + kread((u_long)inp.sctp_socket, (char *)&sockb, sizeof(sockb)); + + ipv4_addr_legal = ipv6_addr_legal = 0; + if (inp.sctp_flags & SCTP_PCB_FLAGS_BOUND_V6) { + ipv6_addr_legal = 1; + if ( +#if defined(__OpenBSD__) + (0) /* we always do dual bind */ +#elif defined (__NetBSD__) + (((struct in6pcb *)&inp)->in6p_flags & IN6P_IPV6_V6ONLY) +#else + (((struct in6pcb *)&inp)->inp_flags & IN6P_IPV6_V6ONLY) +#endif + == 0) { + ipv4_addr_legal = 1; + } + } else { + ipv4_addr_legal = 1; + } + + if (aflag && (inp.sctp_flags & SCTP_PCB_FLAGS_ACCEPTING)) { + if ((inp.sctp_flags & SCTP_PCB_FLAGS_BOUNDALL)) { + ifap = ifap0; + laddr_next = NULL; + } else { + ifap = NULL; + laddr_next = inp.sctp_addr_list.lh_first; + } + first = 1; + while (ifap != NULL || laddr_next != NULL) { + sin = NULL; + sin6 = NULL; + if (ifap != NULL) { + while (ifap != NULL) { + if (ifap->ifa_addr->sa_family == AF_INET && + ipv4_addr_legal) { + sin = (struct sockaddr_in *)ifap->ifa_addr; + break; + } else if (ifap->ifa_addr->sa_family == AF_INET6 && + ipv6_addr_legal) { + sin6 = (struct sockaddr_in6 *)ifap->ifa_addr; + break; + } + ifap = ifap->ifa_next; + } + if (ifap != NULL) + ifap = ifap->ifa_next; + } else if (laddr_next != NULL) { + do { + kread((u_long)laddr_next, (char *)&laddr, + sizeof(laddr)); + laddr_next = laddr.sctp_nxt_addr.le_next; + if (laddr.ifa == NULL) + break; + kread((u_long)laddr.ifa, (char *)&ifa, + sizeof(ifa)); + if (ifa.ifa_addr == NULL) + break; + kread((u_long)ifa.ifa_addr, (char *)&ss, + sizeof(struct sockaddr)); + ss_len = ss.ss_len; + kread((u_long)ifa.ifa_addr, (char *)&ss, + ss_len); + if (ss.ss_family == AF_INET) { + sin = (struct sockaddr_in *)&ss; + } else if (ss.ss_family == AF_INET6) { + sin6 = (struct sockaddr_in6 *)&ss; + } + } while (0); + } + if (sin == NULL && sin6 == NULL) + continue; + if (first) { + if (Aflag) + printf("%8lx ", (u_long)inp_prev); + printf("%-5.5s %6ld %6ld%s ", name, sockb.so_rcv.sb_cc, + sockb.so_snd.sb_cc, Aflag ? "" : " "); + } else { + if (Aflag) + printf("%29s"," "); + else + printf("%21s"," "); + } + + if (sin != NULL) { + inet46print((struct sockaddr *)sin, + inp.sctp_lport, numeric_port); + } else if (sin6 != NULL) { + inet46print((struct sockaddr *)sin6, + inp.sctp_lport, numeric_port); + } + { + inet46print((struct sockaddr *)&sin_any, + 0, numeric_port); + } + if (first) { + printf("%s", "LISTEN"); + first = 0; + } + putchar('\n'); + } + } + + tcb_next = inp.sctp_asoc_list.lh_first; + while (tcb_next != NULL) { + kread((u_long)tcb_next, (char *)&tcb, sizeof(tcb)); + tcb_prev = tcb_next; + tcb_next = tcb.sctp_tcblist.le_next; + nets_next = tcb.asoc.nets.tqh_first; + if ((inp.sctp_flags & SCTP_PCB_FLAGS_BOUNDALL)) { + ifap = ifap0; + laddr_next = NULL; + } else { + ifap = NULL; + laddr_next = inp.sctp_addr_list.lh_first; + } + + first = 1; + while (ifap != NULL || + laddr_next != NULL || + nets_next != NULL) { + sin = sin_r = NULL; + sin6 = sin6_r = NULL; + + if (ifap != NULL) { + while (ifap != NULL) { + if (ifap->ifa_addr->sa_family == AF_INET && + ipv4_addr_legal) { + sin = (struct sockaddr_in *)ifap->ifa_addr; + break; + } else if (ifap->ifa_addr->sa_family == AF_INET6 && + ipv6_addr_legal) { + sin6 = (struct sockaddr_in6 *)ifap->ifa_addr; + break; + } + ifap = ifap->ifa_next; + } + if (ifap != NULL) + ifap = ifap->ifa_next; + } else if (laddr_next != NULL) { + do { + kread((u_long)laddr_next, (char *)&laddr, + sizeof(laddr)); + laddr_next = laddr.sctp_nxt_addr.le_next; + if (laddr.ifa == NULL) + break; + kread((u_long)laddr.ifa, (char *)&ifa, + sizeof(ifa)); + if (ifa.ifa_addr == NULL) + break; + kread((u_long)ifa.ifa_addr, (char *)&ss, + sizeof(struct sockaddr)); + ss_len = ss.ss_len; + kread((u_long)ifa.ifa_addr, (char *)&ss, + ss_len); + if (ss.ss_family == AF_INET) { + sin = (struct sockaddr_in *)&ss; + } else if (ss.ss_family == AF_INET6) { + sin6 = (struct sockaddr_in6 *)&ss; + } + } while (0); + } + + if (nets_next != NULL) { + kread((u_long)nets_next, (char *)&nets, + sizeof(nets)); + nets_next = nets.sctp_next.tqe_next; + sa = (struct sockaddr *)&nets.ra._l_addr; + if (sa->sa_family == AF_INET) { + sin_r = (struct sockaddr_in *)sa; + } else if (sa->sa_family == AF_INET6) { + sin6_r = (struct sockaddr_in6 *)sa; + } + } + + if (sin == NULL && sin6 == NULL && + sin_r == NULL && sin6_r == NULL) + continue; + if (first) { + if (Aflag) + printf("%8lx ", (u_long)inp_prev); + printf("%-5.5s %6ld %6ld%s ", name, sockb.so_rcv.sb_cc, + sockb.so_snd.sb_cc, Aflag ? "" : " "); + } else { + if (Aflag) + printf("%29s"," "); + else + printf("%21s", " "); + } + + if (sin != NULL) { + inet46print((struct sockaddr *)sin, + inp.sctp_lport, numeric_port); + } else if (sin6 != NULL) { + inet46print((struct sockaddr *)sin6, + inp.sctp_lport, numeric_port); + } else { + printf("N/A%*s", width - 3 + 1, " "); +#if 0 + inet46print((struct sockaddr *)&sin_any, + 0, numeric_port); +#endif + } + if (sin_r != NULL) { + inet46print((struct sockaddr *)sin_r, + tcb.rport, numeric_port); + } else if (sin6_r != NULL) { + inet46print((struct sockaddr *)sin6_r, + tcb.rport, numeric_port); + } else { + printf("N/A%*s", width - 3 + 1, " "); +#if 0 + inet46print((struct sockaddr *)&sin_any, + 0, numeric_port); +#endif + } + if (first) { + switch (tcb.asoc.state) { + case SCTP_STATE_COOKIE_WAIT: + printf("COOKIE_WAIT"); + break; + case SCTP_STATE_COOKIE_ECHOED: + printf("COOKIE_ECHOED"); + break; + case SCTP_STATE_OPEN: + printf("ESTABLISHED"); + break; + case SCTP_STATE_SHUTDOWN_SENT: + printf("SHUTDOWN-SENT"); + break; + case SCTP_STATE_SHUTDOWN_RECEIVED: + printf("SHUTDOWN-RECEIVED"); + break; + case SCTP_STATE_SHUTDOWN_ACK_SENT: + printf("SHUTDOWN-ACK-SENT"); + break; + case SCTP_STATE_SHUTDOWN_PENDING: + printf("SHUTDOWN-PENDING"); + break; + case SCTP_STATE_EMPTY: + case SCTP_STATE_INUSE: + case SCTP_STATE_CLOSED_SOCKET: + default: + printf("CLOSED"); + break; + } + first = 0; + } + putchar('\n'); + } + } + } + freeifaddrs(ifap0); +} + +void +inet46print(sa, port, numeric) + struct sockaddr *sa; + u_int16_t port; + int numeric; +{ + struct sockaddr_in sin; + struct sockaddr_in6 sin6; + u_int16_t scope_id; + char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV]; + int flags = 0; + int n, addrwidth; + + addrwidth = width - 6; + + if (sa->sa_family == AF_INET) { + sin = *(struct sockaddr_in *)sa; + sin.sin_port = port; + sa = (struct sockaddr *)&sin; + } else if (sa->sa_family == AF_INET6) { + sin6 = *(struct sockaddr_in6 *)sa; + if (IN6_IS_ADDR_LINKLOCAL(&sin6.sin6_addr) || + IN6_IS_ADDR_MC_LINKLOCAL(&sin6.sin6_addr)) { + bcopy(&sin6.sin6_addr.s6_addr[2], &scope_id, + sizeof(u_int16_t)); + sin6.sin6_scope_id = ntohs(scope_id); + sin6.sin6_addr.s6_addr[2] = 0; + sin6.sin6_addr.s6_addr[3] = 0; + } + sin6.sin6_port = port; + sa = (struct sockaddr *)&sin6; + } else + return; + + if (numeric) + flags |= NI_NUMERICHOST | NI_NUMERICSERV; + + if (getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), + sbuf, sizeof(sbuf), flags)) { + printf("%*s ", width, "???"); + return; + } + if ((sa->sa_family == AF_INET && + sin.sin_addr.s_addr == INADDR_ANY) || + (sa->sa_family == AF_INET6 && + IN6_IS_ADDR_UNSPECIFIED(&sin6.sin6_addr))) + n = printf("%.*s.", addrwidth, "*"); + else + n = printf("%.*s.", addrwidth, hbuf); + + if (port == 0) + n += printf("%5-5s ", "*"); + else + n += printf("%5-5s ", sbuf); + + if (n < width) + printf("%*s", width - n + 1, " "); +} +#endif /* SCTP */ ------------=_1069451637-22070-0-- From crodrigu@bbn.com Mon Nov 24 14:48:49 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 OAA23851 for ; Mon, 24 Nov 2003 14:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMhi-0003Es-00 for sctp-impl-archive@ietf.org; Mon, 24 Nov 2003 14:49:02 -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 1AOMhh-0003EF-00 for sctp-impl-archive@ietf.org; Mon, 24 Nov 2003 14:49:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2003 11:49:53 +0000 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAOJlsjq005589; Mon, 24 Nov 2003 11:47:54 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id hAOJl9Ks016552 for sctp-impl-filtered; Mon, 24 Nov 2003 11:47:11 -0800 (PST) Message-Id: <200311241947.hAOJl9Ks016552@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1069703229-16550-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: UNIX Network Programming, 3rd: SCTP chapter List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Craig Rodrigues X-Nails-Approved: crodrigu@bbn.com Date: Mon, 24 Nov 2003 14:40:14 -0500 This is a multi-part message in MIME format... ------------=_1069703229-16550-0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: binary Hi, I was just surfing through my local bookstore, and noticed that a 3rd edition of the classic book UNIX Network Programming. Bill Fenner and Andrew Rudoff are new co-authors. Of relevance to this mailing list: there are a few chapters on programming sockets for SCTP. http://www.awprofessional.com/isapi/product_id~{F765FE89-50B3-4CEF-B315-8F9B748A7511}/selectDescTypeId~{06B328CA-921B-4395-945D-3078CA6F292A}/st~5130B593-BAEC-49C6-B6A8-0035DFD1EA3B/session_id~{44893953-E5A4-45EB-8544-06BDA0A53EB8}/catalog/product.asp -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA ------------=_1069703229-16550-0--