From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 1 00:30:07 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06981 for ; Tue, 1 Oct 2002 00:30:07 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g914M9ot026950 for ; Mon, 30 Sep 2002 21:22:09 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g914M9jC025948 for ; Mon, 30 Sep 2002 21:22:09 -0700 (PDT) Received: from webmail10.rediffmail.com (webmail10.rediffmail.com [202.54.124.179] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g914L43R026888 for ; Mon, 30 Sep 2002 21:21:06 -0700 (PDT) Received: (qmail 15536 invoked by uid 510); 1 Oct 2002 04:21:43 -0000 Date: 1 Oct 2002 04:21:43 -0000 Message-ID: <20021001042143.15535.qmail@webmail10.rediffmail.com> Received: from unknown (202.141.64.109) by rediffmail.com via HTTP; 01 oct 2002 04:21:43 -0000 MIME-Version: 1.0 From: "Abha Singh Bais" Reply-To: "Abha Singh Bais" To: sctp-impl@external.cisco.com Subject: SCTP prospects Content-type: text/plain; format=flowed Content-Disposition: inline hello.., We are new to this group,and hope to learn as much as we can about SCTP. We desire to do a 1-year long project in SCTP. We have still to decide the specific aspect of SCTP we want to focus on. Wishing to pursue further studies in the same field down the line, we have been trying hard to narrow down to one aspect and tht's where we require this group's help.. Two ideas we had in mind-- 1)comparing the performance of SCTP and TCP (but much work has already been done in that) analyzing the performance of SCTP on Ad-Hoc Networks we can take in as many suggestions as possible over this.., thanks a lot.., abha and nitin. PS:- we did get one suggestion through personal mailing-- implementing http over sctp.wht say??? From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 1 08:50:27 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12920 for ; Tue, 1 Oct 2002 08:50:26 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g91Chaot002077; Tue, 1 Oct 2002 05:43:36 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAF30159; Tue, 1 Oct 2002 05:43:34 -0700 (PDT) Message-ID: <3D999875.9000906@cisco.com> Date: Tue, 01 Oct 2002 07:43:33 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abha Singh Bais CC: sctp-impl@external.cisco.com Subject: Re: SCTP prospects References: <20021001042143.15535.qmail@webmail10.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Abha Singh Bais wrote: > hello.., > We are new to this group,and hope to learn as much as we > can about SCTP. We desire to do a 1-year long project in SCTP. > We have still to decide the specific aspect of SCTP we > want to focus on. Wishing to pursue further studies in the same > field down the line, we have been trying hard to narrow down to > one aspect and tht's where we require this group's help.. > Two ideas we had in mind-- > 1)comparing the performance of SCTP and TCP (but much work has > already been done in that) > analyzing the performance of SCTP on Ad-Hoc Networks > we can take in as many suggestions as possible over this.., > thanks a lot.., > abha and nitin. > PS:- we did get one suggestion through personal mailing-- > implementing http over sctp.wht say??? > > > > Abha: I think I have already responded to you in a personel email (not the one you mention I think) but I do want to address your last comment. Peter Lei and myself DID get apache2 and mozilla running on SCTP (as well as ftpd/ftp ssh/sshd), we plan on releasing the code (a snapshot of both mozilla and apache2 that will run SCTP) as soon as I can get some cycles to do it :-0 And I will even leave up my web server running on one of my boxes that is on the open Big-I so that if you download mozilla you can hit via SCTP a copy of the sctp web site :> But ... like I said... I need some cylces first :-0 R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 1 10:18:01 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18899 for ; Tue, 1 Oct 2002 10:18:00 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g91EC8ot021963; Tue, 1 Oct 2002 07:12:08 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g91EC70n021943; Tue, 1 Oct 2002 07:12:07 -0700 (PDT) Received: from armail01la.mail2world.com (mw183.mail2world.com [66.28.189.183]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g91EC3ao023478; Tue, 1 Oct 2002 07:12:03 -0700 (PDT) Received: from arweb07la (unverified [10.1.201.112]) by armail01la.mail2world.com (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 1 Oct 2002 07:09:49 -0700 thread-index: AcJpVDRABAVWYVBJR1CLx8867uQ/eQ== Thread-Topic: Business Proposal. From: "Cecele Mobutu Sesekou" To: Subject: Business Proposal. Date: Tue, 1 Oct 2002 07:09:49 -0700 Message-ID: <02a201c26954$3442fd50$70c9010a@mail2world.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A3_01C26919.87E42550" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_02A3_01C26919.87E42550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Friend, I am Samuel Cecele Mobutu Sese Sekou,son of the late president Mobutu Sese Sekou of the Congo Democratic Republic(former Republic of Zaire). There was unrest (war) in my country which resulted in the overthrow and eventual of my father President Mobutu Sese Sekou.My family members have since escaped to Morocco while i am presently in Nigeria(West Africa) on political asylum. Due to the political crisis,no member of my family can go back to the Congo Democratic Republic or transact any business investment there,also my fathers properties have been seized and accounts frozen by the Government of Lawrent Joseph Kabila. Before my father died ,he deposited the sum of $48.5million(USD)in a secuity vault in Europe.If you can assist my family.Please we need your assistance in moving and securing this money in your bank account abroad,my family will compensate you adequately with 20% of the total amount for your assistance and co operation. My family will want to invest this money abroad,and for this reason, i sincerely appeal to you to help us in setting up this business. Please you can contact me via email. May i also stae that you please advice on areas of investment as regards your business and your country as the families foreign partner. I look forward to further co-operation from you and will be grateful for your immediate response. Please Reply Back On :c_mobutuus@juno.com yours sincerely, Samuel.C.Mobutu Sese Sekou ------=_NextPart_000_02A3_01C26919.87E42550 Content-Type: text/html Content-Transfer-Encoding: 7bit

Dear Friend,
I am Samuel Cecele Mobutu Sese Sekou,son of the
late president Mobutu Sese Sekou of the Congo
Democratic Republic(former Republic of Zaire).
There was unrest (war) in my country which resulted
in the overthrow and eventual of my father President
Mobutu Sese Sekou.My family members have since escaped
to Morocco while i am presently in Nigeria(West Africa) on
political asylum.
Due to the political crisis,no member of my family
can go back to the Congo Democratic Republic or
transact any business investment there,also my fathers
properties have been seized and accounts frozen by the
Government of Lawrent Joseph Kabila.
Before my father died ,he deposited the sum of
$48.5million(USD)in a secuity vault in Europe.If
you can assist my family.Please we need your
assistance in moving and securing this money in your
bank account abroad,my family will compensate you
adequately with 20% of the total amount for your
assistance and co operation.
My family will want to invest this money abroad,and
for this reason, i sincerely appeal to you to help us
in setting up this business.
Please you can contact me via email.
May i also stae that you please advice on areas of
investment as regards your business and your country
as the families foreign partner.
I look forward to further co-operation from you and
will be grateful for your immediate response.
Please Reply Back On :c_mobutuus@juno.com


yours sincerely,

Samuel.C.Mobutu Sese Sekou



------=_NextPart_000_02A3_01C26919.87E42550-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 1 12:45:17 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26266 for ; Tue, 1 Oct 2002 12:45:15 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g91GdNot005103 for ; Tue, 1 Oct 2002 09:39:23 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g91GdMaC019521 for ; Tue, 1 Oct 2002 09:39:22 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g91GdHoJ002615 for ; Tue, 1 Oct 2002 09:39:19 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g91GQBH17184; Tue, 1 Oct 2002 11:26:12 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D99CCA3.9060104@stewart.chicago.il.us> Date: Tue, 01 Oct 2002 11:26:11 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com CC: TSV WG list Subject: Some SCTP code of interest Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: Ok I finally found a few cycles to get the apache2/mozilla hacks I put together where they could be downloaded. If you go to http://www.sctp.org and have a FreeBSD4.6 system with our kame-sctp version enabled (you can get it from http://www.kame.net) You can download these two packages apache2.tar.gz and/or mozilla.tar.gz and then compile and build them... they are pre-configured for FreeBSD 4.6 (and patched too). Once you do this you will have a httpd server and a mozilla browser that will ONLY do SCTP :-) I do have an IP address I can give folks (ask me offline in a email) that has a apache2 SCTP server running on it with a clone of the sctp.org web page... in case you want to check out http over SCTP on the Big I :-> Best regards R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 3 20:29:16 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09288 for ; Thu, 3 Oct 2002 20:29:15 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g940RsIm006545 for ; Thu, 3 Oct 2002 17:27:54 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g940Rrnh005261 for ; Thu, 3 Oct 2002 17:27:53 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g940Rmao016939 for ; Thu, 3 Oct 2002 17:27:49 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g940CFH22816; Thu, 3 Oct 2002 19:12:16 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D9CDCDF.3080906@stewart.chicago.il.us> Date: Thu, 03 Oct 2002 19:12:15 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kavithab@austin.ibm.com CC: bidulock@openss7.org, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <3D9C861C.57543D00@austin.ibm.com> <20021003145122.D22418@openss7.org> <3D9CB530.17DCEB97@austin.ibm.com> <3D9CBE38.5020300@stewart.chicago.il.us> <3D9CC618.BA05E0D4@austin.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Kavitha: I think we now leave the "making something explcit in a draft" and move in to implementation details for me to discuss this.. I am copying sctp-impl and will respond removing tsvwg... I think it is best we move it there.. If there are no further objections next pass of the sockets api will specify we must be sure to move the data.. I will answer you tommorrow A.M. and see if I can't confuse you more :> R Kavitha Baratakke wrote: > Randall Stewart wrote: > >>Kavitha Baratakke wrote: >> >>>Brian, >>> >>>That was just one case where we do a partial read before a peeloff... >>>Randy's example of where peel_off occurs after a partial read (partial >>>delivery) and we need to move the rest of the data to the new socket >>>buffer... >>> >> >>Kavitha: I was NOT talking about the partial delivery api.. that is >>different than when a user does a partial read... >> >>The partial delivery api is when the sctp stack itself sends up >>only part of the message .. that is different than the socket buffer >>holding the whole message and the app reading only a couple of bytes... >> >> >>>... sure we could make it mandatory that peeloff occurs before any >>>reads...although handling it otherwise is really not that complicated... >>> >> > Randall, how is partial delivery api different from user doing a partial > read as far as how we need to handle it goes. We still need to keep > track of which assoc the partial message belongs to in either case > right? > > I'm confused ??? > > >>As long as you don't mind having sctp specifics in your sockets >>layer... of course Kacheong feels it is part of the sockets layer >>so then there is no problem :> >> >>>But the original source of this discussion was that if data is lying in >>>the socket buffer for the assocation that is peeled off, we still have >>>to move it to the new socket buffer after peeloff... >>> >> >>correct. >> >>and I think that should be stated in the socket draft at minimum. >> >>R >> > > >>>>Is it not simple to just require that the peel_off occur >>>>before any reads on the association being peeled off? >>> > >>>>--brian >>>> >>>>-- >>>>Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ >>>>bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ >>>>http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ >>>> ¦ Therefore all progress depends on the ¦ >>>> ¦ unreasonable man. -- George Bernard Shaw ¦ >>> >>> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 3 20:37:13 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09587 for ; Thu, 3 Oct 2002 20:37:12 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g940VbaW012947 for ; Thu, 3 Oct 2002 17:31:37 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g940VhW3003156 for ; Thu, 3 Oct 2002 17:31:44 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g940Vf87019728 for ; Thu, 3 Oct 2002 17:31:42 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g940GLH22831; Thu, 3 Oct 2002 19:16:21 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D9CDDD5.9080704@stewart.chicago.il.us> Date: Thu, 03 Oct 2002 19:16:21 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Venkat: This seems supicious.. If you do a recvmsg() and then do a subsequent recvmsg() you don't necessarily get the address and control info again... Not until the EOR is set... R venkat venkatsubra wrote: > venkat venkatsubra wrote: > > >>Randall, >> >> >>>--__--__-- >>> >>>Message: 10 >>>Date: Wed, 02 Oct 2002 19:45:25 -0500 >>>From: Randall Stewart >>>To: venkat venkatsubra >>>CC: tsvwg@ietf.org, jgrimm2@us.ibm.com >>>Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about >>> >>> >>>So how do you tell which association goes with which data... do you >>>keep back pointers and such? If you use a mbuf like structure do >>>you have EVERY chained mbuf assured of having this information.. >> >>We attach a sctp_sndrcvinfo structure with each message >>in the socket buffer. We made this a mbuf type of MT_CONTROL. >>And the notification stuffs (SHUTDOWN, ASSOC_CHANGE, etc.) >>we keep it as a MT_SONAME mbuf type. >>So, getting the assoc_id and moving the messages or >>notifications of a particular assoc_id is not an issue. >>As Kacheong had pointed out you need it anyway >>to pass to recvmsg. >> >> >>>It is also possible to read 100 bytes (of a 1000 byte message) and then >>>do the peel off... in the case of a BSD system this may well loose the >>>M_PKTHDR (which is where any back pointers could possibly be kept) and >>>thus you would have data left on the socket with no way to tell >>>which association went with that data for the partially read message... >> >>To support partial delivery api we insert the >>"control" structure back again at the head >>of the message after the user does a partial read. >> >> >>> >>>R >>> >>> >>>>>R >>>>> >>>>>-- >>>>>Randall R. Stewart >>>>>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >>>> >>Venkat > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 01:07:40 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14028 for ; Fri, 4 Oct 2002 01:07:39 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9455Iot029251 for ; Thu, 3 Oct 2002 22:05:18 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9455In0026621 for ; Thu, 3 Oct 2002 22:05:18 -0700 (PDT) Received: from txsmtp01.texas.rr.com (smtp1.texas.rr.com [24.93.36.229]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9455Eao027338 for ; Thu, 3 Oct 2002 22:05:14 -0700 (PDT) Received: from us.ibm.com (cs242715-27.austin.rr.com [24.27.15.27]) by txsmtp01.texas.rr.com (8.12.5/8.12.2) with ESMTP id g9452tss026433; Fri, 4 Oct 2002 01:02:55 -0400 (EDT) Message-ID: <3D9D2149.3000004@us.ibm.com> Date: Fri, 04 Oct 2002 00:04:09 -0500 From: Jon Grimm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart CC: venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy, Randall Stewart wrote: > Venkat: > > This seems supicious.. > > If you do a recvmsg() and then do a subsequent recvmsg() you > don't necessarily get the address and control info again... > Not until the EOR is set... > Why do you say this? Why not? I don't recall anything in the I-D calling out this behavior for subsequent reads. I interpreted this as Venkat and Kavitha did and assume that every message would have msg_name (address) and/or CMSG data, even if only reading a subportion (MSG_EOR not set) of the message. It may be redundant information (as it will not change), but I can't see a good reason that the application shouldn't be able to get that information either. Hmmm.. what happens on your TCP-style impl. What happens on recvmsg/recvfrom? (Assuming not from the primary address) do you fill in msg_name for every read even when it takes a consequent read(s) to pull up the rest of the message? Which, in turn, reminds me to ask another dumb question, why the wording about the primary address? For example section 4.1.8: "When receiving, if a message is not received from the primary address, the SCTP stack will fill in the msg_name field on return so that the application can retrieve the source address information of the received message." This seems rather an odd exclusion; the primary address may never even be the address that the peer sources the message from (assuming multihoming of course.) Why have different behavior to just confuse the application writer? I'd suggest filling in msg_name whether its the primary or not. Maybe another question to ask is whether SOCK_STREAM server applications (multiple sockets) would expect to the msg_name to always be filled in when they request it? I'm pretty sure Linux SOCK_STREAM/TCP will do so at least. Best Regards, Jon From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Oct 4 06:50:27 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28047 for ; Fri, 4 Oct 2002 06:50:26 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94AdAIm017243; Fri, 4 Oct 2002 03:39:10 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG33960; Fri, 4 Oct 2002 03:39:08 -0700 (PDT) Message-ID: <3D9D6FCB.7060108@cisco.com> Date: Fri, 04 Oct 2002 05:39:07 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Grimm CC: Randall Stewart , venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Grimm wrote: > Hi Randy, > > Randall Stewart wrote: > >> Venkat: >> >> This seems supicious.. >> >> If you do a recvmsg() and then do a subsequent recvmsg() you >> don't necessarily get the address and control info again... >> Not until the EOR is set... >> > > Why do you say this? Why not? I don't recall anything in the I-D > calling out this behavior for subsequent reads. I interpreted this as > Venkat and Kavitha did and assume that every message would > have msg_name (address) and/or CMSG data, even if only > reading a subportion (MSG_EOR not set) of the message. I have thought about this and here is the reason I think it is bad Lets say I am using recvfrom instead of recvmsg() In this case I get no MSG_EOR.. I can't see it... I realize this is unwise ... but many application implementors are not going to go the extra mile to learn recvmsg... the folks coming from UDP land WILL know recvfrom though... Now if I get a message with a sockaddr filled in... I know it is the beginning of a message... If the next read has NO sockaddr... guess what I can determine that its a continuation of the previous message... up until I read a subsequent message with a sockaddr setup.. maybe to the same guy maybe different.. But if you do this copy.. you have taken away the only indication I have that this is a second part of a message... > > It may be redundant information (as it will not change), but I can't > see a good reason that the application shouldn't be able to get > that information either. Just the opposite.. you are losing information.. record boundaries.. > > > Hmmm.. what happens on your TCP-style impl. What happens on > recvmsg/recvfrom? (Assuming not from the primary address) do you fill > in msg_name for every read even when it takes a consequent read(s) to > pull up the rest of the message? Good question.. I would hope to see it with an address to mark the beginning of a record and no addresses to mark subsequent parts of the same message.. that way the TCP style would ALSO get some sort of indication where the record boundaries are... > > > Which, in turn, reminds me to ask another dumb question, why the wording > about the primary address? For example section 4.1.8: > > "When receiving, if a message is not received from the primary > address, the SCTP stack will fill in the msg_name field on return so > that the application can retrieve the source address information of > the received message." I agree.. not sure where it came from :-0 > > This seems rather an odd exclusion; the primary address may never even > be the address that the peer sources the message from (assuming > multihoming of course.) Why have different behavior to just confuse > the application writer? I'd suggest filling in msg_name whether its > the primary or not. I think that paragraph should be killed.. don't know why it is there... > > Maybe another question to ask is whether SOCK_STREAM server applications > (multiple sockets) would expect to the msg_name to always be filled in > when they request it? I'm pretty sure Linux SOCK_STREAM/TCP will do > so at least. > > That would surprise me.. most BSD implementations do NOT give you a sockaddr at ALL in sock_stream mode.. on the theory that during the accept you got the address and now you can equate the socket-descriptor to the address... But I do think more wording is in order ... 1) to specify that the address can be used as a message delinator (and lack of ... as I state above) 2) recomend that it be done in the TCP style too 3) get rid of that stray paragraph :> R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 07:25:16 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28632 for ; Fri, 4 Oct 2002 07:25:15 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g94BNxot027719; Fri, 4 Oct 2002 04:23:59 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG34345; Fri, 4 Oct 2002 04:23:58 -0700 (PDT) Message-ID: <3D9D7A4D.7000704@cisco.com> Date: Fri, 04 Oct 2002 06:23:57 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kavithab@austin.ibm.com CC: sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <3D9C861C.57543D00@austin.ibm.com> <20021003145122.D22418@openss7.org> <3D9CB530.17DCEB97@austin.ibm.com> <3D9CBE38.5020300@stewart.chicago.il.us> <3D9CC618.BA05E0D4@austin.ibm.com> <3D9CDCDF.3080906@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > Kavitha Baratakke wrote: > >>> >> Randall, how is partial delivery api different from user doing a partial >> read as far as how we need to handle it goes. We still need to keep >> track of which assoc the partial message belongs to in either case >> right? >> >> I'm confused ??? >> >> Ok let me try to confuse you more... Conceptually there is a large difference between the partial delivery API and a user only reading part of a message. The PD-API MUST be implemented in SCTP ... this is where I start to send up the socket buffer a incomplete message to try to cut down on my resource utilization. I let my upper layer read off the first part that as arrived. A user only reading part of a message DOES NOT depend on SCTP doing anything. I realize this is really splitting hairs.... but lets take for example a SCTP implementation that DOES NOT EVER do the PD-API... it always sends up complete messages (some may well do this). Now in our mythical implementation it may send up a 4k message... the message is pushed up the socket buffer... the user reads 1 byte... The result from the user perspective is much like the PD-API.. even though the SCTP implementation does NOT support it and does not do it.. Thats why I say the issue as nothing to do with the SCTP PD-API.. maybe the way the sockets layer API for partial delivery might work.. but not SCTP.. R > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Oct 4 09:09:28 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02440 for ; Fri, 4 Oct 2002 09:09:27 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g94D7oaW018700 for ; Fri, 4 Oct 2002 06:07:50 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g94D7vqv000493 for ; Fri, 4 Oct 2002 06:07:57 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-33-191.client.attbi.com [12.249.33.191]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g94D7t87027312 for ; Fri, 4 Oct 2002 06:07:56 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g94CJFP09293; Fri, 4 Oct 2002 07:19:16 -0500 Message-Id: <200210041219.g94CJFP09293@baqaqi.chi.il.us> To: "Randall Stewart (cisco)" cc: Jon Grimm , Randall Stewart , venkat venkatsubra s , sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about In-reply-to: Your message of Fri, 04 Oct 2002 05:39:07 -0500. <3D9D6FCB.7060108@cisco.com> Date: Fri, 04 Oct 2002 07:19:14 -0500 Sender: piggy@baqaqi.chi.il.us On Fri, 04 Oct 2002 05:39:07 -0500, "Randall Stewart (cisco)" w rote: > Jon Grimm wrote: > > Which, in turn, reminds me to ask another dumb question, why the wording > > about the primary address? For example section 4.1.8: > > > > "When receiving, if a message is not received from the primary > > address, the SCTP stack will fill in the msg_name field on return so > > that the application can retrieve the source address information of > > the received message." > > I agree.. not sure where it came from :-0 > > > This seems rather an odd exclusion; the primary address may never even > > be the address that the peer sources the message from (assuming > > multihoming of course.) Why have different behavior to just confuse > > the application writer? I'd suggest filling in msg_name whether its > > the primary or not. > > > I think that paragraph should be killed.. don't know why it is there... This is my fault--I should have removed it when I put in assoc_id. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Oct 4 10:01:06 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04363 for ; Fri, 4 Oct 2002 10:01:05 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94Dt3Im017005 for ; Fri, 4 Oct 2002 06:55:03 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94Dt2B2023009 for ; Fri, 4 Oct 2002 06:55:02 -0700 (PDT) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g94Dsmao027543 for ; Fri, 4 Oct 2002 06:54:59 -0700 (PDT) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA20518; Fri, 4 Oct 2002 08:46:31 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA45322; Fri, 4 Oct 2002 08:48:21 -0500 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA09388; Fri, 4 Oct 2002 08:48:21 -0500 Sender: root@popmail.austin.ibm.com Message-ID: <3D9D9754.2BC681DC@us.ibm.com> Date: Fri, 04 Oct 2002 08:27:48 -0500 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.40 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Randall Stewart , venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> <3D9D6FCB.7060108@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Randall Stewart (cisco)" wrote: > > Jon Grimm wrote: > > > Hi Randy, > > > > Randall Stewart wrote: > > > >> Venkat: > >> > >> This seems supicious.. > >> > >> If you do a recvmsg() and then do a subsequent recvmsg() you > >> don't necessarily get the address and control info again... > >> Not until the EOR is set... > >> > > > > Why do you say this? Why not? I don't recall anything in the I-D > > calling out this behavior for subsequent reads. I interpreted this as > > Venkat and Kavitha did and assume that every message would > > have msg_name (address) and/or CMSG data, even if only > > reading a subportion (MSG_EOR not set) of the message. > > I have thought about this and here is the reason I think it is bad > > Lets say I am using recvfrom instead of recvmsg() > > In this case I get no MSG_EOR.. I can't see it... I realize this is > unwise ... but many > application implementors are not going to go the extra mile to learn > recvmsg... the folks > coming from UDP land WILL know recvfrom though... > > Now if I get a message with a sockaddr filled in... I know it is the > beginning of a > message... > > If the next read has NO sockaddr... guess what I can determine that its > a continuation > of the previous message... up until I read a subsequent message with a > sockaddr setup.. maybe > to the same guy maybe different.. > > But if you do this copy.. you have taken away the only indication I have > that this is > a second part of a message... > > > > > It may be redundant information (as it will not change), but I can't > > see a good reason that the application shouldn't be able to get > > that information either. > > Just the opposite.. you are losing information.. record boundaries.. > > > > > > > Hmmm.. what happens on your TCP-style impl. What happens on > > recvmsg/recvfrom? (Assuming not from the primary address) do you fill > > in msg_name for every read even when it takes a consequent read(s) to > > pull up the rest of the message? > > Good question.. I would hope to see it with an address to mark the beginning > of a record and no addresses to mark subsequent parts of the same > message.. that way > the TCP style would ALSO get some sort of indication where the record > boundaries > are... > A couple comments: 1) If TCP style apps care about msg boundary they should use recvmsg, looking at msg_name isn't natural for them either. Using it as a poor man's MSG_EOR seems a little hackish. 2) How about UDP-style applications, above you talk that UDP applications (which I will admit right now that UDP != UDP-style but there was some attempt at similarity) know how to use recvfrom: Will they be expecting msg_name at all times? 3) Depending on ones perspective, is it also interesting to ask what a (non-SCTP) SOCK_SEQPACKET does? Looking at the Linux DECNET code, they'll fill it msg_name in on every subread of a record. I don't have POSIX docs handy to check there. > > > > > > Which, in turn, reminds me to ask another dumb question, why the wording > > about the primary address? For example section 4.1.8: > > > > "When receiving, if a message is not received from the primary > > address, the SCTP stack will fill in the msg_name field on return so > > that the application can retrieve the source address information of > > the received message." > > I agree.. not sure where it came from :-0 > > > > > This seems rather an odd exclusion; the primary address may never even > > be the address that the peer sources the message from (assuming > > multihoming of course.) Why have different behavior to just confuse > > the application writer? I'd suggest filling in msg_name whether its > > the primary or not. > > I think that paragraph should be killed.. don't know why it is there... > > > > > Maybe another question to ask is whether SOCK_STREAM server applications > > (multiple sockets) would expect to the msg_name to always be filled in > > when they request it? I'm pretty sure Linux SOCK_STREAM/TCP will do > > so at least. > > > > > That would surprise me.. most BSD implementations do NOT give you a > sockaddr at ALL > in sock_stream mode.. on the theory that during the accept you got > the address and now you can equate the socket-descriptor to the > address... > BTW, I double checked and you are correct sock_stream does NOT fill in msg_name. The Linux man page for recvmsg says that: "If from is not NULL, and the socket is not connection-oriented, the source address of the message is filled in." So now thinking in reverse I question if a SOCK_STREAM app will ever use the poor man's MSG_EOR trick at all. In general, I think app. writers will need to use sendmsg/recvmsg if they want to exploit the interesting features of SCTP anyway (well I guess that several sockopts have been introduced that don't make this a _completely_ true statement), to where this trick isn't needed. Thanks, Jon > But I do think more wording is in order ... > > 1) to specify that the address can be used as a message delinator (and > lack of ... as I state above) > 2) recomend that it be done in the TCP style too > 3) get rid of that stray paragraph :> > > R > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 10:50:47 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06515 for ; Fri, 4 Oct 2002 10:50:46 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g94Ej6ot004810 for ; Fri, 4 Oct 2002 07:45:06 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94Ej5TE023297 for ; Fri, 4 Oct 2002 07:45:05 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g94EhvhB015755 for ; Fri, 4 Oct 2002 07:43:58 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g94ETWH24324; Fri, 4 Oct 2002 09:29:32 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D9DA5CB.3020302@stewart.chicago.il.us> Date: Fri, 04 Oct 2002 09:29:31 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Grimm CC: "Randall Stewart (cisco)" , venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> <3D9D6FCB.7060108@cisco.com> <3D9D9754.2BC681DC@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon Grimm wrote: > "Randall Stewart (cisco)" wrote: > >>Jon Grimm wrote: >> >> >>>Hi Randy, >>> >>>Randall Stewart wrote: >>> >>> >>>>Venkat: >>>> >>>>This seems supicious.. >>>> >>>>If you do a recvmsg() and then do a subsequent recvmsg() you >>>>don't necessarily get the address and control info again... >>>>Not until the EOR is set... >>>> >>> >>>Why do you say this? Why not? I don't recall anything in the I-D >>>calling out this behavior for subsequent reads. I interpreted this as >>>Venkat and Kavitha did and assume that every message would >>>have msg_name (address) and/or CMSG data, even if only >>>reading a subportion (MSG_EOR not set) of the message. >> >>I have thought about this and here is the reason I think it is bad >> >>Lets say I am using recvfrom instead of recvmsg() >> >>In this case I get no MSG_EOR.. I can't see it... I realize this is >>unwise ... but many >>application implementors are not going to go the extra mile to learn >>recvmsg... the folks >>coming from UDP land WILL know recvfrom though... >> >>Now if I get a message with a sockaddr filled in... I know it is the >>beginning of a >>message... >> >>If the next read has NO sockaddr... guess what I can determine that its >>a continuation >>of the previous message... up until I read a subsequent message with a >>sockaddr setup.. maybe >>to the same guy maybe different.. >> >>But if you do this copy.. you have taken away the only indication I have >>that this is >>a second part of a message... >> >> >>>It may be redundant information (as it will not change), but I can't >>>see a good reason that the application shouldn't be able to get >>>that information either. >> >>Just the opposite.. you are losing information.. record boundaries.. >> >> >>> >>>Hmmm.. what happens on your TCP-style impl. What happens on >>>recvmsg/recvfrom? (Assuming not from the primary address) do you fill >>>in msg_name for every read even when it takes a consequent read(s) to >>>pull up the rest of the message? >> >>Good question.. I would hope to see it with an address to mark the beginning >>of a record and no addresses to mark subsequent parts of the same >>message.. that way >>the TCP style would ALSO get some sort of indication where the record >>boundaries >>are... >> > > > > > A couple comments: > > 1) If TCP style apps care about msg boundary they should use recvmsg, > looking > at msg_name isn't natural for them either. Using it as a poor man's > MSG_EOR > seems a little hackish. I would not call it hackish.. at least it is a clue > 2) How about UDP-style applications, above you talk that UDP > applications > (which I will admit right now that UDP != UDP-style but there was some > attempt at similarity) know how to use recvfrom: Will they be expecting > msg_name at all times? Well UDP uses PR-ATOMIC symantics. This means that if you don't read it all in one shot you LOOSE the message. If we want to go that route... then the whole issue becomes mute. Qiaobing suggested that... Of course that means large messages just can't be sent (larger > 64k) > 3) Depending on ones perspective, is it also interesting to ask what a > (non-SCTP) SOCK_SEQPACKET does? Looking at the Linux DECNET code, > they'll > fill it msg_name in on every subread of a record. I don't have POSIX > docs > handy to check there. > Hmm... don't know.. I don't think I have seen any SOCK_SEQPACKET in any of the BSD's other than SCTP.... of course I have not looked either. Note that currently there is no way in the sockets layer of BSD to do the add a sockaddr * to every read ... Not without hacking up the soread function .. which is exactly what Venkat did... he added this copy the mbuf with the address back to the mbuf chain if you don't read it all.. That is very difficult to justify to the BSD folks.. doing anything within that layer if a stretch.. Now that being said I think this IS rather NEW and uncharted teritory. i.e. a type of socket that does not use PR_ATOMIC (UDP's choice) and is not all one big record (tcp).. I do like having some hint that this record just read is a continuation from the last read.. and I don't see it has a hack.. After all if nothing else I can use it as a clue that I got a big record.. .and do some exception processing... if I have no clue.. then the app will get two "seperate records" in its view that are one... Not a good thing.. R > > >>> >>>Which, in turn, reminds me to ask another dumb question, why the wording >>>about the primary address? For example section 4.1.8: >>> >>>"When receiving, if a message is not received from the primary >>> address, the SCTP stack will fill in the msg_name field on return so >>> that the application can retrieve the source address information of >>> the received message." >> >>I agree.. not sure where it came from :-0 >> >> >>>This seems rather an odd exclusion; the primary address may never even >>>be the address that the peer sources the message from (assuming >>>multihoming of course.) Why have different behavior to just confuse >>>the application writer? I'd suggest filling in msg_name whether its >>>the primary or not. >> >>I think that paragraph should be killed.. don't know why it is there... >> >> >>>Maybe another question to ask is whether SOCK_STREAM server applications >>>(multiple sockets) would expect to the msg_name to always be filled in >>>when they request it? I'm pretty sure Linux SOCK_STREAM/TCP will do >>>so at least. >>> >>> >> >>That would surprise me.. most BSD implementations do NOT give you a >>sockaddr at ALL >>in sock_stream mode.. on the theory that during the accept you got >>the address and now you can equate the socket-descriptor to the >>address... >> > > > > > BTW, I double checked and you are correct sock_stream does NOT fill in > msg_name. > The Linux man page for recvmsg says that: > > "If from is not NULL, and the socket is not connection-oriented, the > source address of the message is filled in." > > So now thinking in reverse I question if a SOCK_STREAM app will ever use > the poor man's MSG_EOR trick at all. In general, I think app. writers > will need to use sendmsg/recvmsg if they want to exploit the > interesting features of SCTP anyway (well I guess that several sockopts > have been introduced that don't make this a _completely_ true > statement), > to where this trick isn't needed. > > > > Thanks, Jon > > >>But I do think more wording is in order ... >> >>1) to specify that the address can be used as a message delinator (and >>lack of ... as I state above) >>2) recomend that it be done in the TCP style too >>3) get rid of that stray paragraph :> >> >>R >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 11:35:49 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08288 for ; Fri, 4 Oct 2002 11:35:48 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g94FTjot003950 for ; Fri, 4 Oct 2002 08:29:45 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g94FThJs014650 for ; Fri, 4 Oct 2002 08:29:44 -0700 (PDT) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g94FTcao021007 for ; Fri, 4 Oct 2002 08:29:39 -0700 (PDT) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA42486; Fri, 4 Oct 2002 10:15:40 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA36248; Fri, 4 Oct 2002 10:23:17 -0500 Sender: venkats@austin.ibm.com Message-ID: <3D9DB264.D8BD0259@austin.ibm.com> Date: Fri, 04 Oct 2002 10:23:17 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.76iC-CCK-MCD [en_US] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Jon Grimm , Randall Stewart , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> <3D9D6FCB.7060108@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall, "Randall Stewart (cisco)" wrote: > Jon Grimm wrote: > > > Hi Randy, > > > > Randall Stewart wrote: > > > >> Venkat: > >> > >> This seems supicious.. > >> > >> If you do a recvmsg() and then do a subsequent recvmsg() you > >> don't necessarily get the address and control info again... > >> Not until the EOR is set... > >> > > > > Why do you say this? Why not? I don't recall anything in the I-D > > calling out this behavior for subsequent reads. I interpreted this as > > Venkat and Kavitha did and assume that every message would > > have msg_name (address) and/or CMSG data, even if only > > reading a subportion (MSG_EOR not set) of the message. > > I have thought about this and here is the reason I think it is bad > > Lets say I am using recvfrom instead of recvmsg() > > In this case I get no MSG_EOR.. I can't see it... I realize this is > unwise ... but many > application implementors are not going to go the extra mile to learn > recvmsg... the folks > coming from UDP land WILL know recvfrom though... > > Now if I get a message with a sockaddr filled in... I know it is the > beginning of a > message... In case of UDP i thought the remaining portion of the message will be truncated. It won't be returned on a subsequent recvfrom(). In fact, the socket code always expects the first mbuf is a MT_SONAME containing the address. > > > If the next read has NO sockaddr... guess what I can determine that its > a continuation > of the previous message... up until I read a subsequent message with a > sockaddr setup.. maybe > to the same guy maybe different.. I am not sure if the UDP recvfrom works this way currently. In my understanding it truncates the message if the user buffer is smaller. > > > But if you do this copy.. you have taken away the only indication I have > that this is > a second part of a message... I dont't think such an indication exists now (at least in our UDP socket implementation). I can verify. > > > > > > > It may be redundant information (as it will not change), but I can't > > see a good reason that the application shouldn't be able to get > > that information either. > > Just the opposite.. you are losing information.. record boundaries.. > Venkat From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Oct 4 11:41:42 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08592 for ; Fri, 4 Oct 2002 11:41:42 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94FagIm021860 for ; Fri, 4 Oct 2002 08:36:42 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g94FadYY019915 for ; Fri, 4 Oct 2002 08:36:39 -0700 (PDT) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g94FaZao023056 for ; Fri, 4 Oct 2002 08:36:36 -0700 (PDT) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA13118; Fri, 4 Oct 2002 10:22:37 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA45648; Fri, 4 Oct 2002 10:30:14 -0500 Sender: venkats@austin.ibm.com Message-ID: <3D9DB405.3208DD2A@austin.ibm.com> Date: Fri, 04 Oct 2002 10:30:13 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.76iC-CCK-MCD [en_US] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: Randall Stewart CC: Jon Grimm , "Randall Stewart (cisco)" , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> <3D9D6FCB.7060108@cisco.com> <3D9D9754.2BC681DC@us.ibm.com> <3D9DA5CB.3020302@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart wrote: > > 3) Depending on ones perspective, is it also interesting to ask what a > > (non-SCTP) SOCK_SEQPACKET does? Looking at the Linux DECNET code, > > they'll > > fill it msg_name in on every subread of a record. I don't have POSIX > > docs > > handy to check there. > > > > Hmm... don't know.. I don't think I have seen any SOCK_SEQPACKET in > any of the BSD's other than SCTP.... of course I have not looked either. XNS might have SOCK_SEQPACKET. I could be wrong. > Note that currently there is no way in the sockets layer of BSD to > do the add a sockaddr * to every read ... > > Not without hacking up the soread function .. which is exactly > what Venkat did... he added this copy the mbuf with the > address back to the mbuf chain if you don't read it all.. > > That is very difficult to justify to the BSD folks.. doing anything > within that layer if a stretch.. Since BSD allows you have your own protocol specific socket level receive, send functions (soreceive, sosend) we used separate functions for SCTP. So whatever we did, did not affect anybody else. Venkat From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 12:22:20 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11562 for ; Fri, 4 Oct 2002 12:22:19 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g94GH2ot009553; Fri, 4 Oct 2002 09:17:02 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG39613; Fri, 4 Oct 2002 09:16:57 -0700 (PDT) Message-ID: <3D9DBEF8.4010003@cisco.com> Date: Fri, 04 Oct 2002 11:16:56 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: venkat venkatsubra CC: Jon Grimm , Randall Stewart , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <20021003004901.32726.56001.Mailman@www1.ietf.org> <3D9CC81E.3D1CC76D@austin.ibm.com> <3D9CC86C.8FC1EF1B@austin.ibm.com> <3D9CDDD5.9080704@stewart.chicago.il.us> <3D9D2149.3000004@us.ibm.com> <3D9D6FCB.7060108@cisco.com> <3D9DB264.D8BD0259@austin.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Venkat: As I said in my earlier post.. PR_ATOMIC is set on UDP.. this means you trucnate things... you NEVER will get any partial mbufs in UDP that do not have the header.. R venkat venkatsubra wrote: >Randall, > >"Randall Stewart (cisco)" wrote: > > > >>Jon Grimm wrote: >> >> >> >>>Hi Randy, >>> >>>Randall Stewart wrote: >>> >>> >>> >>>>Venkat: >>>> >>>>This seems supicious.. >>>> >>>>If you do a recvmsg() and then do a subsequent recvmsg() you >>>>don't necessarily get the address and control info again... >>>>Not until the EOR is set... >>>> >>>> >>>> >>>Why do you say this? Why not? I don't recall anything in the I-D >>>calling out this behavior for subsequent reads. I interpreted this as >>>Venkat and Kavitha did and assume that every message would >>>have msg_name (address) and/or CMSG data, even if only >>>reading a subportion (MSG_EOR not set) of the message. >>> >>> >>I have thought about this and here is the reason I think it is bad >> >>Lets say I am using recvfrom instead of recvmsg() >> >>In this case I get no MSG_EOR.. I can't see it... I realize this is >>unwise ... but many >>application implementors are not going to go the extra mile to learn >>recvmsg... the folks >>coming from UDP land WILL know recvfrom though... >> >>Now if I get a message with a sockaddr filled in... I know it is the >>beginning of a >>message... >> >> > >In case of UDP i thought the remaining portion of the >message will be truncated. It won't be returned on >a subsequent recvfrom(). In fact, the socket code >always expects the first mbuf is a MT_SONAME >containing the address. > > > >>If the next read has NO sockaddr... guess what I can determine that its >>a continuation >>of the previous message... up until I read a subsequent message with a >>sockaddr setup.. maybe >>to the same guy maybe different.. >> >> > >I am not sure if the UDP recvfrom works this way >currently. In my understanding it truncates the message >if the user buffer is smaller. > > > >>But if you do this copy.. you have taken away the only indication I have >>that this is >>a second part of a message... >> >> > >I dont't think such an indication exists now >(at least in our UDP socket implementation). >I can verify. > > > > > > >> >> >>>It may be redundant information (as it will not change), but I can't >>>see a good reason that the application shouldn't be able to get >>>that information either. >>> >>> >>Just the opposite.. you are losing information.. record boundaries.. >> >> >> > >Venkat > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Oct 4 17:47:37 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23228 for ; Fri, 4 Oct 2002 17:47:36 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g94LU1ot001115 for ; Fri, 4 Oct 2002 14:30:01 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g94LU1pu020829 for ; Fri, 4 Oct 2002 14:30:01 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g94LTvao002076 for ; Fri, 4 Oct 2002 14:29:57 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA12901; Fri, 4 Oct 2002 14:24:59 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA07280; Fri, 4 Oct 2002 14:21:52 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g94LLDn07736; Fri, 4 Oct 2002 16:21:13 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA12164; Fri, 4 Oct 2002 16:22:17 -0500 (CDT) Message-ID: <3D9E067D.BE8F8B61@Motorola.com> Date: Fri, 04 Oct 2002 16:22:05 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: "Randall Stewart (cisco)" , Jon Grimm , Randall Stewart , venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <200210041219.g94CJFP09293@baqaqi.chi.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit La Monte Henry Piggy Yarroll wrote: > > On Fri, 04 Oct 2002 05:39:07 -0500, "Randall Stewart (cisco)" w > rote: > > Jon Grimm wrote: > > > Which, in turn, reminds me to ask another dumb question, why the wording > > > about the primary address? For example section 4.1.8: > > > > > > "When receiving, if a message is not received from the primary > > > address, the SCTP stack will fill in the msg_name field on return so > > > that the application can retrieve the source address information of > > > the received message." > > > > I agree.. not sure where it came from :-0 > > > > > This seems rather an odd exclusion; the primary address may never even > > > be the address that the peer sources the message from (assuming > > > multihoming of course.) Why have different behavior to just confuse > > > the application writer? I'd suggest filling in msg_name whether its > > > the primary or not. > > > > I think that paragraph should be killed.. don't know why it is there... > > This is my fault--I should have removed it when I put in assoc_id. As I am coding RSERPOOL, my biggest wish now is to make sure that this assoc_id is supplied by all SCTP stacks and is kept contant throughout the life of the association. (before assoc_id, we used to rely on a source addr sockaddr_in * to tell apart the association. Unfortunately, when the peer is multihomed and when "Add-ip" is in play, the sockaddr_in * cannot be kept constant for a given association, which becomes a big headache to the app). So pls kill the paragraph :-) -Q From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Oct 4 19:55:58 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26285 for ; Fri, 4 Oct 2002 19:55:57 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g94NnVIm020557 for ; Fri, 4 Oct 2002 16:49:31 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g94NnVm5013588 for ; Fri, 4 Oct 2002 16:49:31 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g94NmNhB026490 for ; Fri, 4 Oct 2002 16:48:23 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g94NXkH25260; Fri, 4 Oct 2002 18:33:47 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D9E255A.3020504@stewart.chicago.il.us> Date: Fri, 04 Oct 2002 18:33:46 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: La Monte Henry Piggy Yarroll , "Randall Stewart (cisco)" , Jon Grimm , venkat venkatsubra s , sctp-impl@external.cisco.com Subject: Re: [Tsvwg] A SCTP sockets/sctp_peeloff() issue to think about References: <200210041219.g94CJFP09293@baqaqi.chi.il.us> <3D9E067D.BE8F8B61@Motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > La Monte Henry Piggy Yarroll wrote: > >>On Fri, 04 Oct 2002 05:39:07 -0500, "Randall Stewart (cisco)" w >>rote: >> >>>Jon Grimm wrote: >>> >>>>Which, in turn, reminds me to ask another dumb question, why the wording >>>>about the primary address? For example section 4.1.8: >>>> >>>>"When receiving, if a message is not received from the primary >>>> address, the SCTP stack will fill in the msg_name field on return so >>>> that the application can retrieve the source address information of >>>> the received message." >>> >>>I agree.. not sure where it came from :-0 >>> >>> >>>>This seems rather an odd exclusion; the primary address may never even >>>>be the address that the peer sources the message from (assuming >>>>multihoming of course.) Why have different behavior to just confuse >>>>the application writer? I'd suggest filling in msg_name whether its >>>>the primary or not. >>> >>>I think that paragraph should be killed.. don't know why it is there... >> >>This is my fault--I should have removed it when I put in assoc_id. > > > As I am coding RSERPOOL, my biggest wish now is to make sure that this > assoc_id is supplied by all SCTP stacks and is kept contant throughout > the life of the association. > > (before assoc_id, we used to rely on a source addr sockaddr_in * to tell > apart the association. Unfortunately, when the peer is multihomed and > when "Add-ip" is in play, the sockaddr_in * cannot be kept constant for > a given association, which becomes a big headache to the app). > > So pls kill the paragraph :-) > > -Q > > Don't worry my friend.. It is already dead in the next pre-version :> R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sat Oct 5 15:53:01 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22533 for ; Sat, 5 Oct 2002 15:53:00 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g95Jhrot023898 for ; Sat, 5 Oct 2002 12:43:53 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g95Jhqwq004240 for ; Sat, 5 Oct 2002 12:43:52 -0700 (PDT) Received: from max.faseb.org ([12.17.12.116]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g95JgiQR026132 for ; Sat, 5 Oct 2002 12:42:44 -0700 (PDT) Received: from fw (fw.faseb.org [172.16.1.1]) by max.faseb.org (8.12.5/8.12.5) with SMTP id g95J40Qm007825; Sat, 5 Oct 2002 15:04:00 -0400 (EDT) Message-Id: <200210051904.g95J40Qm007825@max.faseb.org> Received: from da001d2467.cam-ma.osd.concentric.net ([207.88.97.165]) by fw; Sat, 05 Oct 2002 15:07:43 -0400 (EDT) From: "Kris Denton" Subject: First Listings To: <#field0#@max.faseb.org> Date: Sat, 05 Oct 2002 14:31:37 -0500 X-Mailer: Mozilla 4.73 [en] (Win95; I) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Professional Dear Candidate, You have recently become a candidate for inclusion in the upcoming Edition of The International Communications Network's Professional Directory=2E Your listing in The Directory, which spotlights thousands of accomplished individuals each year is free of charge=2E The International Communications Network can give you additional exposure for your business, the ability to network with others, and be listed with other notable individuals from around the world=2E If you feel that you have demonstrated leadership in your field of expertise, and would like to be considered for inclusion in The Directory, please fill out the attached form and submit it back to our offices=2E Wishing you continued success=2E We look forward to your appearance in The Directory=2E Sincerley, Karen Landers Listing Director REGISTRATION FORM Name: Business Name Job Title: Business Address: City: State: Postal Code: Country: United States Canada Australia   Business Phone: Business Fax: Website Address: Email Address: Business/Indutry: Business Expertise: Products or Services: To Opt-out from our in-house list, click Unsubscribe Me and  enter your email address=2E   ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Professional

Dear Candidate,

You have recently become a candidate for inclusion in the upcoming Edition of The International Communications Network's Professional Directory=2E

Your listing in The Directory, which spotlights thousands of accomp= lished individuals each year is free of charge=2E The International Communica= tions Network can give you additional exposure for your business, the abilit= y to network with others, and be listed with other notable individuals from= around the world=2E

If you feel that you have demonstrated leadership in your field of expertise, and would like to be considered for inclusion in The Direct= ory, please fill out the attached form and submit it back to our offices=2E=

Wishing you continued success=2E We look forward to your appearance= in The Directory=2E

Sincerley,

Karen Landers
Listing Director

REGISTRATION FORM

=
Name:
Business Name
Job Title:
Business Address:
City:
State:
Postal Code:
Country:

Business Phone:
Business Fax:
Website Address:
Email Address:
Business/Indutry:
Business Expertise:=
Products or Services:

To Opt-out f= rom our in-house list, click Unsubscribe Me and  enter your = email address=2E

  ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sun Oct 6 05:30:53 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13493 for ; Sun, 6 Oct 2002 05:30:52 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g969K8aW022330 for ; Sun, 6 Oct 2002 02:20:08 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g969KFb3002670 for ; Sun, 6 Oct 2002 02:20:15 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g969K9ao001200 for ; Sun, 6 Oct 2002 02:20:11 -0700 (PDT) Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id NAA21365 for ; Sun, 6 Oct 2002 13:22:47 +0530 From: "dharani_s_me" Message-Id: <200210060752.NAA21365@WS0005.indiatimes.com> To: Reply-To: "dharani_s_me" Subject: implementation of sctp Date: Sun, 06 Oct 2002 13:37:23 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091" MIME-Version: 1.0 --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091 Content-Type: text/plain; charset=us-ascii sir, iam doing mtech computer science & engg. i want to know how sctp is implemented. can you please sent me the source code implementation of SCTP. please send me as early as possible. awaiting for your reply. thanks, dharani.s Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091 Content-Type: text/html; charset=us-ascii

sir,

    iam doing mtech computer science & engg. i want to know how sctp is implemented. can you please sent me the source code implementation of SCTP.

please send me as early as possible. awaiting for your reply.

thanks,

dharani.s

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sun Oct 6 08:05:19 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15326 for ; Sun, 6 Oct 2002 08:05:18 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g96BuHIm004699 for ; Sun, 6 Oct 2002 04:56:17 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g96BuG3X002077 for ; Sun, 6 Oct 2002 04:56:16 -0700 (PDT) Received: from odin.system.xy (gumb-d9b9e42e.pool.mediaWays.net [217.185.228.46]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g96BuATb018056 for ; Sun, 6 Oct 2002 04:56:12 -0700 (PDT) Received: from odin (localhost [127.0.0.1]) by odin.system.xy (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g96Bt9x4003000; Sun, 6 Oct 2002 13:55:09 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Thomas Dreibholz Organization: University of Essen, Institute for Experimental Mathematics To: "dharani_s_me", Subject: Re: implementation of sctp Date: Sun, 6 Oct 2002 13:55:06 +0200 X-Mailer: KMail [version 1.4] References: <200210060752.NAA21365@WS0005.indiatimes.com> In-Reply-To: <200210060752.NAA21365@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210061355.09276.dreibh@irmgard.exp-math.uni-essen.de> X-Virus-Scanned: by amavis-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sonntag, 6. Oktober 2002 10:07, dharani_s_me wrote: > sir, > > > iam doing mtech computer science & engg. i want to know how sctp is > implemented. can you please sent me the source code implementation of SCTP. You can download the userland SCTP implementation of the University of Essen here: http://www.sctp.de/sctp.html Best regards - -- ======================================================================= Dipl.-Inform. Thomas Dreibholz Molbachweg 7 D-51674 Wiehl-Forst Mail: dreibh@exp-math.uni-essen.de Germany WWW: http://www.exp-math.uni-essen.de/~dreibh ======================================================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9oCSc32BbsHYPLWURApVKAJ9CD32wcraX3fHJTAukw7coxP9I7wCgg62h 2fDJo/6DFeCKYsIWrVYi2OA= =Utp5 -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sun Oct 6 08:12:44 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15506 for ; Sun, 6 Oct 2002 08:12:39 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g96CB9aW012068 for ; Sun, 6 Oct 2002 05:11:09 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g96CBFHA018798 for ; Sun, 6 Oct 2002 05:11:16 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-4-78.client.attbi.com [12.249.4.78]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g96CA7Sm008300 for ; Sun, 6 Oct 2002 05:10:07 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g96ArhV27565; Sun, 6 Oct 2002 05:53:47 -0500 Message-Id: <200210061053.g96ArhV27565@baqaqi.chi.il.us> To: "dharani_s_me" cc: sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: implementation of sctp In-reply-to: Your message of Sun, 06 Oct 2002 13:37:23 +0530. <200210060752.NAA21365@WS0005.indiatimes.com> Date: Sun, 06 Oct 2002 05:53:42 -0500 Sender: piggy@baqaqi.chi.il.us You can find open source distributions of SCTP at sctp.org, sctp.de, lksctp.sourceforge.net, and openss7.org. I highly recommend the book by Randall Stewart and Qiaobing Xie, http://www.sctp.org/book.html, which provides very complete coverage of the implementation of SCTP. On Sun, 06 Oct 2002 13:37:23 +0530, "dharani_s_me" wrote: > --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091 > Content-Type: text/plain; charset=us-ascii > > sir, > > > iam doing mtech computer science & engg. i want to know how sctp is implemented. can you please sent me the source code implementation of SCTP. > > > please send me as early as possible. awaiting for your reply. > > > thanks, > > > dharani.s > > > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in > > --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091 > Content-Type: text/html; charset=us-ascii > >

sir,

>

    iam doing mtech computer science & engg. i want to know how sctp is implemented. can you please sent me the source code implementation of SCTP.

>

please send me as early as possible. awaiting for your reply.

>

thanks,

>

dharani.s

>

 

>
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in > > --=_MAILER_ATTACH_BOUNDARY1_20021060133723412776091-- > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sun Oct 6 09:04:33 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16050 for ; Sun, 6 Oct 2002 09:04:32 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g96BtAot001378; Sun, 6 Oct 2002 04:55:10 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG70535; Sun, 6 Oct 2002 04:55:08 -0700 (PDT) Message-ID: <3DA0249B.3040700@cisco.com> Date: Sun, 06 Oct 2002 06:55:07 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dharani_s_me CC: sctp-impl@external.cisco.com Subject: Re: implementation of sctp References: <200210060752.NAA21365@WS0005.indiatimes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit dharani_s_me wrote: > sir, > > iam doing mtech computer science & engg. i want to know how sctp > is implemented. can you please sent me the source code implementation > of SCTP. > > please send me as early as possible. awaiting for your reply. > > thanks, > > dharani.s > > > > ------------------------------------------------------------------------ > *Get Your Private, Free E-mail from Indiatimes at > **http://email.indiatimes.com* > Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from > http://www.planetm.co.in You can find sctp implementations at: http://www.kame.net (sctp is bundled with the KAME BSD stack) http://www.sctp.de ( a user lib version) http://www.openss7.org Regards R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Oct 7 02:54:51 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09245 for ; Mon, 7 Oct 2002 02:54:46 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g976fUaW013726 for ; Sun, 6 Oct 2002 23:41:30 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g976fbTB014330 for ; Sun, 6 Oct 2002 23:41:37 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g976fXao026590 for ; Sun, 6 Oct 2002 23:41:34 -0700 (PDT) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g97647a14393 for ; Mon, 7 Oct 2002 08:04:07 +0200 (MEST) Received: from poseidon.siemens.gr (poseidon.siemens.gr [141.29.40.250]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g97646Q10964 for ; Mon, 7 Oct 2002 08:04:06 +0200 (MEST) Received: by Poseidon with Internet Mail Service (5.5.2653.19) id <4A8M98RG>; Mon, 7 Oct 2002 09:00:21 +0300 Message-ID: From: Chaitidis Theodosios To: sctp-impl@external.cisco.com Date: Mon, 7 Oct 2002 09:04:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" INFO From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 8 16:11:07 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29119 for ; Tue, 8 Oct 2002 16:11:06 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g98K7Sot013286 for ; Tue, 8 Oct 2002 13:07:28 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH28237; Tue, 8 Oct 2002 13:07:25 -0700 (PDT) Message-ID: <3DA33AFC.3080302@cisco.com> Date: Tue, 08 Oct 2002 15:07:24 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: peeloff tester Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: I have just placed a new "peeloff" testing utility up on http://www.sctp.org This utililty is started on the server peel_server -m port-num-of-server On the client do peel_client -h host-of-server -p port-of-server The client will make two associations to the server and write 4 4k records. The server will read N bytes of the first record, peeloff the association and then read the 4k-N bytes followed by the other 3 4k records. After validating the resulting reads are correct it then closes the peeled off association.. This is the key for the client to reconnect the dead assocaition.. This will continue starting where N is 1 up to about 4095... At the last pass the server will look for one more.. but blow up.. since the client as dropped off :> So you should get nearly 4k passes with all data correct... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 8 16:58:45 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00670 for ; Tue, 8 Oct 2002 16:58:44 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98KqSIm018373 for ; Tue, 8 Oct 2002 13:52:28 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98KqRd0000844 for ; Tue, 8 Oct 2002 13:52:27 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g98KoebL004415 for ; Tue, 8 Oct 2002 13:50:41 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98KhshG248236; Tue, 8 Oct 2002 16:43:54 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98KhpYU130114; Tue, 8 Oct 2002 16:43:52 -0400 Message-ID: <3DA34296.5C814A12@us.ibm.com> Date: Tue, 08 Oct 2002 13:39:50 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: sctp-impl@external.cisco.com Subject: Re: peeloff tester References: <3DA33AFC.3080302@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Randall Stewart (cisco)" wrote: > > Hi all: > > I have just placed a new "peeloff" testing utility up on > http://www.sctp.org > R Thanks, I just pulled it down. Very handy. This may be obvious, but what should sctp_peeloff() return if its a SOCK_STREAM socket? EOPNOTSUPP? This should be obvious but I'm not sure..Ditto for a few other cases: what if the socket isnt even bound yet? thanks, Nivedita From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 8 17:58:24 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02102 for ; Tue, 8 Oct 2002 17:58:23 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98LucIm011918; Tue, 8 Oct 2002 14:56:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH32912; Tue, 8 Oct 2002 14:56:37 -0700 (PDT) Message-ID: <3DA35494.9020100@cisco.com> Date: Tue, 08 Oct 2002 16:56:36 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: sctp-impl@external.cisco.com Subject: Re: peeloff tester References: <3DA33AFC.3080302@cisco.com> <3DA34296.5C814A12@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nivedita Singhvi wrote: >"Randall Stewart (cisco)" wrote: > > >>Hi all: >> >>I have just placed a new "peeloff" testing utility up on >>http://www.sctp.org >> >> > > > >>R >> >> > >Thanks, I just pulled it down. Very handy. This may be >obvious, but what should sctp_peeloff() return if its >a SOCK_STREAM socket? EOPNOTSUPP? This should be obvious >but I'm not sure..Ditto for a few other cases: what if >the socket isnt even bound yet? > >thanks, >Nivedita > > > Yeah EOPNOTSUPP would generally be what one would expect if the peeloff() was not supported... I know if you don't compile TCP style into the kame kernel you will get this back.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 8 19:17:19 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03273 for ; Tue, 8 Oct 2002 19:17:19 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g98N9vaW008675; Tue, 8 Oct 2002 16:09:57 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH35781; Tue, 8 Oct 2002 16:10:03 -0700 (PDT) Message-ID: <3DA365CA.9000106@cisco.com> Date: Tue, 08 Oct 2002 18:10:02 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: sctp-impl@external.cisco.com Subject: Re: peeloff tester References: <3DA33AFC.3080302@cisco.com> <3DA34296.5C814A12@us.ibm.com> <3DA35494.9020100@cisco.com> <3DA358F1.C0F54845@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tcp-style or SOCK_DGRAM = 1 to 1 socket to association Udp-style or SEQ_PACKET = 1 to many socket to association R Nivedita Singhvi wrote: >"Randall Stewart (cisco)" wrote: > > > >>>Thanks, I just pulled it down. Very handy. This may be >>>obvious, but what should sctp_peeloff() return if its >>>a SOCK_STREAM socket? EOPNOTSUPP? This should be obvious >>>but I'm not sure..Ditto for a few other cases: what if >>>the socket isnt even bound yet? >>> >>> > > > >>Yeah >> >>EOPNOTSUPP would generally be what one would expect if the peeloff() was >>not supported... I know if you don't compile TCP style into the kame kernel >>you will get this back.. >> >>R >> >> > >Thanks for the response..Just to clarify, are you implying >that should you have TCP style socket support, then sctp_peeloff() >could be supported? Hmmm, from my reading of the API draft, I had >assumed (but I'm fairly new to SCTP and havent done any implementing >yet) that there was no applicable equivalent for a SOCK_STREAM socket. >i.e. It isnt supported for tcp-style sockets..If thats not the case, >then what exactly should happen for a tcp socket? > >I appreciate the help! :) > >thanks, >Nivedita > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 8 19:39:00 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03663 for ; Tue, 8 Oct 2002 19:38:59 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g98MPuIm004318 for ; Tue, 8 Oct 2002 15:25:57 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g98MPuf1012693 for ; Tue, 8 Oct 2002 15:25:56 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g98MPpao014423 for ; Tue, 8 Oct 2002 15:25:52 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98MJHVL193398; Tue, 8 Oct 2002 18:19:17 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98MJEYU173486; Tue, 8 Oct 2002 18:19:15 -0400 Message-ID: <3DA358F1.C0F54845@us.ibm.com> Date: Tue, 08 Oct 2002 15:15:13 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: sctp-impl@external.cisco.com Subject: Re: peeloff tester References: <3DA33AFC.3080302@cisco.com> <3DA34296.5C814A12@us.ibm.com> <3DA35494.9020100@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Randall Stewart (cisco)" wrote: > >Thanks, I just pulled it down. Very handy. This may be > >obvious, but what should sctp_peeloff() return if its > >a SOCK_STREAM socket? EOPNOTSUPP? This should be obvious > >but I'm not sure..Ditto for a few other cases: what if > >the socket isnt even bound yet? > Yeah > > EOPNOTSUPP would generally be what one would expect if the peeloff() was > not supported... I know if you don't compile TCP style into the kame kernel > you will get this back.. > > R Thanks for the response..Just to clarify, are you implying that should you have TCP style socket support, then sctp_peeloff() could be supported? Hmmm, from my reading of the API draft, I had assumed (but I'm fairly new to SCTP and havent done any implementing yet) that there was no applicable equivalent for a SOCK_STREAM socket. i.e. It isnt supported for tcp-style sockets..If thats not the case, then what exactly should happen for a tcp socket? I appreciate the help! :) thanks, Nivedita From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 9 07:52:18 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11202 for ; Wed, 9 Oct 2002 07:52:17 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99Bo4Im025287 for ; Wed, 9 Oct 2002 04:50:04 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH48938; Wed, 9 Oct 2002 04:50:03 -0700 (PDT) Message-ID: <3DA417EA.9000908@cisco.com> Date: Wed, 09 Oct 2002 06:50:02 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: sctp.org patches for kame Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all: I have added to the download page at http://www.sctp.org a patch file for the current kame snap.. and all the work we have done over the last few weeks since the bake-off. We have found a number of bugs and fixed a LOT of API issues... Unfortunately these have been sent to kame but due to their time constraints have not yet made it into their release... Until all the patches catch up and get incorporated I will be making a patch each Monday A.M. to make sure you can always get the current bug fixes on top of whereever KAME is at. As soon as kame catches up and we have nothing left to incorporate I will discontinue this practice.. Thanks R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 10 16:53:58 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23855 for ; Thu, 10 Oct 2002 16:53:57 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9AKlQaW019748 for ; Thu, 10 Oct 2002 13:47:26 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI00981; Thu, 10 Oct 2002 13:47:33 -0700 (PDT) Message-ID: <3DA5E764.7040904@cisco.com> Date: Thu, 10 Oct 2002 15:47:32 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: New apache 2 on sctp.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all: I have now placed a brand new apache tar ball up on http://www.sctp.org (under the downloads tab) What is new and special about this apache is: 1) It is based on the latest release 2.0.43 2) It will recognize SCTP in a machine when you do a ./configure 3) If it sees SCTP it will run BOTH a TCP and SCTP listner.. this way it will service web requests under either protocol. I will try to work to get this put into mainline apache.. Note, it does NOT take advantage of any nice features of SCTP yet (except multi-homing of course)... but first things first... if we get the web able to handle SCTP ... the next step is to get the web to better use the streams capabilities :> Note.. for those of you interested ..how the ./configure script decides you have sctp on your machine is by looking for .. if this file is not there it will decide you do NOT have SCTP in the kernel... Enjoy R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 10 20:18:07 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27283 for ; Thu, 10 Oct 2002 20:18:06 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9B079Im015809 for ; Thu, 10 Oct 2002 17:07:09 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9B079w7010295 for ; Thu, 10 Oct 2002 17:07:09 -0700 (PDT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9B074eT007135 for ; Thu, 10 Oct 2002 17:07:05 -0700 (PDT) Received: from cc2181633-a ([67.212.82.72]) by out011.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021010234803.WHHI17563.out011.verizon.net@cc2181633-a> for ; Thu, 10 Oct 2002 18:48:03 -0500 Message-ID: <4159-220021041023428310@cc2181633-a> Organisation: Market*Access International, Inc. From: "David Dickson" To: "sctp-impl@external.cisco.com" Subject: Gov't Best Practices Training Conf - Mobile & Wireless - Nov 13 '02 - Arl Va. Date: Thu, 10 Oct 2002 19:42:08 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" This is a multi-part message in MIME format. ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable If you wish to be REMOVED from this list, please REPLY and place REMOVE in= the SUBJECT line=2E Thank you=2E ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

 

 

 

 To:        sctp-impl@external=2Ecisco=2Ecom 

Mobile and Wireless Solutions

Homeland Defense Training Conference=99

Government Best Practices Training Conferen= ce =99

Wednesday, November 13, 2= 002

Executive Conference Center

4301 Wilson Boulevard

Arlington, Virginia 22203
 

Continental Breakfast, Refreshments, Lunch included=2E

 

Attention Industry:=A0 There are e= xcellent sponsorship and exhibitor plans available for this senior government executive conference=2E=A0 See = below=2E

About Mobile and Wireless Solutions

From townships to federal agencies, mobile-wireless technology is mak= ing inroads into traditional government business, public safety and operational solutions=2E

Government IT Executives are quickly recognizing the exciting opportu= nity to extend their reach beyond the web to devices like cell phones, handhe= ld computers, interactive pagers, Palm Pilots, and other PDAs=2E  The commercial growth potential for this market is just about to explode=2E&= nbsp; IDC Research projects that 61=2E5 million people will be using wireless = devices to access the Internet in 2003=2E  This is a 728% increase from the= 7=2E4 million users today=2E  Government business applications of wireles= s will track this explosive growth=2E

Products and solutions that address wireless security, business continuity, reliability and disaster recovery will experience high growt= h due to the recent terrorist attacks and the need to improve communications a= nd security=2E

For information on how to register on-line and to v= iew our web site call our information hot line, call:=A0 703-807-2027=2E
Conference Goal

Market*Access will host a training conference for industry and govern= ment focusing on agency needs and requirements in Mobile and Wireless Solutio= ns in the area of Homeland Defense=2E This will be a public-level series of tr= aining presentations on the challenges ahead=2E Speakers will represent federal= agencies and leading security, equipment and systems suppliers=2E

The goal of this meeting is to begin to prepare U=2ES=2E government a= nd industry for the changes that will come about regarding mobile and wirel= ess solutions for Homeland Defense=2E

Exhibitors May Include
  • Wireless and mobile= solution providers
  • Mobile and wireless= communications
  • Security planners <= o:p>
  • Federal systems int= egrators
  • Network and Systems= Security Training and Consulting
  • Disaster recovery a= nd facility security
  • =85 and many others=
Who Should Attend
  • Agency IT Executive= s
  • Agency mobile and w= ireless program managers
  • Tele-work and Telec= omm Directors & Managers
  • Functional area man= agers using mobile computing
  • Wireless and mobile= solutions providers
  • Federal systems int= egrators and solutions providers
  • Federal, State and = Local CIOs and IT teams
 What you will learn
  • Understanding new p= rograms, issues and requirements
  • Strategies for mobi= le and wireless applications
  • New products in dev= elopment and on the drawing boards in terms of Mobile and Wireless Solutions=
  • New initiatives bei= ng planned at the federal, state and local levels=2E
  • Civil agency organi= zation and planning
  • R&D Initiatives=
Speakers Will Represent:
  • Government agency applications of mobile and wireless technologies =
  • Communication manag= ers and program analysts
  • Technology developm= ent leaders representing academic efforts and private sector research a= nd development programs and devices dedicated to mobile and wireless solutions
  • These speakers will= provide attendees with up to date reports on current local and national programs, new technological advances, demonstration project updates= , common challenges and the outlook for the future=2E

Chris Rangel, Assistant Vice President, Alvarion, Inc=2E

Chris Rangel has over 17 years of experience in the communications indus= try with a background in Engineering, System Architecture, Business Developm= ent and Marketing=2E Mr=2E Rangel joined Alvarion in November 2000 as the Di= rector of System Architecture where he was instrumental in developing market strat= egies and defining new products=2E Currently, as the Assistant Vice President = of Marketing, Chris is primarily responsible for advanced business developm= ent, market strategy, and new product concepts=2E

Prior to joining Alvarion, Mr=2E Rangel was Chief Architect for Motorola= 's Broadband Solutions Division and Chief System Engineer of Ground Systems= for Teledesic (Motorola)=2E Chris has a MSEE from the Georgia Institute of Technology, as well as a BS in Computer Engineering and a BSEE from the = Florida Institute of Technology=2E

Andrew Krieg, President, Wireless Communications Association International (WCAI) (Industry Keynote Speaker)

RIM/BlackBerry

GSA Federal Technology Service (FTS)

Leading government executives from DoD and civil agencies have bee= n invited=2E
 

Points of Contact:

For information on exhibitor arrangements, please contact Ms=2E Cara Lombardi at 703/807-2747

For registration or general information about this event, please cont= act Mr=2E Parrish Knight at 703/807-2748=2E

Corporate Sponsors

Alvarion

Alvarion is the world=92s largest pure play provider of solutions bas= ed on Point-to-Multipoint (PMP), Broadband Wireless Access (BWA), one of the technologies essential to the growth of broadband markets=2E Created thr= ough the merger of BreezeCOM and Floware, the Company supplies integrated BWA= solutions to telecom carriers, service providers and enterprises all ove= r the world=2E From providing high-performance access and data and voice servi= ces in the last-mile through facilitating cost-effective feeding for cellular networks, to enabling building-to-building connectivity and Wireless LAN= , Alvarion=92s products represent a full spectrum of BWA applications=2E

 

Blackberry

BlackBerry=99 is an end-to-end wireless email solution, developed by = RIM, that meets the stringent security needs of public sector organizations=2E= It is the only totally integrated package that includes software, airtime and = your choice of wireless handhelds to provide easy, secure and affordable acce= ss to your email wherever you go=2E BlackBerry Wireless Handhelds=99 have been= awarded the FIPS 140-1 Validation for their embedded encryption technology, and BlackBerry supports Triple DES, an industry-leading security standard, t= o meet stringent government security guidelines for remote email access=2E= Since Triple DES encryption is considered unbreakable, you can feel confident = about sending and receiving confidential information=2E

NexTel

=85other sponsors and exhibitors to be announced=2E

Organizational Sponsors
 

Homeland Defense Journal

 Readership now exceeds over 50,000 per issue=2E=A0 Homeland Defense Journal is the d= efinitive news journal for the homeland defense community=2E=A0

Contingency Planning Magazine

The mission of Contingency Planning and Management is to be the centr= al resource for technology, products, services, information, and management= strategies that support business continuity to safeguard the physical, informational, and communication assets of a business; ensure the safety= of employees and the public; and protect the financial well-being of the company=2E 

DRII International

DRI International provides a base of common knowledge in contingency planning, a rapidly growing industry=2E  DRII also:

  • Administers the ind= ustry's premier global certification program for qualified business continu= ity and disaster recovery planners=2E
  • Maintains the Profe= ssional Practices for Business Continuity Planners that serves as the indus= try's best practices standard=2E
  • Provides= training courses to educate and inform business continuity and disaster reco= very planners worldwide=2E

GSA Federal Technology Service

As federal agencies strive to use digital technologies to transform t= heir operations, the GSA Federal Technology Service (FTS) is ready to advise = and support you in that effort=2E Whether your job involves human resources,= procurement, or supply chain management; financial systems, critical infrastructure protection, or enterprise architecture and information management; legacy migration, web connectivity, knowledge and customer relationship management, you can turn to us for the information technolo= gy and telecommunication solutions that will help you get the job done=2E

INPUT

Federal Outsourcing Market Study

INPUT has just completed it latest study of the Federal Outsourcing Market=2E

With strong support from the legislature and the Bush Administration,= INPUT is forecasting strong growth in federal spending on IT related outsourcing services=2E  

Department of Transportation

Transportation Administrative Service Center=

The Department of Transportation's (DOT) Transportation Administrativ= e Service Center (TASC) Information Technology Operations has established = a mechanism for Federal, state, and local government customers to rapidly acquire a wide array of specialized or "niche" information technology (IT) services and support=2E

Specialized Technical and Technology User Services (STATUS) provides pro= gram management and the delivery of "niche" information technology services through its own resources and dozens of recognized contractors = across the functional areas shown:

  • Geographic/Geospati= al Information Systems
  • Artificial Intellig= ence
  • Wireless Technologi= es and Networks
  • E-Learning Manageme= nt and Content
  • Operatio= nal Support

Wireless Communications Association, Interna= tional

Founded in 1988, the Wireless Communications Association Internationa= l (WCA) is the principal non-profit trade association representing the wir= eless broadband industry=2E WCA membership, which includes the industry's lead= ing carriers, vendors and consultants, has grown to over 530 member companie= s spanning six continents=2E

The WCA organizes the world's largest annual business conference and exhibition devoted exclusively to wireless broadband=2E This conference = and exhibition annually convenes experts from around the world to discuss ma= rket strategies, emerging technologies, new applications and financing/regula= tory options=2E The WCA's 15th annual exhibition WCA 2002 will be held on Jun= e 24 - 27, 2002 at the World Trade Center in Boston, Massachusetts=2E

=2E=2E=2Eadditional Organizational sponsors to be announced=2E

Registration Fee
  • Industry Credit Car= d or Check in Advance $695
  • Governme= nt Credit Card or Check in Advance $495

To request more information: Call 703-807-2748=2E

For information on how to register on-line and to= view our web site call our information hot line, call:=A0 703-807-2027=2E

 

Directions to Conference = Center:

The Executive Conference C= enter at Ballston

The National Rural Electri= c Cooperative Association, Plaza Level
4301 Wilson Boulevard, Arlington, Virginia 22203

Marketing, Conference Man= agement and Production by:

Market*Access Internati= onal, Inc=2E
(301) 455-5633

---------------------------------------------------------------------= ----------------------------------------------------

 

Mobile and Wireless Solutions

Homeland Defe= nse Training Conference=99

Government Be= st Practices Training Conference =99

Wednesday, No= vember 13, 2002 

 =

Registration = Form

(Use additional pages as needed= for multiple employees)

Attendee Name:

Title:

Company/Agency:

Company/Agency Web site:

Address:

City:

State:

Zip Code:

Email:

Telephone:

Fax:

Note: Payment requested in advance=2E=

Please check one of the following as your f= orm of payment:

[ ] Check

Make checks payable to: Market*Access Intern= ational

Send to: Market*Access, 4301 Wilson Boulevar= d, Suite 1003, Arlington VA 22203

[ ] VISA [ ] MasterCard [ ] American Express

Account Number: ___________________________Exp=2E Date___________________

Cardholder Name: ______________________________________________________

Signature (required) or telephone order

_______________________________________

Pre-Registration Fee:

Industry Credit Card or Check in Advance $695

Government Credit Card or Check in Advance $495

Additional Information and Additional Copies of Registra= tion Form are available by calling 703-807-2027=2E

Registration and Information: Call Parrish S=2E Knight (703) 807-2748

Fax this form to 703-807-= 2728=2E Thank you=2E

I would be very interested in attendin= g a future training conference on the subject of:

_________________________= ________________

I am a manager/subject matter expert for the= following technical/mission area:

_________________________________________

The most significant challenge my organizati= on faces is:

_________________________________________

Here are email addresses of my contacts and = peers who should be invited to this conference:

_________________________________________

Special Notes:

This message is being sent to you as a service to inform you and = your organization of a training conference directed at federal and industry managers=2E If this business communication was sent to you in error or i= s not of interest, please let us know by REPLY'ing to this message and place R= EMOVE in the SUBJECT line=2E We will remove your name immediately=2E

If however, you wish to receive additional information about this= Conference, how you can register on-line and other related training opportunities, please place SUBSCRIBE TRAINING in the SUBJECT line and R= EPLY to this message=2E We will include you in future notices concerning this= topic=2E

Is your organization involved with homeland defense?=A0 If so, you may wish to register f= or your free subscription to the Homeland Defense Journal=2E=A0 This paper is downloaded over 50,000 time per issue =96 = two issues per month=2E=A0 Go to www=2Ehomelanddefensejournal=2Ecom to register=2E=A0 It=92s free=2E=

 

 

------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Description: image001.gif Content-Id: <3188557-220021041023427700689@cc2181633-a> Content-Transfer-Encoding: base64 R0lGODlhtABkAPcAAOPh3Ly4sdbSzLq1q3N5iEZUbFhgcNnSzf7+/jlFZXqDksrEu4CJmfn5+O7s 6drV0Gt1h6SqtbComero5OHe2TlIZJ2kr9XRys3KwpObqDZFYsjM0rStotPT0tLV2sXBut3b26mi laWcj7zDyS09XLConPX19K2lmN7a1N3g47Cmm9POydnd4fHw7jdHZc7R1vz8+t3Z0kJOZjVIYi8+ YKykl0pXcDhHYv///PHx8WRtffX08u/u6qqwuVJddK6omys7W8HFzNDNxqmhktXTzsG9tbW6w6yk mBcpSfj49ujm4y09WNDLwi5AXDZHXyQ0U9XY3Ss6Vo2Vovz8/C8+Xbm/xcjJz+Pl6MbBtt3WzzFB Xby4rcC8sbWvpObk4LCon7ayqTJBYVtleszIvsrGwL+3rdjUzsTJz+3t7NzX0dfSyvPy8Lmxph0w UNLQyezr59rUzmNvgq6mmdvY0qefktvY1MG6sObl5erp6F1ngVdjdtTQxqyhlYiRn9vWz+Xi3+vt 7vv6+cO/uNnTyqqlmdnW0zRCYV9qfe/w8bGsn7O3wPf29Co8WeDl59/i5djUzKigj+fp64KJlv3/ /vb3997c1qujlTlGXp6WiNvYz/Lz9C06XcG7tT1LZVVgd3R+jsO+tPP19SY6Wi9AWvv7+dHNwcnD tio6XS86WzNEYa6kmK60vvb384WNnCc2VO3v8NbPyPz/+zJBZCc5VS5BYDhFaNPQzKqimOjr7LWs nzVDZTRCXrCqnyk3WaqkkjVJXtLKwDdHZ/T4+dnW0E9ccSo8XjFDXtrUyq6mnLu/yLOqn7GqnKyn mPz7+zNFZayiks/KxbKpm8W+sCEyUK2ilzM/WNfRx/39/f79+/r6+/L08LGpn6ylmiM1V9fTyzpJ YNfWza2mmjpGYjVIZ0FPafv8/NrVzMfEv6+nl9vPyPz9/fTz8/j4+K6lmUVRbjtIZzhDZz1DYpef q8jAt9jTz+Xn6aymlNzW1DRFXTZDWaqknMvBuzdGY9jTza+nmv///yH5BAAAAAAALAAAAAC0AGQA AAj/AP8JHEiwoMGDCBMqXEgQh0OHAxE0MMGDggAhCxaYslOmDKcPGB6hADBhXQOCCBAwXMmypcuX MGPKLLhuAgpoggJsCcCFywdBGS8ooVCHiJAxY7iA+iDAC48kEWdKnUq1qtWBSbysKMNmgJ0FwPaY y5RpTho/dQIZxGbCwR835wR9MMMDx9W7ePNKnVQQQYt+AxKVAQarn9k0D8zQW2zGlpJ/KRNOnACN kxAHKvVq3sx5IF+BgZQIArNljBo4ic30o6e6n+tH9B4sOsj3M0FKXvZAuwP1n+3OwIPLTAJg3wAs YjO1ds28+SMBKKbE9DIPCwC1wrNrZ3jtDxcwC9Sc/6W3urn517YAZG7JF1sMYKDOvdlOf/ukzA4E DTAlfhh5egcIIIAZBzj3yCPe9GMLHjJNAcIB5oxRhC3r1GdhZyo1M8cWC/STGHODqHEACigIcECB ryHozQoUwCATDChc4CEcC3AyR28X5njXDucMYE0a/QjgmhkX2EKEEs0E8oeMzJkhoACFmDBTIHUw aYYfanDBCQ86djlTZncodUAW5g1YyQ4DdTdgPwFSwMMaUE3yW0vsFMJkPx0UksU8A1DA13peBroQ AjEMMAYccByw2GIXALCIOv9gg41KO6ghZD9CETRnSyZ4k6Bri8GRBgZgkDEbDrHYJeiqBU1hSxmw PP8Q5KL0XNAiaJX8odIEhbl2gRdUNQPAneb5cQEYA3C5KauBNoBBGd5k4poAi9qKHQJ/CIFCM/94 0asZe6jXEgJJOIBjEpVcAMdy5j3wgB1dOAAZs4KqlMQHAwxiDhHMLQbdSQI5QISIa/zDg4wm7qGr SwCsUAeaiBSyxyAonufaMFnYAQaX9HpJKShlIGoeoxRcI1ALAir4GDvDqKGGG3VQ0hI2OFBgiy1v vGELsRYz94AfRQzQwj+xxNJxjg1wMoDIIy9KgRcAFJIytfO9QQQRFMi8EnGVUDCHGWZ8TQS7PTf5 QBEBSKnq0fTFskAZDwzzaXOLHnDBBSlPizNklJj/QEpLSqzghhBjO1l42RbTk4YdReDI9naZdHHM A/wmHmo/TGNaSDYvqRTIHG48LTdriyFusQBwZBHAOdjM+7hwXnQBzDCmWxxi6CavBAMrDaj0xgoA kIIABXsoWnvZDwgARh2vZ+dAFwuQeTxzAlxgxjCVsMKSCZWsMME/16TL8R/Fkzf9eWY8sMIADDbf WTNl2JHFI+ffLUAlcMIA0aANq8FlDgJYwdD+AQBrwMF85zvPAz5gB4C5Dy+fAccAsgAH04ENbAIg wh92kLt/rO0gEpnC8PA2tDsIYRjaQ9ncEmixLJRhDB184F3WEQAh+KF2F7QFCtYAKIa8oRCVaIEX /2whgPk0AA2zYUUaeMbCdqWDDZWQYV7cgIWz+OGKWMziFdPwtTnM5iUTuIC+6jCMIhJkDSi4khbX yMY2+uEBKCgFKFwkRas4AAtZIJEe98hHEmUvJggAQAz0SAHtIWANXshEHxfJyEaSiAKmQIGOGEDJ SlrykpjMpCY1KQkI6IAAoAylKEcJyk9IYpOolIQCRKkASaiSlLCMpSxJ6UlU2vKWuGQAEHbJy176 8pfADGYwTwEEGmyCBMhMJgmA0IteuMIVx1wCMoVJTSCcohjYROYmiFkMZXrzm+AMpzKLwYgmUIGY 1UynOoXphHa6851OwMcotEBPY8ATnsag5yjsef/Pfs7gBjMIqEBnQA4bFMATOngHPn7Rz4b2kx8Q fWdAm1DOXwz0osZghDEuytGO/hOiN3CoSEdKUngm4KQoTWkC3vEOQ6RCA2HQhQtUmoBg6CIMhtAA S2tBU5Xe4Kc3gKhQ8aGFVmzAEdpwBDnC8M+f9vSpKRUqUG+gAQ0Q4xA20MBPhQpSe/qgAPjQAFfH SlZ+DHSmUE2rWtca1bLywwVU0EMQXnCGDVhgF84YawJoQI5VbOAMQYCAFlzg1sIKVQPkEMMV/nEF GYTBsJA9LERdcINU0KIJq9BEBjaRCkMI1QUu0EIFquCIOEQhsqhNrWpXW1gNdEIHVhBIMz4xC7L/ PoEBAgEEBDrhhBmwlqtNQEUQ/uEIGRhCHL+FqAa0oAHCvjUVMugEEhSAAAW0gRydaO5kXaGAf2iC GIxwbnLHS17WOmMaceDcPzawCy1wVQu72IBAPLCLTYzDtyAFrXi5egPnbtUJYUgGcY2LXMOCNqif TQUVbEAOsfLDGSRYBRQO0Ykq2OAQLJAHEAgrDlpEYbjC+IQrCttfypK1xPudLGgLq98Uq3jF5dWA OEjgiXpQAgeU+EQvIjqDXhBgHX/zQCe04IRL1LQCYZAmFVKx4gTAlBburQAtltBOGlRhwJ7VRSrw oQt4JCCo/ZUFEJYQhgT8MwGymIUCPOCJEddC/xf4MEIKXpCBKmTgBSmIAHMhWgwIOEJmZ7hEGADK Xw1QAZmpCGoCxFEBF9Cgmxt1KmjDgOgK8OMGJ220IagAhCW7wAn8SIALkJxMY1AWwb9NAD+WkAcP 9EAlZ9BCKi6dijAoIgiA+IeQmxBUF4QhCs4oQAHIIWsXjKMYoqCFE75Ri028gxw51cKVi5vTQzNi CYb49A1qUQxjGNQYpwCtIVzRimyEghjTSMU4+OEEGbyjGhEQhhTE0QlyCPWlZ5CCfBsQByCY9bOy 2AQ5iOEOKhQDtGg+xTuIUYBqRCGg43AGI1JhUC0s4QbrroAuTrELYcuACjQIxgxc4IxT0MDjWv+g AU/Hq2pWQ0EHjfhHMyBAggo0+xMvgECud32DYIyiEwoYARQawYIIDLkCDFjFCF5gBHgQAAopgAAj qDBtGURBD6vogSJG0Ipd3AAfNIDACILAgjNAABWy0IA8OMeKKijiE9XoLw2a0Icg6GADDFhCEyZL BR144BIWEIg8whvQqlLBHRbwQBA2YAQxjGIcNBBHKzywgRfYnQYzyOcngkB2uy/BGS7YxS4+YQUP eIAFQdADDcYhTwgEAQpQYMELdEADF6e25XlohAykIJAqoOIG4thEFSxAjBzouhN7R4WfgyAGH6xC IJKYRQJ8IAWZpUAejnjFPxjgCqoPWAvuMED/FbIhDxvowhCokIc6eiAOCGgiG33oxTj0EFtEKOAQ xMh2VZ9vAST04B/yQAUOtgSKIAVtIAah8A8sQA6yEFAu0AtxcAW4AAG7gFuaoADT4ANQQAmScAMQ wBfyEAXwhgAWkA8KQAmhoACuYAiX0AOhkAGe4AMEcAc9EAW1AG+UEAF64AkQAAWrsAS2h1q45wgF 4AOa8A+hoAOMQAt5sICecIS7RgI+kGsY2A3EcIQWAGyzsAQv8A/lkHoFIA95sARWRlxL9QQYhoEk 4AKuAAEIcAWd0AZIIAn/kA0KMAtP8HyAYANtEAa18Fa7EAce8AnT8AkbQAxh4ALBcHIv4A5P/4AK sVUOcVAMFfANtFAAV6AOEDANpyAOG0AJPVABUPAPFsCJo9ADlBAEhfgPUEAL3YAE8vAPlAABT9Bd VjANbVAMT+ADCqAFp0AACrgESAAET1AAn8BkLLdqeeAIxPAEsfgPiuAK05B1SBAHUIh8JLCMZ+AO tNAGNjA0PQAEzqAF4uAB/1APNjANJDAK/KABZdgIcagALAABrqABFcBcsWUE0+AOeWABlFAPERAF TWAE/wAIngAEmCZUJEBvtdAJl0AFovaA8tADqDADo9AHAhEBTUBZTfB/KUBs91gAcXAJGBkKesAI 7xAGnQABNtAJ5liKNiAGLlgPGTANGeBdFv9gA1QgCqIwChUwC7HIDqtADKMABKLQBJaWjKzmCD7Q DVOIhIdADiwgBm1gjce3d/xgA+LQCytpBNwSjstVjgpIDlTgArpQVWXIAt8gBQ1wBbtQc/wABGKA COslDyNQBVIgBu7wDrJAAgRpkAipahCVAE2QCgmgC1qQALUQWvgABZEAdSyQAjSDCwVAA2FQAJGw XpegC2/liksQW421hsEQcK4QBwIxAhYQBEbQCp6wl0DwCQOBBsmgAETpAiQAAVqDCFbAAESpXck1 hD5AA1Hwf/+wChlgBKggCodwjbwGD71AAp8ABR1gAXQJluRojilQABv5h05QhpGQDJIJgLP/4Aw3 AAQQwDkecAgFEA+bQAMulQp+WZAHmZAQdQkBdQm95VsJQG5QAAGfAEoQYI7/oGM04AN0uQEaIFOg RQI2sFgp0AlrmGlLgFv/wHwFIHHzlKD4IA9HOBC4wACMMA5L0Ad0ORA5wAAkgGqsNYTEkAqzIAba lwP1AAFU0AvLyYrk0AROgArEMAKBIA+uUADgGAVhiZ0FQAWHVYYm0AoyYI6aoAfyxwgQwA7/YARt gKTB0F/BYAzxCZj06VbioAWGAAUZ0AaMEAWn0AafcBIbkACiYAB06QEVIAuCeXgpwFgyUHOXAFEk 0F2k2AamVgFOoIi1QAujcAg94AHa9w85/5AHnLUEepB4uCAQ7NBvQQhZwBkGGtALEXCa1ZAKUXCj V2AD62gDLPAPETANVmh8AVmk/5CdWNmOZZgCxqCm3PIC8UADJEAMmQkF4kAFlmZzutCXf+kJNSeY bpUAm6AAuEAMu1ABwSBll2CO2bCJBeAI//AKxACX/GAIJHBldjhiyFUBVJAHgOaHFdBzb1aoxgAE UXAJnpAMdtEH3RAGqeCu4uB8JyEFrnCphqVqs1BjeeAK5XkI5TAFn8AIFeAKYnCEjeAOrsAIN/kP CoAEUdAKKmEEUZAKo7ALXfiwveBg90qQ8CgKS0CcAVkMS/B8U9AHbdBpJKAF0Dac2UoM3f8gpobV BJtwBqmaiKClAU8QeMXpCt3QqaQYBSRABUrrCpJgMhuQD92HTDglYHY4DVTQBEAgs+LQBwVwCpSG BJ2ABwjwCW3QB1Dal20QBeaoY0m5oq71CTCQk+TAsVUAAh0mYwogHQ2gAAVwkQLBAhkwAsnQhdmQ AeSwC8Rwp+xAAORQAWJVAe4gX6SgA+6QU7GFqu6ACjaAraHQB56gB2JgARGQCk8wsRnQCZ5gA55V VhrgDp/ADlzrDs0lYzIgCSqRYxUgA10IjWLwua1gAd9AnBsQBz7gCZ8QAWHgCZP6CgzgA3qgAz0Q gsmgCNHVCZ0gD1OgCEB7awVgveTQCib/sAHGpaKrRQUMsAEe8AIjkAeHBgEMIIBNgHOwBwVM5w4V EAShQAmOkAH5oAceoAmRYAOeYASm5wEj0AMFoAVhQAyr8AKwx7PuEAU+sAGxZ3QMuwGvgAN4AAIv IA8XSgKHAAUmYAIdEAQEQAKsqwV90AFQAFgEsATjkAqdEAHoC3svIAVRUABGcAUmkANX4AFVMIka EAGOkAMyCgVB8Am6IKUvkAPYcAdQsAFSQA5RoAB4AAXp2wHXJ2jFoABXgMUe0AGOYAGXQAv+alhU RQ7u0AkyUADvYI+GoHLtSA7d+w7fIGxS9g06EAfk4Ao0QAMVcAhigA+dYAPu1gkFYAOW/6YB48Bg 1pvIQdUEM/DIM+AEGysGoKSXvSDJ40AL5BAHBBAHNhBWhaXGneAOhixWWiVsnVABiOwOq9YEMfmf BoAPotDJS1AAegBKBiAOs+BbjDADYvAJEKAHMjALJBAM4mADcaAACkC5jCBaLnAJBXAIzizKR5mu 5FUBu0AFKUcDWkVVDvZ13jxPTTAKoKYF1wbOVEULqEACM2BoVEALf0xk/WVof2xO7jVpSuteJ0Vp qAAE5RTOhEUFS8AIneZgbhUGf0wDS3ZpQaUFSjvRXjcDlLYEUcAIJCALhOUCCrYJIL0JWsBQEb1M YzYKMnWYJIDQAi2AWwWfLJ3QQPWvbP/FDzyVUuJAUzkNVTutmCgVamkF1DqtUuJQ1D2N00bNVket Vj0t1D3l1Iu21CeFXDtd1DQF1FbNVg291Vzd1V791WAd1mI91mRd1mZ91mid1mNtAGzd1m791nAd 13I913Rd13Z913id13q913w91yXw14Ad2II92IRd2IZ92Iid2Iq92Izd2I792IYdDZI92ZRd2ZZ9 2Zid2Zq92Zzd2Z792aAd2qKd2f5Q2qZ92qid2qq92qzd2q792rAd27IN2+hgD75QA7Od27q927It BzVwAidQA3LA28Qd2ycw3MWN2svwA4mgDMid3NAd3awtB4nQBRzAAV2wDLCtAtK92ir/8N2lXQIq sNzcHd1HwAUA0ALWYAnd3d7drQKWUAZewApJoARscAStLQfUUN7ubdolUAPtUNohUAYtQAYhIAHS TQgY8A8oEALowN/9HeGzzd3cwAFDgwWWgODIfQL47Q8lcAS3wAY/wAynLdynPdxycAKlLQcoftyo LQeWoOL+IAG+sA25gA7+EALSwANkcAum7dsy/uMt7g/PDeTITQdFAAN1EAL+AOES/uSuTeH6ILZ2 MASWMARDcAIhYOW4LQdHAA0T8AMhUAL+YAkZHgIqfuWW0A58YAlysOW/beVu/gNEHgJyIAEhgNs1 AAZKsACQUOf2YA9N7g8nwN41kOUS/6DlQ1ADV87opn0CQ9AO6LDoeC4ISs7kTg7lmq7aJSAHJYAZ XOALXCAEG4Lef1AG1EANanANgfAIdtAO1DAAvzIHX6ACWHA3ibAClXAcwwANiSAAEyAEhIAOJ4AM RYACDoACYDAE8UJApcABA0AGF7AANaAC1MALpVAJDbMNlhDtw0AqcDAB50AI/nAEX7AAFOAAhcAB kz5HSz7omx7vnO7poD4E7ENAWGAL1+AAEmAJHzAF6wAKXUANnNACHwAG66AEXTAAO2ACc6AEeNAF ZIAAi7AHC4AZGEAHbPAGlcABhfAPbkAHJRBFtjAA26AMK4AADU4NHOAFGJAIZNAMSv+QCNsgBP+g DUxwDkAWAHSQLBfQBVGEAc8wBO6O6fJ+9Kfd6Z+OAFwQAnTQAf9wDiIQAniADWwgAmzADi0QDkNQ Ai3QAmzQBRewBgsgAgDQAEUQAokQAmDQABOADJhABgwuAvuABgOACWPwD8Pg9Db/ASIgAZDQ9jEw BHzgKF8ACZAADv+AASLAAeXgBUcgAgu+ByJwDhNQAnH/D0LAB0R/6fCO9PIuARJA70wfAiEA9ZxA B+gwAVMABpAwAA2wBokQ+NmwCOAwBgOgDMtACH+wBiUwBPYQArD/B7cACXk/B0MQDregDAvwPeBg +m4Q9Rlu7w0QA3TwBeuQA7ygCpb/AAoMDgld0AwUwPl5fwEHbgkcgAHfI/Sd/+6ZDvpPLvqkDwpD cPr/IAh0oAITUA5gABB0BjRYkwgSGHUOeIU4YklVDQA7uviSEGKgF0J0MPybMyTEuTegNpoLEcLW vwUh/D0bWIkOr3U7ElGjtuUfiiFdpgCwBGnMP1sh+AjBU4TMPwy+6AiCUUelCn9RpU6lWtXqVaxZ tW6NKkGCHG54/gmCRIfIvyJ0VE2A0UXEgEAtmEHisGgdBxEOS4QAkAQMpBJDwDQAEELEzzkiTP0r hInJPzN0Qgj494GOnCED/4io4aDZAEhDzv0jQ7dZ4SFHV4g4+gETtH+PyhaBMYcO/zqoXHXv5t17 qtcTbNb8W1GCFwWgNboMx8JncLYiXQhtnGBnwIJ9ud78O7cMGbUP/1p0qWHu34R2sP4pwYCCXQ7Q pf4NA9MlRPgWA56NUfeHAwc8AAjnCE7EY8OSs0BAZph/KBDCi3LWYIMa2CboQo7cfNNwQw4lQEeO BYYpxBs77BimDgHYsCOTQvawTwgevCCDGUswQMOBSsjIRRoR1QDlFmWYKGSOBdjYo5BC7OjCCx4u 2EYQNBag6w8HYtjiB2jqGIaJXCwR5A4A+iHjB184EALJeThwo44H7GBDCW3cSIQMNATJZYVChllA gnY49PNP3ywJ4YSojmAoKkEJDf+nhmWWieqEEErIZZkTTpAjUX/k8OcES2qQowRIj1BB1GhqMLWE aEaVY1I55ODUEk0v/YEDZQaNSo4QLIGqhhBq8MfXZRqypIRHe9UUUGSTxarVVm9tNtNnXW3n2E0t dfZZaJtl9lZCb5Vq22ypdZVaaDMt91Fxp8JWWXbbdfddZSWAV7dK67X3Xnzz1Xdffz5k9l+AAwb4 w331xVBgOdBBp2B8/UX4XxUWZnhiivfd5mKMM9Z4Y4475pgXf34oYWSSSzb55JGXkZcXXjzWmOUS vljm5GiWadnlbVhWGWWUv1ChUZyDFrpjB4o2+mikk1Z6aaV5EGKLPZiQemqqq7b/eupKmG5aCSGA AcZqDCjgQeuj/7j66j2wmMeBscl2+22l/5F7brrrtvtuvPHeYYAVUBjmb8ADF3xwIipBIO+8vVBj 8L9bQLzuFsxgnHEu/nj8cswz13zzvBGApgw/zOhndNJLN930CyqZ4h8cNl+kEAHokZ30C7Zr/XIv LpB99tOJ8AMLQa7hfHjii+d8BzuY8ON05pmHBYVmWOc8991pt/3yayjQXXYBLrjA9GH2YGMC48s3 //x/DgegjANEb/79fi6IIfrbNU+iDlt47weW6x9vYBg1yM4WFHgDBYgggNGZIQtbEAL6HPjAzB3u H2MoQhrcB7/TyS8Q0jveA743/7r27YCDiHOAAAYRPwBs8BpKcIM36JGGfZSBFRCkYQ3xZoIBlCIT 9MBgBtPQgBFurgWDsEY/4AALJWQOBpUwoTX+sDq5TaESbngALNjgBRtmUYv/qEQXrPGAHqLuAUkI 4ubeQA8B2AIOi1BiHdxwAS9go26BUEIMBrCRLeYRgjBYQBmycMEwXsAMbKwf5xCwiBa0YBESxNwa /sAD4d1NCAOghB4t6cAkgAIUfyRCGPuhhn6so3iTSB/dGPk4dcxNgqScWyUSQb5LxtJ82gjAPP7o yX4IwHGyvNwb2AAAXgazePlZQBZwaYvtCBNvPCgCck6pTGji7XA8sEMxw2gGW/8AM5p0W8MWUPCP SRRym+OUmwQdEIAxGLOT8LsACmDwzFiy8h9vAAM45iZOcuZznvPAgB/AgcEDHGA428TDABgET30m tAW1/CMgTXcMNQAABqXk5eEmsAVtJlSjdmtBEcrQjzTwkHnHeIQA6rDLYFKAC0kEpzw3mtDD7YAL XViBlt5nhguAY6A44KkWe0oJIUCplJNw6UvzKcEkYOEHY4jB8hDIPDUQAQ8IteE5BSFCo2a1bqSo xBYGIIRhgJF5BxCAACigSCjasAGFKMIwNqhVuNJtEbYAAyeskQY4nO4Aj3jEBdRghkq0IBBULR4d F7ACrMqtqHE1Kg8EkQhTHCPrC3llXlkvcIAHeCGt5UPABIoQgDswVrR2C0QlrDMPa2ThAQ4lHRxq GsnhSRABSlgAF4iQ2NHmVm7sUAIZBiCIFZhBuHq9AEuLlwQZCaISuNVtc+XGA2iAgQtMgIUasnAP 2F2gEG9YHQK8+13w8rSnc6OEA9wQgA/cIXrOZS/k6kAGLnABC2MQQmAJizeCnPEDHyhuOdr7X7uR ogVeEAIXwCCIOgDAC29owQ4aEAgIN8AEizBBC94AAHCQQRAfgAYK8MBGAIeYdYW8RhIcQAEzjEEQ RfBqfONrhy14tQhYOIcQ5qCEFgDxniIOCAA7 ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Description: image001.gif Content-Id: <3243758-220021041023427700690@cc2181633-a> Content-Transfer-Encoding: base64 R0lGODlhtABkAPcAAOPh3Ly4sdbSzLq1q3N5iEZUbFhgcNnSzf7+/jlFZXqDksrEu4CJmfn5+O7s 6drV0Gt1h6SqtbComero5OHe2TlIZJ2kr9XRys3KwpObqDZFYsjM0rStotPT0tLV2sXBut3b26mi laWcj7zDyS09XLConPX19K2lmN7a1N3g47Cmm9POydnd4fHw7jdHZc7R1vz8+t3Z0kJOZjVIYi8+ YKykl0pXcDhHYv///PHx8WRtffX08u/u6qqwuVJddK6omys7W8HFzNDNxqmhktXTzsG9tbW6w6yk mBcpSfj49ujm4y09WNDLwi5AXDZHXyQ0U9XY3Ss6Vo2Vovz8/C8+Xbm/xcjJz+Pl6MbBtt3WzzFB Xby4rcC8sbWvpObk4LCon7ayqTJBYVtleszIvsrGwL+3rdjUzsTJz+3t7NzX0dfSyvPy8Lmxph0w UNLQyezr59rUzmNvgq6mmdvY0qefktvY1MG6sObl5erp6F1ngVdjdtTQxqyhlYiRn9vWz+Xi3+vt 7vv6+cO/uNnTyqqlmdnW0zRCYV9qfe/w8bGsn7O3wPf29Co8WeDl59/i5djUzKigj+fp64KJlv3/ /vb3997c1qujlTlGXp6WiNvYz/Lz9C06XcG7tT1LZVVgd3R+jsO+tPP19SY6Wi9AWvv7+dHNwcnD tio6XS86WzNEYa6kmK60vvb384WNnCc2VO3v8NbPyPz/+zJBZCc5VS5BYDhFaNPQzKqimOjr7LWs nzVDZTRCXrCqnyk3WaqkkjVJXtLKwDdHZ/T4+dnW0E9ccSo8XjFDXtrUyq6mnLu/yLOqn7GqnKyn mPz7+zNFZayiks/KxbKpm8W+sCEyUK2ilzM/WNfRx/39/f79+/r6+/L08LGpn6ylmiM1V9fTyzpJ YNfWza2mmjpGYjVIZ0FPafv8/NrVzMfEv6+nl9vPyPz9/fTz8/j4+K6lmUVRbjtIZzhDZz1DYpef q8jAt9jTz+Xn6aymlNzW1DRFXTZDWaqknMvBuzdGY9jTza+nmv///yH5BAAAAAAALAAAAAC0AGQA AAj/AP8JHEiwoMGDCBMqXEgQh0OHAxE0MMGDggAhCxaYslOmDKcPGB6hADBhXQOCCBAwXMmypcuX MGPKLLhuAgpoggJsCcCFywdBGS8ooVCHiJAxY7iA+iDAC48kEWdKnUq1qtWBSbysKMNmgJ0FwPaY y5RpTho/dQIZxGbCwR835wR9MMMDx9W7ePNKnVQQQYt+AxKVAQarn9k0D8zQW2zGlpJ/KRNOnACN kxAHKvVq3sx5IF+BgZQIArNljBo4ic30o6e6n+tH9B4sOsj3M0FKXvZAuwP1n+3OwIPLTAJg3wAs YjO1ds28+SMBKKbE9DIPCwC1wrNrZ3jtDxcwC9Sc/6W3urn517YAZG7JF1sMYKDOvdlOf/ukzA4E DTAlfhh5egcIIIAZBzj3yCPe9GMLHjJNAcIB5oxRhC3r1GdhZyo1M8cWC/STGHODqHEACigIcECB ryHozQoUwCATDChc4CEcC3AyR28X5njXDucMYE0a/QjgmhkX2EKEEs0E8oeMzJkhoACFmDBTIHUw aYYfanDBCQ86djlTZncodUAW5g1YyQ4DdTdgPwFSwMMaUE3yW0vsFMJkPx0UksU8A1DA13peBroQ AjEMMAYccByw2GIXALCIOv9gg41KO6ghZD9CETRnSyZ4k6Bri8GRBgZgkDEbDrHYJeiqBU1hSxmw PP8Q5KL0XNAiaJX8odIEhbl2gRdUNQPAneb5cQEYA3C5KauBNoBBGd5k4poAi9qKHQJ/CIFCM/94 0asZe6jXEgJJOIBjEpVcAMdy5j3wgB1dOAAZs4KqlMQHAwxiDhHMLQbdSQI5QISIa/zDg4wm7qGr SwCsUAeaiBSyxyAonufaMFnYAQaX9HpJKShlIGoeoxRcI1ALAir4GDvDqKGGG3VQ0hI2OFBgiy1v vGELsRYz94AfRQzQwj+xxNJxjg1wMoDIIy9KgRcAFJIytfO9QQQRFMi8EnGVUDCHGWZ8TQS7PTf5 QBEBSKnq0fTFskAZDwzzaXOLHnDBBSlPizNklJj/QEpLSqzghhBjO1l42RbTk4YdReDI9naZdHHM A/wmHmo/TGNaSDYvqRTIHG48LTdriyFusQBwZBHAOdjM+7hwXnQBzDCmWxxi6CavBAMrDaj0xgoA kIIABXsoWnvZDwgARh2vZ+dAFwuQeTxzAlxgxjCVsMKSCZWsMME/16TL8R/Fkzf9eWY8sMIADDbf WTNl2JHFI+ffLUAlcMIA0aANq8FlDgJYwdD+AQBrwMF85zvPAz5gB4C5Dy+fAccAsgAH04ENbAIg wh92kLt/rO0gEpnC8PA2tDsIYRjaQ9ncEmixLJRhDB184F3WEQAh+KF2F7QFCtYAKIa8oRCVaIEX /2whgPk0AA2zYUUaeMbCdqWDDZWQYV7cgIWz+OGKWMziFdPwtTnM5iUTuIC+6jCMIhJkDSi4khbX yMY2+uEBKCgFKFwkRas4AAtZIJEe98hHEmUvJggAQAz0SAHtIWANXshEHxfJyEaSiAKmQIGOGEDJ SlrykpjMpCY1KQkI6IAAoAylKEcJyk9IYpOolIQCRKkASaiSlLCMpSxJ6UlU2vKWuGQAEHbJy176 8pfADGYwTwEEGmyCBMhMJgmA0IteuMIVx1wCMoVJTSCcohjYROYmiFkMZXrzm+AMpzKLwYgmUIGY 1UynOoXphHa6851OwMcotEBPY8ATnsag5yjsef/Pfs7gBjMIqEBnQA4bFMATOngHPn7Rz4b2kx8Q fWdAm1DOXwz0osZghDEuytGO/hOiN3CoSEdKUngm4KQoTWkC3vEOQ6RCA2HQhQtUmoBg6CIMhtAA S2tBU5Xe4Kc3gKhQ8aGFVmzAEdpwBDnC8M+f9vSpKRUqUG+gAQ0Q4xA20MBPhQpSe/qgAPjQAFfH SlZ+DHSmUE2rWtca1bLywwVU0EMQXnCGDVhgF84YawJoQI5VbOAMQYCAFlzg1sIKVQPkEMMV/nEF GYTBsJA9LERdcINU0KIJq9BEBjaRCkMI1QUu0EIFquCIOEQhsqhNrWpXW1gNdEIHVhBIMz4xC7L/ PoEBAgEEBDrhhBmwlqtNQEUQ/uEIGRhCHL+FqAa0oAHCvjUVMugEEhSAAAW0gRydaO5kXaGAf2iC GIxwbnLHS17WOmMaceDcPzawCy1wVQu72IBAPLCLTYzDtyAFrXi5egPnbtUJYUgGcY2LXMOCNqif TQUVbEAOsfLDGSRYBRQO0Ykq2OAQLJAHEAgrDlpEYbjC+IQrCttfypK1xPudLGgLq98Uq3jF5dWA OEjgiXpQAgeU+EQvIjqDXhBgHX/zQCe04IRL1LQCYZAmFVKx4gTAlBburQAtltBOGlRhwJ7VRSrw oQt4JCCo/ZUFEJYQhgT8MwGymIUCPOCJEddC/xf4MEIKXpCBKmTgBSmIAHMhWgwIOEJmZ7hEGADK Xw1QAZmpCGoCxFEBF9Cgmxt1KmjDgOgK8OMGJ220IagAhCW7wAn8SIALkJxMY1AWwb9NAD+WkAcP 9EAlZ9BCKi6dijAoIgiA+IeQmxBUF4QhCs4oQAHIIWsXjKMYoqCFE75Ri028gxw51cKVi5vTQzNi CYb49A1qUQxjGNQYpwCtIVzRimyEghjTSMU4+OEEGbyjGhEQhhTE0QlyCPWlZ5CCfBsQByCY9bOy 2AQ5iOEOKhQDtGg+xTuIUYBqRCGg43AGI1JhUC0s4QbrroAuTrELYcuACjQIxgxc4IxT0MDjWv+g AU/Hq2pWQ0EHjfhHMyBAggo0+xMvgECud32DYIyiEwoYARQawYIIDLkCDFjFCF5gBHgQAAopgAAj qDBtGURBD6vogSJG0Ipd3AAfNIDACILAgjNAABWy0IA8OMeKKijiE9XoLw2a0Icg6GADDFhCEyZL BR144BIWEIg8whvQqlLBHRbwQBA2YAQxjGIcNBBHKzywgRfYnQYzyOcngkB2uy/BGS7YxS4+YQUP eIAFQdADDcYhTwgEAQpQYMELdEADF6e25XlohAykIJAqoOIG4thEFSxAjBzouhN7R4WfgyAGH6xC IJKYRQJ8IAWZpUAejnjFPxjgCqoPWAvuMED/FbIhDxvowhCokIc6eiAOCGgiG33oxTj0EFtEKOAQ xMh2VZ9vAST04B/yQAUOtgSKIAVtIAah8A8sQA6yEFAu0AtxcAW4AAG7gFuaoADT4ANQQAmScAMQ wBfyEAXwhgAWkA8KQAmhoACuYAiX0AOhkAGe4AMEcAc9EAW1AG+UEAF64AkQAAWrsAS2h1q45wgF 4AOa8A+hoAOMQAt5sICecIS7RgI+kGsY2A3EcIQWAGyzsAQv8A/lkHoFIA95sARWRlxL9QQYhoEk 4AKuAAEIcAWd0AZIIAn/kA0KMAtP8HyAYANtEAa18Fa7EAce8AnT8AkbQAxh4ALBcHIv4A5P/4AK sVUOcVAMFfANtFAAV6AOEDANpyAOG0AJPVABUPAPFsCJo9ADlBAEhfgPUEAL3YAE8vAPlAABT9Bd VjANbVAMT+ADCqAFp0AACrgESAAET1AAn8BkLLdqeeAIxPAEsfgPiuAK05B1SBAHUIh8JLCMZ+AO tNAGNjA0PQAEzqAF4uAB/1APNjANJDAK/KABZdgIcagALAABrqABFcBcsWUE0+AOeWABlFAPERAF TWAE/wAIngAEmCZUJEBvtdAJl0AFovaA8tADqDADo9AHAhEBTUBZTfB/KUBs91gAcXAJGBkKesAI 7xAGnQABNtAJ5liKNiAGLlgPGTANGeBdFv9gA1QgCqIwChUwC7HIDqtADKMABKLQBJaWjKzmCD7Q DVOIhIdADiwgBm1gjce3d/xgA+LQCytpBNwSjstVjgpIDlTgArpQVWXIAt8gBQ1wBbtQc/wABGKA COslDyNQBVIgBu7wDrJAAgRpkAipahCVAE2QCgmgC1qQALUQWvgABZEAdSyQAjSDCwVAA2FQAJGw XpegC2/liksQW421hsEQcK4QBwIxAhYQBEbQCp6wl0DwCQOBBsmgAETpAiQAAVqDCFbAAESpXck1 hD5AA1Hwf/+wChlgBKggCodwjbwGD71AAp8ABR1gAXQJluRojilQABv5h05QhpGQDJIJgLP/4Aw3 AAQQwDkecAgFEA+bQAMulQp+WZAHmZAQdQkBdQm95VsJQG5QAAGfAEoQYI7/oGM04AN0uQEaIFOg RQI2sFgp0AlrmGlLgFv/wHwFIHHzlKD4IA9HOBC4wACMMA5L0Ad0ORA5wAAkgGqsNYTEkAqzIAba lwP1AAFU0AvLyYrk0AROgArEMAKBIA+uUADgGAVhiZ0FQAWHVYYm0AoyYI6aoAfyxwgQwA7/YARt gKTB0F/BYAzxCZj06VbioAWGAAUZ0AaMEAWn0AafcBIbkACiYAB06QEVIAuCeXgpwFgyUHOXAFEk 0F2k2AamVgFOoIi1QAujcAg94AHa9w85/5AHnLUEepB4uCAQ7NBvQQhZwBkGGtALEXCa1ZAKUXCj V2AD62gDLPAPETANVmh8AVmk/5CdWNmOZZgCxqCm3PIC8UADJEAMmQkF4kAFlmZzutCXf+kJNSeY bpUAm6AAuEAMu1ABwSBll2CO2bCJBeAI//AKxACX/GAIJHBldjhiyFUBVJAHgOaHFdBzb1aoxgAE UXAJnpAMdtEH3RAGqeCu4uB8JyEFrnCphqVqs1BjeeAK5XkI5TAFn8AIFeAKYnCEjeAOrsAIN/kP CoAEUdAKKmEEUZAKo7ALXfiwveBg90qQ8CgKS0CcAVkMS/B8U9AHbdBpJKAF0Dac2UoM3f8gpobV BJtwBqmaiKClAU8QeMXpCt3QqaQYBSRABUrrCpJgMhuQD92HTDglYHY4DVTQBEAgs+LQBwVwCpSG BJ2ABwjwCW3QB1Dal20QBeaoY0m5oq71CTCQk+TAsVUAAh0mYwogHQ2gAAVwkQLBAhkwAsnQhdmQ AeSwC8Rwp+xAAORQAWJVAe4gX6SgA+6QU7GFqu6ACjaAraHQB56gB2JgARGQCk8wsRnQCZ5gA55V VhrgDp/ADlzrDs0lYzIgCSqRYxUgA10IjWLwua1gAd9AnBsQBz7gCZ8QAWHgCZP6CgzgA3qgAz0Q gsmgCNHVCZ0gD1OgCEB7awVgveTQCib/sAHGpaKrRQUMsAEe8AIjkAeHBgEMIIBNgHOwBwVM5w4V EAShQAmOkAH5oAceoAmRYAOeYASm5wEj0AMFoAVhQAyr8AKwx7PuEAU+sAGxZ3QMuwGvgAN4AAIv IA8XSgKHAAUmYAIdEAQEQAKsqwV90AFQAFgEsATjkAqdEAHoC3svIAVRUABGcAUmkANX4AFVMIka EAGOkAMyCgVB8Am6IKUvkAPYcAdQsAFSQA5RoAB4AAXp2wHXJ2jFoABXgMUe0AGOYAGXQAv+alhU RQ7u0AkyUADvYI+GoHLtSA7d+w7fIGxS9g06EAfk4Ao0QAMVcAhigA+dYAPu1gkFYAOW/6YB48Bg 1pvIQdUEM/DIM+AEGysGoKSXvSDJ40AL5BAHBBAHNhBWhaXGneAOhixWWiVsnVABiOwOq9YEMfmf BoAPotDJS1AAegBKBiAOs+BbjDADYvAJEKAHMjALJBAM4mADcaAACkC5jCBaLnAJBXAIzizKR5mu 5FUBu0AFKUcDWkVVDvZ13jxPTTAKoKYF1wbOVEULqEACM2BoVEALf0xk/WVof2xO7jVpSuteJ0Vp qAAE5RTOhEUFS8AIneZgbhUGf0wDS3ZpQaUFSjvRXjcDlLYEUcAIJCALhOUCCrYJIL0JWsBQEb1M YzYKMnWYJIDQAi2AWwWfLJ3QQPWvbP/FDzyVUuJAUzkNVTutmCgVamkF1DqtUuJQ1D2N00bNVket Vj0t1D3l1Iu21CeFXDtd1DQF1FbNVg291Vzd1V791WAd1mI91mRd1mZ91mid1mNtAGzd1m791nAd 13I913Rd13Z913id13q913w91yXw14Ad2II92IRd2IZ92Iid2Iq92Izd2I792IYdDZI92ZRd2ZZ9 2Zid2Zq92Zzd2Z792aAd2qKd2f5Q2qZ92qid2qq92qzd2q792rAd27IN2+hgD75QA7Od27q927It BzVwAidQA3LA28Qd2ycw3MWN2svwA4mgDMid3NAd3awtB4nQBRzAAV2wDLCtAtK92ir/8N2lXQIq sNzcHd1HwAUA0ALWYAnd3d7drQKWUAZewApJoARscAStLQfUUN7ubdolUAPtUNohUAYtQAYhIAHS TQgY8A8oEALowN/9HeGzzd3cwAFDgwWWgODIfQL47Q8lcAS3wAY/wAynLdynPdxycAKlLQcoftyo LQeWoOL+IAG+sA25gA7+EALSwANkcAum7dsy/uMt7g/PDeTITQdFAAN1EAL+AOES/uSuTeH6ILZ2 MASWMARDcAIhYOW4LQdHAA0T8AMhUAL+YAkZHgIqfuWW0A58YAlysOW/beVu/gNEHgJyIAEhgNs1 AAZKsACQUOf2YA9N7g8nwN41kOUS/6DlQ1ADV87opn0CQ9AO6LDoeC4ISs7kTg7lmq7aJSAHJYAZ XOALXCAEG4Lef1AG1EANanANgfAIdtAO1DAAvzIHX6ACWHA3ibAClXAcwwANiSAAEyAEhIAOJ4AM RYACDoACYDAE8UJApcABA0AGF7AANaAC1MALpVAJDbMNlhDtw0AqcDAB50AI/nAEX7AAFOAAhcAB kz5HSz7omx7vnO7poD4E7ENAWGAL1+AAEmAJHzAF6wAKXUANnNACHwAG66AEXTAAO2ACc6AEeNAF ZIAAi7AHC4AZGEAHbPAGlcABhfAPbkAHJRBFtjAA26AMK4AADU4NHOAFGJAIZNAMSv+QCNsgBP+g DUxwDkAWAHSQLBfQBVGEAc8wBO6O6fJ+9Kfd6Z+OAFwQAnTQAf9wDiIQAniADWwgAmzADi0QDkNQ Ai3QAmzQBRewBgsgAgDQAEUQAokQAmDQABOADJhABgwuAvuABgOACWPwD8Pg9Db/ASIgAZDQ9jEw BHzgKF8ACZAADv+AASLAAeXgBUcgAgu+ByJwDhNQAnH/D0LAB0R/6fCO9PIuARJA70wfAiEA9ZxA B+gwAVMABpAwAA2wBokQ+NmwCOAwBgOgDMtACH+wBiUwBPYQArD/B7cACXk/B0MQDregDAvwPeBg +m4Q9Rlu7w0QA3TwBeuQA7ygCpb/AAoMDgld0AwUwPl5fwEHbgkcgAHfI/Sd/+6ZDvpPLvqkDwpD cPr/IAh0oAITUA5gABB0BjRYkwgSGHUOeIU4YklVDQA7uviSEGKgF0J0MPybMyTEuTegNpoLEcLW vwUh/D0bWIkOr3U7ElGjtuUfiiFdpgCwBGnMP1sh+AjBU4TMPwy+6AiCUUelCn9RpU6lWtXqVaxZ tW6NKkGCHG54/gmCRIfIvyJ0VE2A0UXEgEAtmEHisGgdBxEOS4QAkAQMpBJDwDQAEELEzzkiTP0r hInJPzN0Qgj494GOnCED/4io4aDZAEhDzv0jQ7dZ4SFHV4g4+gETtH+PyhaBMYcO/zqoXHXv5t17 qtcTbNb8W1GCFwWgNboMx8JncLYiXQhtnGBnwIJ9ud78O7cMGbUP/1p0qWHu34R2sP4pwYCCXQ7Q pf4NA9MlRPgWA56NUfeHAwc8AAjnCE7EY8OSs0BAZph/KBDCi3LWYIMa2CboQo7cfNNwQw4lQEeO BYYpxBs77BimDgHYsCOTQvawTwgevCCDGUswQMOBSsjIRRoR1QDlFmWYKGSOBdjYo5BC7OjCCx4u 2EYQNBag6w8HYtjiB2jqGIaJXCwR5A4A+iHjB184EALJeThwo44H7GBDCW3cSIQMNATJZYVChllA gnY49PNP3ywJ4YSojmAoKkEJDf+nhmWWieqEEErIZZkTTpAjUX/k8OcES2qQowRIj1BB1GhqMLWE aEaVY1I55ODUEk0v/YEDZQaNSo4QLIGqhhBq8MfXZRqypIRHe9UUUGSTxarVVm9tNtNnXW3n2E0t dfZZaJtl9lZCb5Vq22ypdZVaaDMt91Fxp8JWWXbbdfddZSWAV7dK67X3Xnzz1Xdffz5k9l+AAwb4 w331xVBgOdBBp2B8/UX4XxUWZnhiivfd5mKMM9Z4Y4475pgXf34oYWSSSzb55JGXkZcXXjzWmOUS vljm5GiWadnlbVhWGWWUv1ChUZyDFrpjB4o2+mikk1Z6aaV5EGKLPZiQemqqq7b/eupKmG5aCSGA AcZqDCjgQeuj/7j66j2wmMeBscl2+22l/5F7brrrtvtuvPHeYYAVUBjmb8ADF3xwIipBIO+8vVBj 8L9bQLzuFsxgnHEu/nj8cswz13zzvBGApgw/zOhndNJLN930CyqZ4h8cNl+kEAHokZ30C7Zr/XIv LpB99tOJ8AMLQa7hfHjii+d8BzuY8ON05pmHBYVmWOc8991pt/3yayjQXXYBLrjA9GH2YGMC48s3 //x/DgegjANEb/79fi6IIfrbNU+iDlt47weW6x9vYBg1yM4WFHgDBYgggNGZIQtbEAL6HPjAzB3u H2MoQhrcB7/TyS8Q0jveA743/7r27YCDiHOAAAYRPwBs8BpKcIM36JGGfZSBFRCkYQ3xZoIBlCIT 9MBgBtPQgBFurgWDsEY/4AALJWQOBpUwoTX+sDq5TaESbngALNjgBRtmUYv/qEQXrPGAHqLuAUkI 4ubeQA8B2AIOi1BiHdxwAS9go26BUEIMBrCRLeYRgjBYQBmycMEwXsAMbKwf5xCwiBa0YBESxNwa /sAD4d1NCAOghB4t6cAkgAIUfyRCGPuhhn6so3iTSB/dGPk4dcxNgqScWyUSQb5LxtJ82gjAPP7o yX4IwHGyvNwb2AAAXgazePlZQBZwaYvtCBNvPCgCck6pTGji7XA8sEMxw2gGW/8AM5p0W8MWUPCP SRRym+OUmwQdEIAxGLOT8LsACmDwzFiy8h9vAAM45iZOcuZznvPAgB/AgcEDHGA428TDABgET30m tAW1/CMgTXcMNQAABqXk5eEmsAVtJlSjdmtBEcrQjzTwkHnHeIQA6rDLYFKAC0kEpzw3mtDD7YAL XViBlt5nhguAY6A44KkWe0oJIUCplJNw6UvzKcEkYOEHY4jB8hDIPDUQAQ8IteE5BSFCo2a1bqSo xBYGIIRhgJF5BxCAACigSCjasAGFKMIwNqhVuNJtEbYAAyeskQY4nO4Aj3jEBdRghkq0IBBULR4d F7ACrMqtqHE1Kg8EkQhTHCPrC3llXlkvcIAHeCGt5UPABIoQgDswVrR2C0QlrDMPa2ThAQ4lHRxq GsnhSRABSlgAF4iQ2NHmVm7sUAIZBiCIFZhBuHq9AEuLlwQZCaISuNVtc+XGA2iAgQtMgIUasnAP 2F2gEG9YHQK8+13w8rSnc6OEA9wQgA/cIXrOZS/k6kAGLnABC2MQQmAJizeCnPEDHyhuOdr7X7uR ogVeEAIXwCCIOgDAC29owQ4aEAgIN8AEizBBC94AAHCQQRAfgAYK8MBGAIeYdYW8RhIcQAEzjEEQ RfBqfONrhy14tQhYOIcQ5qCEFgDxniIOCAA7 ------=_NextPart_94915C5ABAF209EF376268C8-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Oct 11 05:26:00 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14930 for ; Fri, 11 Oct 2002 05:26:00 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-92.cisco.com [64.103.26.92]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id g9B9OVaW022570 for ; Fri, 11 Oct 2002 02:24:32 -0700 (PDT) Received: (qmail 1583 invoked by uid 1000); 11 Oct 2002 09:24:34 -0000 Message-ID: <20021011092434.1582.qmail@cobweb.example.org> Date: Fri, 11 Oct 2002 11:24:34 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: PR-SCTP and socket API X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am trying to map the PR-SCTP draft to the socket API draft. My understanding is that what is called "lifetime" in PR-SCTP is, in the socket API, member "sinfo_timetolive" of struct sctp_sndrcvinfo. Is this correct? thanks marco From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Oct 11 06:53:38 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16020 for ; Fri, 11 Oct 2002 06:53:37 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9BAcnaW022781; Fri, 11 Oct 2002 03:38:49 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI18745; Fri, 11 Oct 2002 03:38:55 -0700 (PDT) Message-ID: <3DA6AA3F.7040902@cisco.com> Date: Fri, 11 Oct 2002 05:38:55 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com Subject: Re: PR-SCTP and socket API References: <20021011092434.1582.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco Molteni wrote: >Hi, > >I am trying to map the PR-SCTP draft to the socket API draft. > >My understanding is that what is called "lifetime" in PR-SCTP is, in the >socket API, member "sinfo_timetolive" of struct sctp_sndrcvinfo. > >Is this correct? > >thanks >marco > > > Yes.. this is how the FreeBSD implementation works at least and is also what I had intended when I added time-to-live to the socket api draft... The FreeBSD side as another option as well .. which is a buffer constrained mode... So for time based you set sinfo->sinfo_flags = MSG_PR_SCTP; and set sinfo->sinfo_timetolive = milliseconds-to-live; The implementation is setup to transmit at LEAST once and then timeout on any retransmit.. There probably should be an option to not send at all if it is past time... our implementation currently does not do this ... sigh.. one more thing on the todo list... The buffer constrained one is a bit more interesting :> You do sinfo->sinfo_flags = MSG_PR_SCTP | MSG_PR_BUFFER; and set the sinfo->sinfo_timetolive = msg-priority; The lower the number the higher the priority. So one can do sendmsg(msg1, priority 0) sendmsg(msg2,priority1) sendmsg(msg3,priority2) sendmsg(msg4,priority1); And it will only kick into effect if when you say send and there is no space left in the socket buffer. In that case it will look in the sent queue for a message of equal or lesser priority. Note that no message will be dropped if it has not at least been transmitted once .. again something to do as well .. sigh ... In my example above.. msg4 (assuming the socket buffer is full and one would block/or get a EAGAIN) would knock out msg2 or msg3 (if they have been transmitted) but msg1 would NOT be subject to knocking out... Anyway the idea is that one can keep sending even when one is getting overloaded with how much buffer space you are constainted to on the send side... I have on my list to also write this profile up one day as a internet draft... but not for a while.. its way down at the bottom of the stack.. R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Oct 11 07:51:48 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17599 for ; Fri, 11 Oct 2002 07:51:47 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-92.cisco.com [64.103.26.92]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id g9BBdMaW019894 for ; Fri, 11 Oct 2002 04:39:23 -0700 (PDT) Received: (qmail 1823 invoked by uid 1000); 11 Oct 2002 11:39:25 -0000 Message-ID: <20021011113925.1822.qmail@cobweb.example.org> Date: Fri, 11 Oct 2002 13:39:25 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: Re: PR-SCTP and socket API In-Reply-To: <3DA6AA3F.7040902@cisco.com> References: <20021011092434.1582.qmail@cobweb.example.org> <3DA6AA3F.7040902@cisco.com> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 11 Oct 2002, "Randall Stewart (cisco)" wrote: [..] > The buffer constrained one is a bit more interesting :> > > You do > > sinfo->sinfo_flags = MSG_PR_SCTP | MSG_PR_BUFFER; [..] Randall, thanks for the quick answer, and also thanks for explaining the buffer constrained version. Actually just after I sent the first email I saw MSG_PR_BUFFER and had a look at the code wondering what it was... Marco From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sat Oct 12 06:14:45 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23626 for ; Sat, 12 Oct 2002 06:14:44 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-92.cisco.com [64.103.26.92]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id g9CADPaW027593 for ; Sat, 12 Oct 2002 03:13:26 -0700 (PDT) Received: (qmail 4158 invoked by uid 1000); 12 Oct 2002 10:12:29 -0000 Message-ID: <20021012101228.4157.qmail@cobweb.example.org> Date: Sat, 12 Oct 2002 12:12:28 +0200 From: Marco Molteni To: "Randall Stewart \(cisco\)" Cc: sctp-impl@external.cisco.com Subject: Re: PR-SCTP and socket API In-Reply-To: <3DA6AA3F.7040902@cisco.com> References: <20021011092434.1582.qmail@cobweb.example.org> <3DA6AA3F.7040902@cisco.com> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randall, a few questions and maybe a bug... On Fri, 11 Oct 2002 "Randall Stewart (cisco)" wrote: [..] > So for time based you > > set > sinfo->sinfo_flags = MSG_PR_SCTP; > > and set > sinfo->sinfo_timetolive = milliseconds-to-live; Looking at the kernel source, it seems it is microseconds, not milliseconds: from sctp_msg_append(): int sec,usec; SCTP_GETTIME_TIMEVAL(&chk->rec.data.timetodrop); sec = (srcv->sinfo_timetolive/1000000); chk->rec.data.timetodrop.tv_sec += sec; /* Add in the micro seconds */ usec = (srcv->sinfo_timetolive % 1000000); chk->rec.data.timetodrop.tv_usec += usec; if (chk->rec.data.timetodrop.tv_usec > 1000000) { /* add in the carry over */ chk->rec.data.timetodrop.tv_usec -= 1000000; chk->rec.data.timetodrop.tv_usec++; } It does a division by 1 million... also, at the end, when it looks at the carry over, I think there is a bug because it adds 1 to tv_usec instead of tv_sec... or am I missing something? Marco From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sat Oct 12 07:15:54 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24303 for ; Sat, 12 Oct 2002 07:15:53 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9CB5iot027855; Sat, 12 Oct 2002 04:05:44 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI48700; Sat, 12 Oct 2002 04:05:42 -0700 (PDT) Message-ID: <3DA80206.5080302@cisco.com> Date: Sat, 12 Oct 2002 06:05:42 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com Subject: Re: PR-SCTP and socket API References: <20021011092434.1582.qmail@cobweb.example.org> <3DA6AA3F.7040902@cisco.com> <20021012101228.4157.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco Molteni wrote: >Hi Randall, > >a few questions and maybe a bug... > >On Fri, 11 Oct 2002 "Randall Stewart (cisco)" wrote: > >[..] > > > >>So for time based you >> >>set >>sinfo->sinfo_flags = MSG_PR_SCTP; >> >>and set >>sinfo->sinfo_timetolive = milliseconds-to-live; >> >> > >Looking at the kernel source, it seems it is microseconds, not milliseconds: > >from sctp_msg_append(): > > > int sec,usec; > SCTP_GETTIME_TIMEVAL(&chk->rec.data.timetodrop); > sec = (srcv->sinfo_timetolive/1000000); > chk->rec.data.timetodrop.tv_sec += sec; > /* Add in the micro seconds */ > usec = (srcv->sinfo_timetolive % 1000000); > chk->rec.data.timetodrop.tv_usec += usec; > if (chk->rec.data.timetodrop.tv_usec > 1000000) { > /* add in the carry over */ > chk->rec.data.timetodrop.tv_usec -= 1000000; > chk->rec.data.timetodrop.tv_usec++; > } > >It does a division by 1 million... > >also, at the end, when it looks at the carry over, I think there is a >bug because it adds 1 to tv_usec instead of tv_sec... or am I missing >something? > > >Marco > > > > No.. its a bug .. it should be tv_sec++ .. I will get that fixed... and for some reason I thought it was milli seconds.. I stand corrected...need to fix the printf in the user test program... R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sun Oct 13 21:07:28 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27000 for ; Sun, 13 Oct 2002 21:07:27 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9E14uIm007888; Sun, 13 Oct 2002 18:04:56 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9E14t8V024365; Sun, 13 Oct 2002 18:04:55 -0700 (PDT) Received: from 19.06.05.14 ([62.59.72.45]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g9E13QmE004513; Sun, 13 Oct 2002 18:03:30 -0700 (PDT) Message-Id: <200210140103.g9E13QmE004513@proxy2.cisco.com> From: "R. Al-Mejrin" Reply-To: siiiprivate1@hotmail.com Subject: Contract Project. Date: Mon, 14 Oct 2002 03:06:14 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0d0e8e95-c75d-4b2f-bd52-cf95b108ac9a" This is a multi-part message in MIME format --0d0e8e95-c75d-4b2f-bd52-cf95b108ac9a Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable For Your Attention, (TREAT PRIVATELY BY THE OWNER OF COMPANY) I am writing to solicite for your cooperation in a multi million dollars = international contract supply for the Government of Kuwait. We are a small = company and a government employee that won a supply contractorship for the = supply of some humanitarian products, but due to the status of our company as = having no international banking accounts and registration to recieve the = funds, we are contacting you to act as our foreign partner beneficiary so = that the fund can be released to you on our behalf as a sub-contractor. For your information, the contract value was over inflated by 30% and the = Kuwait Ministry Of Finance approved the payment, so we would be willing to = pay you for your assistance by means of commission from the over inflated = sum. If you can be relied upon and trusted in recieving the funds on our behalf, = then please contact me immediately via my private Global Satelite Voice/Fax = Number: + 14136386967 and provide me BY FAX ONLY with your Direct Telephone = and Fax Numbers, and your Exclusive Email Address including full details of = your company and personal profile so that we can evaluate how to incoporate = your company as the fund reciever. Make SURE to send a fax with the above = details. As soon as I recieve the information, I shall contact you and = discuss the immediate commencement of the project. Thank you for your anticipated cooperation as I expect your swift response in = the above subject. Regards, R. Al-Mejrin. SII International. --0d0e8e95-c75d-4b2f-bd52-cf95b108ac9a-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Oct 14 07:11:40 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14378 for ; Mon, 14 Oct 2002 07:11:39 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9EAwvIm001485 for ; Mon, 14 Oct 2002 03:58:57 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9EAws7W009925 for ; Mon, 14 Oct 2002 03:58:55 -0700 (PDT) Received: from srv-exchange.RTX ([80.63.27.146]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9EAwsKL027337 for ; Mon, 14 Oct 2002 03:58:56 -0700 (PDT) Received: by SRV-EXCHANGE with Internet Mail Service (5.5.2653.19) id <4Q6VPPWZ>; Mon, 14 Oct 2002 12:54:40 +0200 Message-ID: From: Morten Laursen To: "'sctp-impl@external.cisco.com'" Subject: Association initialization Date: Mon, 14 Oct 2002 12:54:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi, I've got a couple of questions about association initializion: 1) The specification doesn't mention anything about what to do if you do not wish to accept an association. To me it seems reasonable to send an abort, but because there is no matching error cause I'm uncertain if that is not how it is supposed to be done? I notice that lksctp (in linux 2.5.41) send an abort with verification tag 0. Is it legal to use verification tag 0 when you know the peer's verification tag (since you got the init chunk)? 2) What is the point of being able to choose an initial TSN instead of always using 0, when we can use the verification tags to distinguish old associations? Thanks in advance... Venlig Hilsen / Regards Morten -- Morten Laursen, M.Sc.S.E. RTX Telecom A/S - http://www.rtx.dk/ Direct phone: (+45) 96 32 24 03 From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Oct 14 08:15:11 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16275 for ; Mon, 14 Oct 2002 08:15:10 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9EC9sot018844 for ; Mon, 14 Oct 2002 05:09:54 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9EC9rx4022669 for ; Mon, 14 Oct 2002 05:09:53 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9EC8WmE006064 for ; Mon, 14 Oct 2002 05:08:33 -0700 (PDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9EBobw12835 for ; Mon, 14 Oct 2002 14:50:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 14:39:37 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 14:39:33 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 14:39:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Association initialization Date: Mon, 14 Oct 2002 14:39:22 +0300 Message-ID: Thread-Topic: Association initialization Thread-Index: AcJzdJOjw2ANBaTDRti+inyENWnTkgAAFRXw From: To: , X-OriginalArrivalTime: 14 Oct 2002 11:39:33.0398 (UTC) FILETIME=[5DA14360:01C27376] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA16275 Hi Morten! See my comments inline... > -----Original Message----- > From: ext Morten Laursen [mailto:MLA@rtx.dk] > Sent: 14. October 2002 13:55 > To: 'sctp-impl@external.cisco.com' > Subject: Association initialization > > > Hi, > > I've got a couple of questions about association initializion: > > 1) The specification doesn't mention anything about what to > do if you do not > wish to accept an association. To me it seems reasonable to > send an abort, > but because there is no matching error cause I'm uncertain if > that is not > how it is supposed to be done? I guess "Out of resource" is nice... Unless the reason why you don't want to open an association is closer to any other error cause. In any case you don't have to include any error cause. It will make life easier to the client though (for debugging purposes). > I notice that lksctp (in linux 2.5.41) send an abort with > verification tag > 0. Is it legal to use verification tag 0 when you know the peer's > verification tag (since you got the init chunk)? Well, there has been some discussion about this, and the new Implementer's Guide will include some modification related to this. I think the final agreement was to set the T bit of the ABORT to 0, but still use the Initiate Tag as the Verification Tag of the datagram. This makes that the meaning of the T bit changes a little bit. Instead of meaning "I didn't erase any TCB", it would mean "I send you the 'reverse' VT". However, these two definitions will always be equivalent except for this case... > 2) What is the point of being able to choose an initial TSN instead of > always using 0, when we can use the verification tags to > distinguish old > associations? In general, I considered it as an extra security measure for blind attacks. If somebody fakes your IP and sends some DATA, not only he has to guess the VT but also the TSN value... The SACKs will carry the right value of the TSN, but they will go back to the real peer... BR Iván Arias Rodríguez > Thanks in advance... > > Venlig Hilsen / Regards > Morten > > -- > Morten Laursen, M.Sc.S.E. > RTX Telecom A/S - http://www.rtx.dk/ > Direct phone: (+45) 96 32 24 03 > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Oct 14 09:00:19 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17955 for ; Mon, 14 Oct 2002 09:00:18 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9ECtaot002929 for ; Mon, 14 Oct 2002 05:55:36 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9ECtZUY012945 for ; Mon, 14 Oct 2002 05:55:35 -0700 (PDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9ECsFmE024188 for ; Mon, 14 Oct 2002 05:54:16 -0700 (PDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA02455; Mon, 14 Oct 2002 14:38:59 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA11360; Mon, 14 Oct 2002 14:38:29 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id <4RYKJLA0>; Mon, 14 Oct 2002 14:38:13 +0200 Message-ID: From: Meyknecht Bernward To: "'Ivan.Arias-Rodriguez@nokia.com'" , MLA@rtx.dk, sctp-impl@external.cisco.com Subject: AW: Association initialization Date: Mon, 14 Oct 2002 14:38:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA17955 Hi Morten, Hi Iván, I'm also re-using the 'User initiated Abort' error cause value, together with some cause spec. info, on SCTP level, in cases, where the reason for not accepting the association is related to some upper layer defined filter or configuration. Main reason for doing this is debugging. Best regards, Bernward -----Ursprüngliche Nachricht----- Von: Ivan.Arias-Rodriguez@nokia.com [mailto:Ivan.Arias-Rodriguez@nokia.com] Gesendet: Montag, 14. Oktober 2002 13:39 An: MLA@rtx.dk; sctp-impl@external.cisco.com Betreff: RE: Association initialization Hi Morten! See my comments inline... > -----Original Message----- > From: ext Morten Laursen [mailto:MLA@rtx.dk] > Sent: 14. October 2002 13:55 > To: 'sctp-impl@external.cisco.com' > Subject: Association initialization > > > Hi, > > I've got a couple of questions about association initializion: > > 1) The specification doesn't mention anything about what to > do if you do not > wish to accept an association. To me it seems reasonable to > send an abort, > but because there is no matching error cause I'm uncertain if > that is not > how it is supposed to be done? I guess "Out of resource" is nice... Unless the reason why you don't want to open an association is closer to any other error cause. In any case you don't have to include any error cause. It will make life easier to the client though (for debugging purposes). > I notice that lksctp (in linux 2.5.41) send an abort with > verification tag > 0. Is it legal to use verification tag 0 when you know the peer's > verification tag (since you got the init chunk)? Well, there has been some discussion about this, and the new Implementer's Guide will include some modification related to this. I think the final agreement was to set the T bit of the ABORT to 0, but still use the Initiate Tag as the Verification Tag of the datagram. This makes that the meaning of the T bit changes a little bit. Instead of meaning "I didn't erase any TCB", it would mean "I send you the 'reverse' VT". However, these two definitions will always be equivalent except for this case... > 2) What is the point of being able to choose an initial TSN instead of > always using 0, when we can use the verification tags to > distinguish old > associations? In general, I considered it as an extra security measure for blind attacks. If somebody fakes your IP and sends some DATA, not only he has to guess the VT but also the TSN value... The SACKs will carry the right value of the TSN, but they will go back to the real peer... BR Iván Arias Rodríguez > Thanks in advance... > > Venlig Hilsen / Regards > Morten > > -- > Morten Laursen, M.Sc.S.E. > RTX Telecom A/S - http://www.rtx.dk/ > Direct phone: (+45) 96 32 24 03 > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Oct 14 10:24:42 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21623 for ; Mon, 14 Oct 2002 10:24:41 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9EEC9ot003026 for ; Mon, 14 Oct 2002 07:12:10 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9EEC8GQ000726 for ; Mon, 14 Oct 2002 07:12:09 -0700 (PDT) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9EEC4UZ008825 for ; Mon, 14 Oct 2002 07:12:04 -0700 (PDT) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA15790; Mon, 14 Oct 2002 08:57:51 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA43758; Mon, 14 Oct 2002 09:05:31 -0500 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id JAA25590; Mon, 14 Oct 2002 09:05:30 -0500 Sender: root@popmail.austin.ibm.com Message-ID: <3DAAC9F1.1B8BF880@us.ibm.com> Date: Mon, 14 Oct 2002 08:43:13 -0500 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.40 i686) X-Accept-Language: en MIME-Version: 1.0 To: Morten Laursen CC: "'sctp-impl@external.cisco.com'" Subject: Re: Association initialization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Morten Laursen wrote: > Hi Morten, > I notice that lksctp (in linux 2.5.41) send an abort with verification tag > 0. Is it legal to use verification tag 0 when you know the peer's > verification tag (since you got the init chunk)? Its a bug in lksctp. I think its fixed in a patch already, just not integrated yet. The patch for bug 611840 should contain the behavior per the impl. guide: --------- New text: (Section 8.4) --------- 3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT can not be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate tag of the received INIT chunk and the T-Bit of the ABORT chunk has to be set to 1 indicating that no TCB was destroyed. Otherwise, Best Regards, jon > Thanks in advance... > > Venlig Hilsen / Regards > Morten > > -- > Morten Laursen, M.Sc.S.E. > RTX Telecom A/S - http://www.rtx.dk/ > Direct phone: (+45) 96 32 24 03 From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 15 22:48:06 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21924 for ; Tue, 15 Oct 2002 22:48:05 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9G2kxIm005129 for ; Tue, 15 Oct 2002 19:46:59 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9G2kxCH026677 for ; Tue, 15 Oct 2002 19:46:59 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id g9G2ko2Z014891 for ; Tue, 15 Oct 2002 19:46:55 -0700 (PDT) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa18901; 15 Oct 2002 22:41 EDT Date: Tue, 15 Oct 2002 22:41:28 -0400 (EDT) From: "Armando L. Caro Jr." Reply-To: "Armando L. Caro Jr." To: sctp-impl@external.cisco.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: implementations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I am compiling a list of SCTP implementations, including tools and apps. I want to include the project name, author(s), affiliation(s), kernel/userland/simulation/app, OS, license, url. (I wasn't sure if both author and affiliation were always appropriate.) Below is an incomplete list I have so far. Please inform me (via private email) of any corrections or projects which are not listed. Also, if there is any other information that you think would be useful to have in such a list, please let me know. Thank you. Project: KAME Stack Author(s): R. Stewart, ?? Affiliation(s): Cisco Systems Type: kernel OS: FreeBSD, NetBSD, OpenBSD License: BSD URL: www.sctp.org Project: Siemens SCTP Author(s): T. Dreibholz, H. Holzlwimmer, A. Jungmaier, M. Tuxen Affiliations(s): Seimens AG, University of Essen Type: userland OS: Linux, FreeBSD, Mac OS X License: GPL URL: www.sctp.de Project: Linux Kernel SCTP Author(s): L. Yarroll, ?? Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco Type: kernel OS: Linux License: GPL URL: sourceforge.net/projects/lksctp Project: Solaris Stack Author(s): K. Poon, ?? Affiliation(s): Sun Microsystems Laboratories Type: kernel OS: Solaris License: Proprietary URL: playground.sun.com/sctp Project: OpenSS7 Stack Author(s): B. Bidulock, ?? Affiliation(s): Open{SS7} Corporation Type: kernel OS: Linux License: GPL URL: www.openss7.org Project: RivuS Author(s): J. Rane, N. Kumbhar, K. Sovani Affiliation(s): Pune Institute of Computer Technology (PICT) Type: kernel OS: FreeBSD License: BSD URL: rivus.sourceforge.net Project: AIX Stack Author(s): ?? Affiliation(s): IBM Type: kernel OS: AIX License: Proprietary URL: ?? Project: ?? Author(s): I. Arias-Rodriguez, ?? Affiliation(s): Nokia Research Center Type: ?? OS: ?? License: ?? URL: ?? Project: Playstation II Author(s): R. Stewart, ?? Affiliation(s): Cisco Systems Type: kernel OS: ?? License: ?? URL: ?? Project: Intellinet SCTP Author(s): ?? Affiliation(s): IntelliNet Technologies, Inc. Type: kernel? OS: independent License: Proprietary URL: www.intellinet-tech.com/products/sigtran/sctp Project: Portable SCTP Author(s): ?? Affiliation(s): Data Connection Ltd. Type: kernel? OS: Windows, VxWorks/VxWorks AE/Tornado, Solaris / SunOS, pSOS, Chorus, LynxOS, OSE, Nucleus, UNIX, Linux, and others License: Proprietary URL: www.dataconnection.com/sctp Project: ns-2 SCTP module Author(s): A. Caro, J. Iyengar Affiliation(s): University of Delaware Type: simulation OS: FreeBSD, Linux, SunOS, Solaris, other UNIX, Windows License: BSD URL: pel.cis.udel.edu Project: OPNET SCTP model Author(s): R. Brennan, T. Curran Affiliation(s): Dublin City University Type: simulation OS: ?? License: ?? URL: ?? Project: tcpdump SCTP module Author(s): J. Heinz, J. Fiore, A. Caro Affiliation(s): Temple University, U of Pennsylvania, U of Delaware Type: application OS: UNIX/Linux License: BSD URL: www.tcpdump.org Project: ethereal SCTP module Author(s): M. Tuxen Affiliation(s): Seimens AG Type: application OS: UNIX/Linux, Windows License: GPL URL: www.ethereal.com Project: Apache w/ SCTP support Author(s): R. Stewart, P. Lei Affiliation(s): Cisco Systems Type: application OS: FreeBSD, NetBSD, OpenBSD License: URL: www.sctp.org Project: Mozilla w/ SCTP support Author(s): R. Stewart, P. Lei Affiliation(s): Cisco Systems Type: application OS: FreeBSD, NetBSD, OpenBSD License: URL: www.sctp.org Project: FTP (client & server) w/ SCTP support Author(s): B. Atlani, S. Ladha Affiliation(s): University of Delaware Type: application OS: FreeBsd, NetBSD, OpenBSD License: BSD URL: not avail yet Project: WebCam over SCTP Author(s): P. Conrad, ?? Affiliation(s): Temple University Type: application OS: FreeBsd, NetBSD, OpenBSD License: ?? URL: ?? ~armando 0-- --0 | Armando L. Caro Jr. | acaro@cis.udel.edu | | University of Delaware | www.cis.udel.edu/~acaro | 0-- --0 From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Oct 16 06:59:08 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24318 for ; Wed, 16 Oct 2002 06:59:02 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GAvkxF006927; Wed, 16 Oct 2002 03:57:46 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAJ29081; Wed, 16 Oct 2002 03:57:45 -0700 (PDT) Message-ID: <3DAD4629.1000106@cisco.com> Date: Wed, 16 Oct 2002 05:57:45 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: sctp-impl@external.cisco.com Subject: Re: implementations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Armando L. Caro Jr. wrote: >Hi, > >I am compiling a list of SCTP implementations, including tools and >apps. I want to include the project name, author(s), affiliation(s), >kernel/userland/simulation/app, OS, license, url. (I wasn't sure if both author >and affiliation were always appropriate.) Below is an incomplete list I >have so far. Please inform me (via private email) of any corrections >or projects which are not listed. Also, if there is any other >information that you think would be useful to have in such a list, >please let me know. Thank you. > >Project: KAME Stack >Author(s): R. Stewart, ?? >Affiliation(s): Cisco Systems >Type: kernel >OS: FreeBSD, NetBSD, OpenBSD >License: BSD >URL: www.sctp.org > > Please add to your list a authors Peter Lei. Also it might be good to mention the Kame Project. >Project: Siemens SCTP >Author(s): T. Dreibholz, H. Holzlwimmer, A. Jungmaier, M. Tuxen >Affiliations(s): Seimens AG, University of Essen >Type: userland >OS: Linux, FreeBSD, Mac OS X >License: GPL >URL: www.sctp.de > >Project: Linux Kernel SCTP >Author(s): L. Yarroll, ?? >Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco >Type: kernel >OS: Linux >License: GPL >URL: sourceforge.net/projects/lksctp > >Project: Solaris Stack >Author(s): K. Poon, ?? >Affiliation(s): Sun Microsystems Laboratories >Type: kernel >OS: Solaris >License: Proprietary >URL: playground.sun.com/sctp > > Unfortunately the two folks responsible for the sun stack Jon Woods and Kacheong have left sun... Michael Tuexen, do you remember who was given ownership of this stack at connect-a-thon? I can't remember.... >Project: OpenSS7 Stack >Author(s): B. Bidulock, ?? >Affiliation(s): Open{SS7} Corporation >Type: kernel >OS: Linux >License: GPL >URL: www.openss7.org > >Project: RivuS >Author(s): J. Rane, N. Kumbhar, K. Sovani >Affiliation(s): Pune Institute of Computer Technology (PICT) >Type: kernel >OS: FreeBSD >License: BSD >URL: rivus.sourceforge.net > >Project: AIX Stack >Author(s): ?? >Affiliation(s): IBM >Type: kernel >OS: AIX >License: Proprietary >URL: ?? > >Project: ?? >Author(s): I. Arias-Rodriguez, ?? >Affiliation(s): Nokia Research Center >Type: ?? >OS: ?? >License: ?? >URL: ?? > >Project: Playstation II >Author(s): R. Stewart, ?? >Affiliation(s): Cisco Systems >Type: kernel >OS: ?? >License: ?? >URL: ?? > > Huh? I know some folks inside were playing with this but I don't know any status on it...you might want to remove it unless someone else confesses up.... >Project: Intellinet SCTP >Author(s): ?? >Affiliation(s): IntelliNet Technologies, Inc. >Type: kernel? >OS: independent >License: Proprietary >URL: www.intellinet-tech.com/products/sigtran/sctp > >Project: Portable SCTP >Author(s): ?? >Affiliation(s): Data Connection Ltd. >Type: kernel? >OS: Windows, VxWorks/VxWorks AE/Tornado, Solaris / SunOS, pSOS, Chorus, LynxOS, OSE, Nucleus, UNIX, Linux, and others >License: Proprietary >URL: www.dataconnection.com/sctp > >Project: ns-2 SCTP module >Author(s): A. Caro, J. Iyengar >Affiliation(s): University of Delaware >Type: simulation >OS: FreeBSD, Linux, SunOS, Solaris, other UNIX, Windows >License: BSD >URL: pel.cis.udel.edu > >Project: OPNET SCTP model >Author(s): R. Brennan, T. Curran >Affiliation(s): Dublin City University >Type: simulation >OS: ?? >License: ?? >URL: ?? > >Project: tcpdump SCTP module >Author(s): J. Heinz, J. Fiore, A. Caro >Affiliation(s): Temple University, U of Pennsylvania, U of Delaware >Type: application >OS: UNIX/Linux >License: BSD >URL: www.tcpdump.org > >Project: ethereal SCTP module >Author(s): M. Tuxen >Affiliation(s): Seimens AG >Type: application >OS: UNIX/Linux, Windows >License: GPL >URL: www.ethereal.com > >Project: Apache w/ SCTP support >Author(s): R. Stewart, P. Lei >Affiliation(s): Cisco Systems >Type: application >OS: FreeBSD, NetBSD, OpenBSD >License: >URL: www.sctp.org > > Hopefully soon we will get these all in apache itself... I am working with them on it.. :> There was also a stack for HP/Compac also Ericcson.. plus I think companies called radvision radsys spyder all had stacks at the last bake-off... and there may have been others... R >Project: Mozilla w/ SCTP support >Author(s): R. Stewart, P. Lei >Affiliation(s): Cisco Systems >Type: application >OS: FreeBSD, NetBSD, OpenBSD >License: >URL: www.sctp.org > >Project: FTP (client & server) w/ SCTP support >Author(s): B. Atlani, S. Ladha >Affiliation(s): University of Delaware >Type: application >OS: FreeBsd, NetBSD, OpenBSD >License: BSD >URL: not avail yet > >Project: WebCam over SCTP >Author(s): P. Conrad, ?? >Affiliation(s): Temple University >Type: application >OS: FreeBsd, NetBSD, OpenBSD >License: ?? >URL: ?? > > >~armando > >0-- --0 >| Armando L. Caro Jr. | acaro@cis.udel.edu | >| University of Delaware | www.cis.udel.edu/~acaro | >0-- --0 > > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 16 07:26:03 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24863 for ; Wed, 16 Oct 2002 07:26:02 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9GBP0Im005953 for ; Wed, 16 Oct 2002 04:25:01 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9GBOxMN001456 for ; Wed, 16 Oct 2002 04:24:59 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9GBOw2p014260 for ; Wed, 16 Oct 2002 04:24:59 -0700 (PDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA19286; Wed, 16 Oct 2002 13:08:05 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA29269; Wed, 16 Oct 2002 13:08:05 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id <4RYGRD3K>; Wed, 16 Oct 2002 13:07:44 +0200 Message-ID: From: Tuexen Michael To: "'Randall Stewart (cisco)'" , "Armando L. Caro Jr." Cc: sctp-impl@external.cisco.com Subject: RE: implementations Date: Wed, 16 Oct 2002 13:07:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" I think the guy from Sun was Steven.Glass@Sun.COM You may want to contact him before including him in the list. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Wednesday, October 16, 2002 12:58 PM > To: Armando L. Caro Jr. > Cc: sctp-impl@external.cisco.com > Subject: Re: implementations > > > Armando L. Caro Jr. wrote: > > >Hi, > > > >I am compiling a list of SCTP implementations, including tools and > >apps. I want to include the project name, author(s), affiliation(s), > >kernel/userland/simulation/app, OS, license, url. (I wasn't > sure if both author > >and affiliation were always appropriate.) Below is an > incomplete list I > >have so far. Please inform me (via private email) of any corrections > >or projects which are not listed. Also, if there is any other > >information that you think would be useful to have in such a list, > >please let me know. Thank you. > > > >Project: KAME Stack > >Author(s): R. Stewart, ?? > >Affiliation(s): Cisco Systems > >Type: kernel > >OS: FreeBSD, NetBSD, OpenBSD > >License: BSD > >URL: www.sctp.org > > > > > Please add to your list a authors Peter Lei. Also it might be > good to mention the Kame Project. > > > >Project: Siemens SCTP > >Author(s): T. Dreibholz, H. Holzlwimmer, A. Jungmaier, M. Tuxen > >Affiliations(s): Seimens AG, University of Essen > >Type: userland > >OS: Linux, FreeBSD, Mac OS X > >License: GPL > >URL: www.sctp.de > > > >Project: Linux Kernel SCTP > >Author(s): L. Yarroll, ?? > >Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco > >Type: kernel > >OS: Linux > >License: GPL > >URL: sourceforge.net/projects/lksctp > > > >Project: Solaris Stack > >Author(s): K. Poon, ?? > >Affiliation(s): Sun Microsystems Laboratories > >Type: kernel > >OS: Solaris > >License: Proprietary > >URL: playground.sun.com/sctp > > > > > Unfortunately the two folks responsible for the sun stack Jon > Woods and > Kacheong > have left sun... Michael Tuexen, do you remember who was > given ownership > of this stack at connect-a-thon? I can't remember.... > > >Project: OpenSS7 Stack > >Author(s): B. Bidulock, ?? > >Affiliation(s): Open{SS7} Corporation > >Type: kernel > >OS: Linux > >License: GPL > >URL: www.openss7.org > > > >Project: RivuS > >Author(s): J. Rane, N. Kumbhar, K. Sovani > >Affiliation(s): Pune Institute of Computer Technology (PICT) > >Type: kernel > >OS: FreeBSD > >License: BSD > >URL: rivus.sourceforge.net > > > >Project: AIX Stack > >Author(s): ?? > >Affiliation(s): IBM > >Type: kernel > >OS: AIX > >License: Proprietary > >URL: ?? > > > >Project: ?? > >Author(s): I. Arias-Rodriguez, ?? > >Affiliation(s): Nokia Research Center > >Type: ?? > >OS: ?? > >License: ?? > >URL: ?? > > > >Project: Playstation II > >Author(s): R. Stewart, ?? > >Affiliation(s): Cisco Systems > >Type: kernel > >OS: ?? > >License: ?? > >URL: ?? > > > > > Huh? I know some folks inside were > playing with this but I don't know any > status on it...you might want to remove it > unless someone else confesses up.... > > >Project: Intellinet SCTP > >Author(s): ?? > >Affiliation(s): IntelliNet Technologies, Inc. > >Type: kernel? > >OS: independent > >License: Proprietary > >URL: www.intellinet-tech.com/products/sigtran/sctp > > > >Project: Portable SCTP > >Author(s): ?? > >Affiliation(s): Data Connection Ltd. > >Type: kernel? > >OS: Windows, VxWorks/VxWorks AE/Tornado, Solaris / SunOS, > pSOS, Chorus, LynxOS, OSE, Nucleus, UNIX, Linux, and others > >License: Proprietary > >URL: www.dataconnection.com/sctp > > > >Project: ns-2 SCTP module > >Author(s): A. Caro, J. Iyengar > >Affiliation(s): University of Delaware > >Type: simulation > >OS: FreeBSD, Linux, SunOS, Solaris, other UNIX, Windows > >License: BSD > >URL: pel.cis.udel.edu > > > >Project: OPNET SCTP model > >Author(s): R. Brennan, T. Curran > >Affiliation(s): Dublin City University > >Type: simulation > >OS: ?? > >License: ?? > >URL: ?? > > > >Project: tcpdump SCTP module > >Author(s): J. Heinz, J. Fiore, A. Caro > >Affiliation(s): Temple University, U of Pennsylvania, U of Delaware > >Type: application > >OS: UNIX/Linux > >License: BSD > >URL: www.tcpdump.org > > > >Project: ethereal SCTP module > >Author(s): M. Tuxen > >Affiliation(s): Seimens AG > >Type: application > >OS: UNIX/Linux, Windows > >License: GPL > >URL: www.ethereal.com > > > >Project: Apache w/ SCTP support > >Author(s): R. Stewart, P. Lei > >Affiliation(s): Cisco Systems > >Type: application > >OS: FreeBSD, NetBSD, OpenBSD > >License: > >URL: www.sctp.org > > > > > Hopefully soon we will get these all in apache itself... I am working > with them on it.. :> > > There was also a stack for HP/Compac also Ericcson.. plus I think > companies called > radvision > radsys > spyder > > all had stacks at the last bake-off... and there may have > been others... > > R > > > >Project: Mozilla w/ SCTP support > >Author(s): R. Stewart, P. Lei > >Affiliation(s): Cisco Systems > >Type: application > >OS: FreeBSD, NetBSD, OpenBSD > >License: > >URL: www.sctp.org > > > >Project: FTP (client & server) w/ SCTP support > >Author(s): B. Atlani, S. Ladha > >Affiliation(s): University of Delaware > >Type: application > >OS: FreeBsd, NetBSD, OpenBSD > >License: BSD > >URL: not avail yet > > > >Project: WebCam over SCTP > >Author(s): P. Conrad, ?? > >Affiliation(s): Temple University > >Type: application > >OS: FreeBsd, NetBSD, OpenBSD > >License: ?? > >URL: ?? > > > > > >~armando > > > >0-- --0 > >| Armando L. Caro Jr. | acaro@cis.udel.edu | > >| University of Delaware | www.cis.udel.edu/~acaro | > >0-- --0 > > > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 16 11:14:30 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02655 for ; Wed, 16 Oct 2002 11:14:29 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9GF85cl020814 for ; Wed, 16 Oct 2002 08:08:05 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GF869r021895 for ; Wed, 16 Oct 2002 08:08:06 -0700 (PDT) Received: from tweets.austin.ibm.com (pixpat.austin.ibm.com [192.35.232.241]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9GF8489020128 for ; Wed, 16 Oct 2002 08:08:05 -0700 (PDT) Received: from austin.ibm.com (loopback [127.0.0.1] (may be forged)) by tweets.austin.ibm.com (AIX5.1/8.11.0/8.11.0) with ESMTP id g9GF1Vh33934; Wed, 16 Oct 2002 10:01:31 -0500 Sender: kavithab@tweets.austin.ibm.com Message-ID: <3DAD7F4B.E1B435DC@austin.ibm.com> Date: Wed, 16 Oct 2002 10:01:31 -0500 From: Kavitha Baratakke Reply-To: kavithab@austin.ibm.com Organization: IBM corporation X-Mailer: Mozilla 4.76iC-CCK-MCD [en_US] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: sctp-impl@external.cisco.com Subject: Re: implementations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Project: AIX Kernel SCTP Author(s): Venkat Venkatsubra, Kavitha Baratakke Affiliation(s): IBM Corporation Type: Kernel OS: AIX License: Proprietary URL: No URL yet. -- Thanks, Kavitha _________________________________________________________________ Ms. Kavitha V. Baratakke IBM Corporation Office : (512)-838-1226 AIX TCP/IP Kernel Development & Support T/L : 678-1226 11501, Burnet Road, Austin TX 78758 From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 16 12:46:11 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05319 for ; Wed, 16 Oct 2002 12:45:10 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-92.cisco.com [64.103.26.92]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g9GGb5cl008162 for ; Wed, 16 Oct 2002 09:37:06 -0700 (PDT) Received: (qmail 37333 invoked by uid 1000); 16 Oct 2002 16:36:58 -0000 Message-ID: <20021016163658.37332.qmail@cobweb.example.org> Date: Wed, 16 Oct 2002 18:36:58 +0200 From: Marco Molteni To: "Armando L. Caro Jr." Cc: sctp-impl@external.cisco.com Subject: Re: implementations In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 15 Oct 2002, "Armando L. Caro Jr." wrote: > I am compiling a list of SCTP implementations, including tools and > apps. [..] Hi Armando, myself and Massimo Villari wrote a paper to appear in the EuroBDSConf proceedings (eurobsdcon2002.org) on PR-SCTP as transport for MPEG-4. We use apple darwin streaming server and mpeg4ip mplayer. The code is really hackish at the moment so I think I will release it (BSD license) when I'll have time to make it decent. I'll send you the paper if you are interested. thanks marco Project: MPEG-4 streamer and player Author(s): Marco Molteni, Massimo Villari Affiliation(s): Cisco Systems Type: application OS: FreeBSD License: various licenses apply URL: no url for the moment From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 16 13:22:10 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06649 for ; Wed, 16 Oct 2002 13:22:09 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9GHGaIm003937 for ; Wed, 16 Oct 2002 10:16:36 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9GHGZIV009031 for ; Wed, 16 Oct 2002 10:16:35 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9GHFB6v023950 for ; Wed, 16 Oct 2002 10:15:12 -0700 (PDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9GHA6tr045202; Wed, 16 Oct 2002 13:10:07 -0400 Received: from us.ibm.com ([9.41.94.148]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9GHA66x250454; Wed, 16 Oct 2002 11:10:06 -0600 Sender: root@westrelay01.boulder.ibm.com Message-ID: <3DAD9D1D.C8E249B7@us.ibm.com> Date: Wed, 16 Oct 2002 12:08:45 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: sctp-impl@external.cisco.com Subject: Re: implementations References: Content-Type: multipart/alternative; boundary="------------8A7C245C776A20164B93E4DC" --------------8A7C245C776A20164B93E4DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Armando L. Caro Jr." wrote:Project: Linux Kernel SCTP > Author(s): L. Yarroll, ?? > Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco > Type: kernel > OS: Linux > License: GPL > URL: sourceforge.net/projects/lksctp Please add these people to Author(s) - Jon Grimm, Sridhar Samudrala. -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------8A7C245C776A20164B93E4DC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "Armando L. Caro Jr." wrote:Project: Linux Kernel SCTP
Author(s): L. Yarroll, ??
Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco
Type: kernel
OS: Linux
License: GPL
URL: sourceforge.net/projects/lksctp
Please add these people to Author(s) - Jon Grimm, Sridhar Samudrala. 
-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------8A7C245C776A20164B93E4DC-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 16 16:36:30 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11537 for ; Wed, 16 Oct 2002 16:36:29 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9GKYxcl019320 for ; Wed, 16 Oct 2002 13:34:59 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9GKYvHa027038 for ; Wed, 16 Oct 2002 13:34:57 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9GKYs2Z024389 for ; Wed, 16 Oct 2002 13:34:55 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA05271 for ; Wed, 16 Oct 2002 13:27:18 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA05719 for ; Wed, 16 Oct 2002 13:29:50 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9GKQ7n10908; Wed, 16 Oct 2002 15:26:07 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06170; Wed, 16 Oct 2002 15:27:15 -0500 (CDT) Message-ID: <3DADCBDC.699739DB@Motorola.com> Date: Wed, 16 Oct 2002 15:28:12 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: sctp-impl@external.cisco.com Subject: Re: implementations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't see the very first SCTP stack on your list: the open source reference userland stack at . That's probably still the widest distributed stack so far. -Qiaobing "Armando L. Caro Jr." wrote: > > Hi, > > I am compiling a list of SCTP implementations, including tools and > apps. I want to include the project name, author(s), affiliation(s), > kernel/userland/simulation/app, OS, license, url. (I wasn't sure if both author > and affiliation were always appropriate.) Below is an incomplete list I > have so far. Please inform me (via private email) of any corrections > or projects which are not listed. Also, if there is any other > information that you think would be useful to have in such a list, > please let me know. Thank you. > > Project: KAME Stack > Author(s): R. Stewart, ?? > Affiliation(s): Cisco Systems > Type: kernel > OS: FreeBSD, NetBSD, OpenBSD > License: BSD > URL: www.sctp.org > > Project: Siemens SCTP > Author(s): T. Dreibholz, H. Holzlwimmer, A. Jungmaier, M. Tuxen > Affiliations(s): Seimens AG, University of Essen > Type: userland > OS: Linux, FreeBSD, Mac OS X > License: GPL > URL: www.sctp.de > > Project: Linux Kernel SCTP > Author(s): L. Yarroll, ?? > Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco > Type: kernel > OS: Linux > License: GPL > URL: sourceforge.net/projects/lksctp > > Project: Solaris Stack > Author(s): K. Poon, ?? > Affiliation(s): Sun Microsystems Laboratories > Type: kernel > OS: Solaris > License: Proprietary > URL: playground.sun.com/sctp > > Project: OpenSS7 Stack > Author(s): B. Bidulock, ?? > Affiliation(s): Open{SS7} Corporation > Type: kernel > OS: Linux > License: GPL > URL: www.openss7.org > > Project: RivuS > Author(s): J. Rane, N. Kumbhar, K. Sovani > Affiliation(s): Pune Institute of Computer Technology (PICT) > Type: kernel > OS: FreeBSD > License: BSD > URL: rivus.sourceforge.net > > Project: AIX Stack > Author(s): ?? > Affiliation(s): IBM > Type: kernel > OS: AIX > License: Proprietary > URL: ?? > > Project: ?? > Author(s): I. Arias-Rodriguez, ?? > Affiliation(s): Nokia Research Center > Type: ?? > OS: ?? > License: ?? > URL: ?? > > Project: Playstation II > Author(s): R. Stewart, ?? > Affiliation(s): Cisco Systems > Type: kernel > OS: ?? > License: ?? > URL: ?? > > Project: Intellinet SCTP > Author(s): ?? > Affiliation(s): IntelliNet Technologies, Inc. > Type: kernel? > OS: independent > License: Proprietary > URL: www.intellinet-tech.com/products/sigtran/sctp > > Project: Portable SCTP > Author(s): ?? > Affiliation(s): Data Connection Ltd. > Type: kernel? > OS: Windows, VxWorks/VxWorks AE/Tornado, Solaris / SunOS, pSOS, Chorus, LynxOS, OSE, Nucleus, UNIX, Linux, and others > License: Proprietary > URL: www.dataconnection.com/sctp > > Project: ns-2 SCTP module > Author(s): A. Caro, J. Iyengar > Affiliation(s): University of Delaware > Type: simulation > OS: FreeBSD, Linux, SunOS, Solaris, other UNIX, Windows > License: BSD > URL: pel.cis.udel.edu > > Project: OPNET SCTP model > Author(s): R. Brennan, T. Curran > Affiliation(s): Dublin City University > Type: simulation > OS: ?? > License: ?? > URL: ?? > > Project: tcpdump SCTP module > Author(s): J. Heinz, J. Fiore, A. Caro > Affiliation(s): Temple University, U of Pennsylvania, U of Delaware > Type: application > OS: UNIX/Linux > License: BSD > URL: www.tcpdump.org > > Project: ethereal SCTP module > Author(s): M. Tuxen > Affiliation(s): Seimens AG > Type: application > OS: UNIX/Linux, Windows > License: GPL > URL: www.ethereal.com > > Project: Apache w/ SCTP support > Author(s): R. Stewart, P. Lei > Affiliation(s): Cisco Systems > Type: application > OS: FreeBSD, NetBSD, OpenBSD > License: > URL: www.sctp.org > > Project: Mozilla w/ SCTP support > Author(s): R. Stewart, P. Lei > Affiliation(s): Cisco Systems > Type: application > OS: FreeBSD, NetBSD, OpenBSD > License: > URL: www.sctp.org > > Project: FTP (client & server) w/ SCTP support > Author(s): B. Atlani, S. Ladha > Affiliation(s): University of Delaware > Type: application > OS: FreeBsd, NetBSD, OpenBSD > License: BSD > URL: not avail yet > > Project: WebCam over SCTP > Author(s): P. Conrad, ?? > Affiliation(s): Temple University > Type: application > OS: FreeBsd, NetBSD, OpenBSD > License: ?? > URL: ?? > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | acaro@cis.udel.edu | > | University of Delaware | www.cis.udel.edu/~acaro | > 0-- --0 From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Oct 17 02:31:36 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02201 for ; Thu, 17 Oct 2002 02:31:34 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9H6SGcl015129 for ; Wed, 16 Oct 2002 23:28:16 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9H6SEcf027349 for ; Wed, 16 Oct 2002 23:28:14 -0700 (PDT) Received: from out019.verizon.net (out019pub.verizon.net [206.46.170.98]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9H6Qr6v003734 for ; Wed, 16 Oct 2002 23:26:55 -0700 (PDT) Received: from cc2181633-a ([67.212.87.187]) by out019.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021017060922.PDKI9549.out019.verizon.net@cc2181633-a> for ; Thu, 17 Oct 2002 01:09:22 -0500 Message-ID: <4114-22002104176830710@cc2181633-a> Organisation: Market*Access International, Inc. From: "David Dickson" To: "sctp-impl@external.cisco.com" Subject: Three Conferences: Mobile&Wireless, Cyber, Info Sharing, Arl. Va, Nov-Dec 02 Date: Thu, 17 Oct 2002 02:08:30 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02201 To: sctp-impl@external.cisco.com TRAINING CONFERENCE - MOBILE AND WIRELESS SOLUTIONS Homeland Defense Training Conference Event Produced by Market*Access International, Inc. WHEN: November 13, 2002 WHERE: Executive Conference Center NRECA Building 4301 Wilson Boulevard Arlington, Virginia 22203 Time: 7:00 AM Registration Program Starts: 8:30 AM Wrap-up: 4:45 PM Continental Breakfast, Refreshments, Lunch included. HOTLINE AVAILABLE - Call 703-807-2027 to learn how you can register on-line and view the most current agenda or visit our site at www.homelanddefensejournal.com *** To register and pay on line, call our hot line at 703-807-2027 for instructions. *** *** Special Note: We have three conferences planned in November and December 2002. These include: * Mobile and Wireless Solutions * Protecting America's Infrastructure - Cyber Defense * Information Sharing Strategies (To get current information on these conferences, exhibitor and sponsorship information, go to our web site at www.homelanddefensejournal.com.) SPEAKERS CONFIRMED * CHRIS RANGEL, Assistant Vice President of Marketing, Alvarion, Inc. * ANDREW KRIEG, President, Wireless Communications Association International (WCAI) (Industry Keynote Speaker) * SPEAKER TBD, GSA Federal Technology Service (FTS) · SPEAKER TBD, RIM/BlackBerry · … government speakers being confirmed now. NOTE: As speakers are confirmed they will be posted at our site www.homelanddefensejournal.com. SPEAKERS WILL REPRESENT: Government agency applications of mobile and wireless technologies Communication managers and program analysts Technology development leaders representing academic efforts and private sector research and development programs and devices dedicated to mobile and wireless solutions. These speakers will provide attendees with up to date reports on current local and national programs, new technological advances, demonstration project updates, common challenges and the outlook for the future. ABOUT MOBILE AND WIRELESS SOLUTIONS From townships to federal agencies, mobile-wireless technology is making inroads into traditional government business, public safety and operational solutions. Government IT Executives are quickly recognizing the exciting opportunity to extend their reach beyond the web to devices like cell phones, handheld computers, interactive pagers, Palm Pilots, and other PDAs. The commercial growth potential for this market is just about to explode. IDC Research projects that 61.5 million people will be using wireless devices to access the Internet in 2003. This is a 728% increase from the 7.4 million users today. Government business applications of wireless will track this explosive growth. Products and solutions that address wireless security, business continuity, reliability and disaster recovery will experience high growth due to the recent terrorist attacks and the need to improve communications and security. CONFERNECE GOAL Market*Access will host a training conference for industry and government focusing on agency needs and requirements in Mobile and Wireless Solutions in the area of Homeland Defense. This will be a public-level series of training presentations on the challenges ahead. Speakers will represent federal agencies and leading security, equipment and systems suppliers. The goal of this meeting is to begin to prepare U.S. government and industry for the changes that will come about regarding mobile and wireless solutions for Homeland Defense. EXHIBITORS WILL INCLUDE * Wireless and mobile solution providers * Mobile and wireless communications * Security planners * Federal systems integrators * Network and Systems Security Training and Consulting * Disaster recovery and facility security WHO SHOULD ATTEND * Agency IT Executives * Agency mobile and wireless program managers * Tele-work and Telecomm Directors & Managers * Functional area managers using mobile computing * Wireless and mobile solutions providers * Federal systems integrators and solutions providers * Federal, State and Local CIOs and IT teams WHAT YOU WILL LEARN * Understanding new programs, issues and requirements * Strategies for mobile and wireless applications * New products in development and on the drawing boards in terms of Mobile and Wireless Solutions * New initiatives being planned at the federal, state and local levels. * Civil agency organization and planning * R&D Initiatives POINTS OF CONTACT: For information on SPONSORSHIP arrangements, please contact Mr. George Groesbeck, 406-723-3488 For REGISTRATION or general information about this event, please contact Mr. David Dickson, 703/807-2742. **** THERE IS LIMITED SEATING SO PLEASE REGISTER EARLY **** REGISTRATION FEE * Industry - Credit Card or Check in Advance $595 * Government - Credit Card or Check in Advance $395 * Fax: registration form to 703-807-2728. * Mail: registration form to: Market*Access International, Inc. Attn: David Dickson 4301 Wilson Blvd. #1003 Arlington, VA 22203 ----------------------------------------------------------------------------------------- **** REGISTRATION FORM **** Mobile and Wireless Solutions - November 13, 2002 Attendee Name: Title: Company/Agency: Address: City: State: Zip Code: Email: Telephone: Fax: Registration Fee: * Industry - Credit Card or Check in Advance $595 * Government - Credit Card or Check in Advance $395 Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Blvd. #1003, Arlington, VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order I am interested in continuing to receive updates and information by email regarding future conferences in this area. Select one: _____Yes _____No Registration: Call David Dickson (703) 807-2742 Fax this form to 703-807-2728. Thank you. To register and pay on line, call our hot line at 703-807-2027 for instructions. *** SPECIAL NOTE *** This message is being sent to you as a service to inform you and your organization of a training conference directed at federal and industry managers. If this business communication was sent to you in error or is not of interest, please let us know by REPLY'ing to this message and place REMOVE in the SUBJECT line. We will remove your name immediately. If however, you wish to receive additional information about this Conference, how you can register on-line and other related training opportunities, please place SUBSCRIBE TRAINING in the SUBJECT line and REPLY to this message. We will include you in future notices concerning this topic. *** SPECIAL NOTE *** HOMELAND DEFENSE JOURNAL FREE SUBSCRIPTION IS AVAILABLE NOW **** The Homeland Defense Journal is published twice a month and distributed as a PDF file by email. If you would like a free subscription, please REPLY to this message and place SUBSCRIBE HOMELAND in the SUBJECT line and you will receive our next issue -- Issue #19 - This paper has a distribution of over 45,000 subscribers at federal, state and local levels. Our last issue was downloaded over 126,000 times. To get information on how you can download past issues free, call our Homeland Defense Journal HOTLINE at 703-807-2758 or visit www.homelanddefensejournal.com. If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. Thank you. From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sun Oct 20 14:11:14 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01144 for ; Sun, 20 Oct 2002 14:11:13 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9KI8xxF022693 for ; Sun, 20 Oct 2002 11:08:59 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9KI90E5013169 for ; Sun, 20 Oct 2002 11:09:00 -0700 (PDT) Received: from stewart.chicago.il.us (adsl-67-38-193-238.dsl.chcgil.ameritech.net [67.38.193.238]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9KI8sss027808 for ; Sun, 20 Oct 2002 11:08:55 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap2 [10.1.2.5]) by stewart.chicago.il.us (8.12.3/8.12.3) with ESMTP id g9KI51fO049917; Sun, 20 Oct 2002 13:05:07 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3DB2F04D.30407@stewart.chicago.il.us> Date: Sun, 20 Oct 2002 13:05:01 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ram Avtar Meena , sctp-impl@external.cisco.com Subject: Re: sctp server References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ram: The peel off test code is written for BSD NOT linux.. I have no idea what include files need to be around for lksctp.. besides which it appears LK must have other problems if it does not have the basic SCTP_ASOC_CHANGE defines in place... this is basic socket-api stuff. R Ram Avtar Meena wrote: > Hi, > Thanks for your guidance. I downloaded the peel off server/client from > www.sctp.org but as i found some problem in compiling both the files even > after installing Sctp prototype and socket API implementation from > www.sctp.de i recomplied the kernel with lksctp implementation ,but still > getting the same error (iam posting initial part of error at the end). > It is surprising to know that the new kernel passed all sctp related test > given in http://lksctp.sourceforge.net . > > lsctp-2_5_41-0_6_0I complied lksctp-2_5_29-0_5_0 with linux-2.5.29.tar.gz > kernel. > > > <--error --> > > [rambo@ChillSpirit peel]$ gcc peel_server.c > peel_server.c:11:26: net/if_types.h: No such file or directory > peel_server.c:12:23: net/if_dl.h: No such file or directory > peel_server.c:26:26: netinet/sctp.h: No such file or directory > peel_server.c:27:30: netinet/sctp_uio.h: No such file or directory > peel_server.c:28:36: netinet/sctp_constants.h: No such file or directory > peel_server.c: In function `my_handle_notification': > peel_server.c:239: dereferencing pointer to incomplete type > peel_server.c:240: `SCTP_ASSOC_CHANGE' undeclared (first use in this > function) > peel_server.c:240: (Each undeclared identifier is reported only once > peel_server.c:240: for each function it appears in.) > peel_server.c:241: dereferencing pointer to incomplete type > peel_server.c:242: dereferencing pointer to incomplete type > peel_server.c:244: `SCTP_COMM_UP' undeclared (first use in this function) > peel_server.c:248: `SCTP_COMM_LOST' undeclared (first use in this > function) > . . . > . . . > . . . > > <--end--> > > Errors related to sctp.h and sctp_sonstants.h in line 26 and 28 can be > removed my placing the files in appropriate place but there is no > netinet/sctp_uio.h file. > > I really wants to contribute to this field but iam very sorry to say that > there is not much information either on internet or otherwise. And that's > one more reason that i appreciate your guidance and suggestions. > > With regards, > > Ram > > > > On Wed, 9 Oct 2002, Randall Stewart wrote: > > >>Ram Avtar Meena wrote: >> >>>Hi, >>> I am a 4th year student of computer science and engineering and as my >>>networks project i am asked to work on sctp server/client >>>implemetation,Although i have knowledge of tcp/ip server/client >>>programming but still i can't understand much of sctp. I have already >>>tried looking for materials on this part but could not get it, and its rfc >>>2960 also don't have much on server/client programming over sctp. >>>I read your post on sctp.org and i hope you could guide me on this one. >>>Please consider my request. >>> >>>thanks >>> >> >>Ram: >> >>If you go to the download page of >>http://www.sctp.org >> >>You will find a new "peel off" server and client. >>This is a small tarball that should give you a good >>idea about how to use SCTP in a sockets api. >> >>You also need to take a look at the sockets api draft >>on the ietf web page... there is a pointer to this from >>the "RFC's and internet drafts page' >> >> > > > > > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Oct 21 09:40:52 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28386 for ; Mon, 21 Oct 2002 09:40:51 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9LDctIm000786 for ; Mon, 21 Oct 2002 06:38:55 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9LDcrmK027104 for ; Mon, 21 Oct 2002 06:38:54 -0700 (PDT) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9LDbPjp006382 for ; Mon, 21 Oct 2002 06:37:26 -0700 (PDT) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA23126; Mon, 21 Oct 2002 08:29:43 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA23184; Mon, 21 Oct 2002 08:31:44 -0500 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA05050; Mon, 21 Oct 2002 08:31:43 -0500 Sender: root@popmail.austin.ibm.com Message-ID: <3DB3FBB8.84FDF075@us.ibm.com> Date: Mon, 21 Oct 2002 08:06:00 -0500 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.43 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ram Avtar Meena CC: Randall Stewart , sctp-impl@external.cisco.com, "lksctp-developers@lists.sourceforge.net" Subject: Re: sctp server References: <3DB2F04D.30407@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ram, I'm forwarding your note over to lksctp-developers as this is an lksctp question. If you have lksctp related questions you'll have better luck finding help there: The short answer is that you are using the BSD header files. ;-) e.g: > > peel_server.c:11:26: net/if_types.h: No such file or directory > > peel_server.c:12:23: net/if_dl.h: No such file or directory > > peel_server.c:26:26: netinet/sctp.h: No such file or directory > > peel_server.c:27:30: netinet/sctp_uio.h: No such file or directory > > peel_server.c:28:36: netinet/sctp_constants.h: No such file or directory The long answer is that I'm not sure if this program is ported over to lksctp. I know Sridhar had been playing with it one afternoon, so it may be done and I just don't know it. Minimally, the lksctp-tools package includes the netinet/sctp.h file you'll need for compilation. Best Regards, Jon Grimm Randall Stewart wrote: > > Ram: > > The peel off test code is written for BSD NOT linux.. I have > no idea what include files need to be around for lksctp.. besides > which it appears LK must have other problems if it does not > have the basic SCTP_ASOC_CHANGE defines in place... this is > basic socket-api stuff. > > R > > Ram Avtar Meena wrote: > > Hi, > > Thanks for your guidance. I downloaded the peel off server/client from > > www.sctp.org but as i found some problem in compiling both the files even > > after installing Sctp prototype and socket API implementation from > > www.sctp.de i recomplied the kernel with lksctp implementation ,but still > > getting the same error (iam posting initial part of error at the end). > > It is surprising to know that the new kernel passed all sctp related test > > given in http://lksctp.sourceforge.net . > > > > lsctp-2_5_41-0_6_0I complied lksctp-2_5_29-0_5_0 with linux-2.5.29.tar.gz > > kernel. > > > > > > <--error --> > > > > [rambo@ChillSpirit peel]$ gcc peel_server.c > > peel_server.c:11:26: net/if_types.h: No such file or directory > > peel_server.c:12:23: net/if_dl.h: No such file or directory > > peel_server.c:26:26: netinet/sctp.h: No such file or directory > > peel_server.c:27:30: netinet/sctp_uio.h: No such file or directory > > peel_server.c:28:36: netinet/sctp_constants.h: No such file or directory > > peel_server.c: In function `my_handle_notification': > > peel_server.c:239: dereferencing pointer to incomplete type > > peel_server.c:240: `SCTP_ASSOC_CHANGE' undeclared (first use in this > > function) > > peel_server.c:240: (Each undeclared identifier is reported only once > > peel_server.c:240: for each function it appears in.) > > peel_server.c:241: dereferencing pointer to incomplete type > > peel_server.c:242: dereferencing pointer to incomplete type > > peel_server.c:244: `SCTP_COMM_UP' undeclared (first use in this function) > > peel_server.c:248: `SCTP_COMM_LOST' undeclared (first use in this > > function) > > . . . > > . . . > > . . . > > > > <--end--> > > > > Errors related to sctp.h and sctp_sonstants.h in line 26 and 28 can be > > removed my placing the files in appropriate place but there is no > > netinet/sctp_uio.h file. > > > > I really wants to contribute to this field but iam very sorry to say that > > there is not much information either on internet or otherwise. And that's > > one more reason that i appreciate your guidance and suggestions. > > > > With regards, > > > > Ram > > > > > > > > On Wed, 9 Oct 2002, Randall Stewart wrote: > > > > > >>Ram Avtar Meena wrote: > >> > >>>Hi, > >>> I am a 4th year student of computer science and engineering and as my > >>>networks project i am asked to work on sctp server/client > >>>implemetation,Although i have knowledge of tcp/ip server/client > >>>programming but still i can't understand much of sctp. I have already > >>>tried looking for materials on this part but could not get it, and its rfc > >>>2960 also don't have much on server/client programming over sctp. > >>>I read your post on sctp.org and i hope you could guide me on this one. > >>>Please consider my request. > >>> > >>>thanks > >>> > >> > >>Ram: > >> > >>If you go to the download page of > >>http://www.sctp.org > >> > >>You will find a new "peel off" server and client. > >>This is a small tarball that should give you a good > >>idea about how to use SCTP in a sockets api. > >> > >>You also need to take a look at the sockets api draft > >>on the ietf web page... there is a pointer to this from > >>the "RFC's and internet drafts page' > >> > >> > > > > > > > > > > > > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Oct 21 11:07:59 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02138 for ; Mon, 21 Oct 2002 11:07:58 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9LF09Io011261; Mon, 21 Oct 2002 08:00:09 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK46053; Mon, 21 Oct 2002 08:00:07 -0700 (PDT) Message-ID: <3DB41677.9060508@cisco.com> Date: Mon, 21 Oct 2002 10:00:07 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Grimm CC: Ram Avtar Meena , Randall Stewart , sctp-impl@external.cisco.com, "lksctp-developers@lists.sourceforge.net" Subject: Re: sctp server References: <3DB2F04D.30407@stewart.chicago.il.us> <3DB3FBB8.84FDF075@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon: If anyone cares to send me patches for lk-sctp (ifdef's around header files etc) I will be more than glad to make sure the code is updated.. R Jon Grimm wrote: >Ram, > I'm forwarding your note over to lksctp-developers as this is an lksctp >question. If you have lksctp related questions you'll have better luck >finding help there: > >The short answer is that you are using the BSD header files. ;-) > > >e.g: > > >>>peel_server.c:11:26: net/if_types.h: No such file or directory >>>peel_server.c:12:23: net/if_dl.h: No such file or directory >>>peel_server.c:26:26: netinet/sctp.h: No such file or directory >>>peel_server.c:27:30: netinet/sctp_uio.h: No such file or directory >>>peel_server.c:28:36: netinet/sctp_constants.h: No such file or directory >>> >>> > > >The long answer is that I'm not sure if this program is ported over to >lksctp. >I know Sridhar had been playing with it one afternoon, so it may be done >and I just don't know it. Minimally, the lksctp-tools package includes >the >netinet/sctp.h file you'll need for compilation. > >Best Regards, >Jon Grimm > >Randall Stewart wrote: > > >>Ram: >> >>The peel off test code is written for BSD NOT linux.. I have >>no idea what include files need to be around for lksctp.. besides >>which it appears LK must have other problems if it does not >>have the basic SCTP_ASOC_CHANGE defines in place... this is >>basic socket-api stuff. >> >>R >> >>Ram Avtar Meena wrote: >> >> >>>Hi, >>> Thanks for your guidance. I downloaded the peel off server/client from >>>www.sctp.org but as i found some problem in compiling both the files even >>>after installing Sctp prototype and socket API implementation from >>>www.sctp.de i recomplied the kernel with lksctp implementation ,but still >>>getting the same error (iam posting initial part of error at the end). >>>It is surprising to know that the new kernel passed all sctp related test >>>given in http://lksctp.sourceforge.net . >>> >>>lsctp-2_5_41-0_6_0I complied lksctp-2_5_29-0_5_0 with linux-2.5.29.tar.gz >>>kernel. >>> >>> >>><--error --> >>> >>>[rambo@ChillSpirit peel]$ gcc peel_server.c >>>peel_server.c:11:26: net/if_types.h: No such file or directory >>>peel_server.c:12:23: net/if_dl.h: No such file or directory >>>peel_server.c:26:26: netinet/sctp.h: No such file or directory >>>peel_server.c:27:30: netinet/sctp_uio.h: No such file or directory >>>peel_server.c:28:36: netinet/sctp_constants.h: No such file or directory >>>peel_server.c: In function `my_handle_notification': >>>peel_server.c:239: dereferencing pointer to incomplete type >>>peel_server.c:240: `SCTP_ASSOC_CHANGE' undeclared (first use in this >>>function) >>>peel_server.c:240: (Each undeclared identifier is reported only once >>>peel_server.c:240: for each function it appears in.) >>>peel_server.c:241: dereferencing pointer to incomplete type >>>peel_server.c:242: dereferencing pointer to incomplete type >>>peel_server.c:244: `SCTP_COMM_UP' undeclared (first use in this function) >>>peel_server.c:248: `SCTP_COMM_LOST' undeclared (first use in this >>>function) >>>. . . >>>. . . >>>. . . >>> >>><--end--> >>> >>>Errors related to sctp.h and sctp_sonstants.h in line 26 and 28 can be >>>removed my placing the files in appropriate place but there is no >>>netinet/sctp_uio.h file. >>> >>>I really wants to contribute to this field but iam very sorry to say that >>>there is not much information either on internet or otherwise. And that's >>>one more reason that i appreciate your guidance and suggestions. >>> >>>With regards, >>> >>>Ram >>> >>> >>> >>>On Wed, 9 Oct 2002, Randall Stewart wrote: >>> >>> >>> >>> >>>>Ram Avtar Meena wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> I am a 4th year student of computer science and engineering and as my >>>>>networks project i am asked to work on sctp server/client >>>>>implemetation,Although i have knowledge of tcp/ip server/client >>>>>programming but still i can't understand much of sctp. I have already >>>>>tried looking for materials on this part but could not get it, and its rfc >>>>>2960 also don't have much on server/client programming over sctp. >>>>>I read your post on sctp.org and i hope you could guide me on this one. >>>>>Please consider my request. >>>>> >>>>>thanks >>>>> >>>>> >>>>> >>>>Ram: >>>> >>>>If you go to the download page of >>>>http://www.sctp.org >>>> >>>>You will find a new "peel off" server and client. >>>>This is a small tarball that should give you a good >>>>idea about how to use SCTP in a sockets api. >>>> >>>>You also need to take a look at the sockets api draft >>>>on the ietf web page... there is a pointer to this from >>>>the "RFC's and internet drafts page' >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 22 03:25:43 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07658 for ; Tue, 22 Oct 2002 03:25:37 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9M7NMxF027695 for ; Tue, 22 Oct 2002 00:23:22 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9M7NNV9028728 for ; Tue, 22 Oct 2002 00:23:24 -0700 (PDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9M7NN89001654 for ; Tue, 22 Oct 2002 00:23:23 -0700 (PDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA15154; Tue, 22 Oct 2002 09:06:37 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA14490; Tue, 22 Oct 2002 09:06:27 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id <4RYS8ZX7>; Tue, 22 Oct 2002 09:06:18 +0200 Message-ID: From: Schruefer Wolfgang To: "'Armando L. Caro Jr.'" Cc: sctp-impl@external.cisco.com Subject: AW: implementations Date: Tue, 22 Oct 2002 09:05:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07658 Hi Armando, to supplement your list: There are two further SCTP implementations within SIEMENS: Project: Siemens SCTP for Signaling Gateway Author(s): Bernward Meyknecht Affiliation(s): Siemens AG, Muenchen Type: proprietary, carrier grade OS: proprietary License: proprietary URL: no URL yet. Project: Siemens generic SCTP Author(s): Wolfgang Schruefer Affiliation(s): Siemens AG, Munich Type: independent, carrier grade OS: independent License: Proprietary URL: no URL yet. thanks Wolfgang ********************************* Siemens ICN WN CC NP B4 TEL: +49 89 722-61646 ********************************* -----Ursprüngliche Nachricht----- Von: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] Gesendet: Mittwoch, 16. Oktober 2002 04:41 An: sctp-impl@external.cisco.com Betreff: implementations Hi, I am compiling a list of SCTP implementations, including tools and apps. I want to include the project name, author(s), affiliation(s), kernel/userland/simulation/app, OS, license, url. (I wasn't sure if both author and affiliation were always appropriate.) Below is an incomplete list I have so far. Please inform me (via private email) of any corrections or projects which are not listed. Also, if there is any other information that you think would be useful to have in such a list, please let me know. Thank you. Project: KAME Stack Author(s): R. Stewart, ?? Affiliation(s): Cisco Systems Type: kernel OS: FreeBSD, NetBSD, OpenBSD License: BSD URL: www.sctp.org Project: Siemens SCTP Author(s): T. Dreibholz, H. Holzlwimmer, A. Jungmaier, M. Tuxen Affiliations(s): Seimens AG, University of Essen Type: userland OS: Linux, FreeBSD, Mac OS X License: GPL URL: www.sctp.de Project: Linux Kernel SCTP Author(s): L. Yarroll, ?? Affiliation(s): Motorola, IBM, Intel, Nokia, Cisco Type: kernel OS: Linux License: GPL URL: sourceforge.net/projects/lksctp Project: Solaris Stack Author(s): K. Poon, ?? Affiliation(s): Sun Microsystems Laboratories Type: kernel OS: Solaris License: Proprietary URL: playground.sun.com/sctp Project: OpenSS7 Stack Author(s): B. Bidulock, ?? Affiliation(s): Open{SS7} Corporation Type: kernel OS: Linux License: GPL URL: www.openss7.org Project: RivuS Author(s): J. Rane, N. Kumbhar, K. Sovani Affiliation(s): Pune Institute of Computer Technology (PICT) Type: kernel OS: FreeBSD License: BSD URL: rivus.sourceforge.net Project: AIX Stack Author(s): ?? Affiliation(s): IBM Type: kernel OS: AIX License: Proprietary URL: ?? Project: ?? Author(s): I. Arias-Rodriguez, ?? Affiliation(s): Nokia Research Center Type: ?? OS: ?? License: ?? URL: ?? Project: Playstation II Author(s): R. Stewart, ?? Affiliation(s): Cisco Systems Type: kernel OS: ?? License: ?? URL: ?? Project: Intellinet SCTP Author(s): ?? Affiliation(s): IntelliNet Technologies, Inc. Type: kernel? OS: independent License: Proprietary URL: www.intellinet-tech.com/products/sigtran/sctp Project: Portable SCTP Author(s): ?? Affiliation(s): Data Connection Ltd. Type: kernel? OS: Windows, VxWorks/VxWorks AE/Tornado, Solaris / SunOS, pSOS, Chorus, LynxOS, OSE, Nucleus, UNIX, Linux, and others License: Proprietary URL: www.dataconnection.com/sctp Project: ns-2 SCTP module Author(s): A. Caro, J. Iyengar Affiliation(s): University of Delaware Type: simulation OS: FreeBSD, Linux, SunOS, Solaris, other UNIX, Windows License: BSD URL: pel.cis.udel.edu Project: OPNET SCTP model Author(s): R. Brennan, T. Curran Affiliation(s): Dublin City University Type: simulation OS: ?? License: ?? URL: ?? Project: tcpdump SCTP module Author(s): J. Heinz, J. Fiore, A. Caro Affiliation(s): Temple University, U of Pennsylvania, U of Delaware Type: application OS: UNIX/Linux License: BSD URL: www.tcpdump.org Project: ethereal SCTP module Author(s): M. Tuxen Affiliation(s): Seimens AG Type: application OS: UNIX/Linux, Windows License: GPL URL: www.ethereal.com Project: Apache w/ SCTP support Author(s): R. Stewart, P. Lei Affiliation(s): Cisco Systems Type: application OS: FreeBSD, NetBSD, OpenBSD License: URL: www.sctp.org Project: Mozilla w/ SCTP support Author(s): R. Stewart, P. Lei Affiliation(s): Cisco Systems Type: application OS: FreeBSD, NetBSD, OpenBSD License: URL: www.sctp.org Project: FTP (client & server) w/ SCTP support Author(s): B. Atlani, S. Ladha Affiliation(s): University of Delaware Type: application OS: FreeBsd, NetBSD, OpenBSD License: BSD URL: not avail yet Project: WebCam over SCTP Author(s): P. Conrad, ?? Affiliation(s): Temple University Type: application OS: FreeBsd, NetBSD, OpenBSD License: ?? URL: ?? ~armando 0-- --0 | Armando L. Caro Jr. | acaro@cis.udel.edu | | University of Delaware | www.cis.udel.edu/~acaro | 0-- --0 From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 22 15:37:27 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01730 for ; Tue, 22 Oct 2002 15:37:26 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MJZ3xF018081 for ; Tue, 22 Oct 2002 12:35:03 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MJZ4i4024106 for ; Tue, 22 Oct 2002 12:35:04 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9MJYvw2027488 for ; Tue, 22 Oct 2002 12:34:58 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MJSNUF028800 for ; Tue, 22 Oct 2002 15:28:23 -0400 Received: from us.ibm.com ([9.41.94.148]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MJSLh0104758 for ; Tue, 22 Oct 2002 15:28:21 -0400 Sender: root@northrelay01.pok.ibm.com Message-ID: <3DB5A68F.DE8ECAD@us.ibm.com> Date: Tue, 22 Oct 2002 14:27:11 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: sctp-impl@external.cisco.com Subject: question regarding retransmission Content-Type: multipart/alternative; boundary="------------101BF637BB683B4F1208272C" --------------101BF637BB683B4F1208272C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I was looking to fix a problem in our SCTP retransmission code and had a confusion on the following scenario. I would like to clear it up and make sure that we will do it right. The confusion is about retransmission under the circumstances of outstanding chunks eligible for retransmit (residuals from previous T3rtx timeout) and data on multiple transports in an association. The scenario: If there are 3 transports - t1, t2, t3. Where t1 is the primary path, and t2 is the first choice for doing any retransmission with. Assuming that chunks with TSN #1, #2, and #3 have been transmitted thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER flag on and destined to be sent thru t3. Also, assuming that t1, t2, t3 have the same MTU sizes, and that each chunk would fit in the MTU just right. So, Transmitted: t1: #1, #2, #3 t2: nothing t3: #4 With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked for retramission but only #1 would be sent out due to the MTU constraint (RFC 2960 6.3 E3). So we will end up with Transmitted: t1: nothing t2: #1 t3: #4 marked for retransmission: #2, #3 Next, if t3's T3-rtx timer pops, a retransmission needs to be made again thru t2, which chunk should be sent out? Is it #1, or #2 or even #4? In other words, which one of the following would be the result of this timeout? Is it Transmitted: t1: nothing t2: #1 (again) t3: nothing marked for retransmission: #2, #3. #4 or Transmitted: t1: nothing t2: #1, #2 t3: nothing marked for retransmission: #3. #4 or Transmitted: t1: nothing t2: #1, #4 t3: nothing marked for retransmission: #2, #3 -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------101BF637BB683B4F1208272C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  Hi,
    I was looking to fix a problem in our SCTP retransmission code and had a confusion on the following scenario. I would like to clear it up and make sure that we will do it right.  The confusion is about retransmission under the circumstances of outstanding chunks eligible for retransmit (residuals from previous T3rtx timeout) and data on multiple transports in an association.

    The scenario:
    If there are 3 transports - t1, t2, t3. Where t1 is the primary path, and t2 is the first choice for doing any retransmission with.  Assuming that chunks with TSN #1, #2, and #3 have been transmitted thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER flag on and destined to be sent thru t3.   Also, assuming that t1, t2, t3 have the same MTU sizes, and that each chunk would fit in the MTU just right.  So,
  Transmitted:
    t1: #1, #2, #3
    t2: nothing
    t3: #4
 
With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked for retramission but only #1 would be sent out due to the MTU constraint (RFC 2960 6.3 E3).  So we will end up with
    Transmitted:
    t1: nothing
    t2: #1
    t3: #4
    marked for retransmission: #2, #3

Next, if t3's T3-rtx timer pops, a retransmission needs to be made again thru t2, which chunk should be sent out?   Is it #1, or #2 or even #4?  In other words, which one of the following would be the result of this timeout? Is it

    Transmitted:
    t1: nothing
    t2: #1 (again)
    t3: nothing
    marked for retransmission: #2, #3. #4
or
    Transmitted:
    t1: nothing
    t2: #1, #2
    t3: nothing
    marked for retransmission:  #3. #4
or
    Transmitted:
    t1: nothing
    t2: #1, #4
    t3: nothing
    marked for retransmission:  #2, #3
 
  

-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------101BF637BB683B4F1208272C-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 22 17:04:31 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04525 for ; Tue, 22 Oct 2002 17:04:30 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9ML0ZxF013841 for ; Tue, 22 Oct 2002 14:00:35 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9ML02GA011776 for ; Tue, 22 Oct 2002 14:00:33 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9MKM4w2023691 for ; Tue, 22 Oct 2002 13:22:05 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MKFb0K076100; Tue, 22 Oct 2002 16:15:37 -0400 Received: from us.ibm.com ([9.41.94.148]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MKFYbr134860; Tue, 22 Oct 2002 16:15:34 -0400 Sender: root@northrelay04.pok.ibm.com Message-ID: <3DB5B1A0.937472B5@us.ibm.com> Date: Tue, 22 Oct 2002 15:14:24 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: sctp-impl@external.cisco.com CC: randall@stewart.chicago.il.us Subject: [Fwd: question regarding retransmission] Content-Type: multipart/alternative; boundary="------------2BB681E0B3CB1D14E94DBAAC" --------------2BB681E0B3CB1D14E94DBAAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Sorry to post this again. I would like to update my illustrations, hopefully, to make the question clearer for you. The scenario is the same, but I would like to show the sequence of outgoing chunks, per transport/path, a little better by putting the previously transmitted chunks in (), followed by newly transmitted chunks as a result of the events described in the scenario. So, we begin with Transmitted: t1: #1, #2, #3 t2: nothing t3: #4 If t1 times out, we expect Transmitted: t1: (#1, #2, #3) t2: #1 t3: (#4) marked for retransmission: #2, #3 Now, if t3 times out next, which one is expected to happen? Transmitted: t1: (#1. #2, #3) t2: (#1), #1 t3: (#4) marked for retransmission: #2, #3. #4 or Transmitted: t1: (#1, #2, #3) t2: (#1), #2 t3: (#4) marked for retransmission: #3. #4 or Transmitted: t1: (#1, #2, #3) t2: (#1), #4 t3: (#4) marked for retransmission: #2, #3 or something else??? Any of your responses is greatly appreciated! Best Regards, Daisy Daisy Chang wrote: > Hi, > I was looking to fix a problem in our SCTP retransmission code and > had a confusion on the following scenario. I would like to clear it up > and make sure that we will do it right. The confusion is about > retransmission under the circumstances of outstanding chunks eligible > for retransmit (residuals from previous T3rtx timeout) and data on > multiple transports in an association. > > The scenario: > If there are 3 transports - t1, t2, t3. Where t1 is the primary > path, and t2 is the first choice for doing any retransmission with. > Assuming that chunks with TSN #1, #2, and #3 have been transmitted > thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER > flag on and destined to be sent thru t3. Also, assuming that t1, t2, > t3 have the same MTU sizes, and that each chunk would fit in the MTU > just right. So, > Transmitted: > t1: #1, #2, #3 > t2: nothing > t3: #4 > > With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked > for retramission but only #1 would be sent out due to the MTU > constraint (RFC 2960 6.3 E3). So we will end up with > Transmitted: > t1: nothing > t2: #1 > t3: #4 > marked for retransmission: #2, #3 > > Next, if t3's T3-rtx timer pops, a retransmission needs to be made > again thru t2, which chunk should be sent out? Is it #1, or #2 or > even #4? In other words, which one of the following would be the > result of this timeout? Is it > > Transmitted: > t1: nothing > t2: #1 (again) > t3: nothing > marked for retransmission: #2, #3. #4 > or > Transmitted: > t1: nothing > t2: #1, #2 > t3: nothing > marked for retransmission: #3. #4 > or > Transmitted: > t1: nothing > t2: #1, #4 > t3: nothing > marked for retransmission: #2, #3 > > > > -- > > Thanks, > Daisy > > +--------------------------------------------------------------------------+ > Daisy Chang IBM Linux Technology Center > e-mail: tcdc@us.ibm.com > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------2BB681E0B3CB1D14E94DBAAC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    Sorry to post this again. I would like to update my illustrations, hopefully, to make the question clearer for you. The scenario is the same, but I would like to show the sequence of outgoing chunks, per transport/path, a little better by putting the previously transmitted chunks in (), followed by newly transmitted chunks as a result of the events described in the scenario.

So, we begin with
  Transmitted:
    t1: #1, #2, #3
    t2: nothing
    t3: #4

If t1 times out, we expect
  Transmitted:
    t1: (#1, #2, #3)
    t2: #1
    t3: (#4)
    marked for retransmission: #2, #3

Now, if t3 times out next, which one is expected to happen?
Transmitted:
    t1: (#1. #2, #3)
    t2: (#1), #1
    t3: (#4)
    marked for retransmission: #2, #3. #4
or
    Transmitted:
    t1: (#1, #2, #3)
    t2: (#1), #2
    t3: (#4)
    marked for retransmission:  #3. #4
or
    Transmitted:
    t1: (#1, #2, #3)
    t2: (#1), #4
    t3: (#4)
    marked for retransmission:  #2, #3
or
    something else???
 
    Any of your responses is greatly appreciated!
 

Best Regards,
Daisy

Daisy Chang wrote:

 Hi,
    I was looking to fix a problem in our SCTP retransmission code and had a confusion on the following scenario. I would like to clear it up and make sure that we will do it right.  The confusion is about retransmission under the circumstances of outstanding chunks eligible for retransmit (residuals from previous T3rtx timeout) and data on multiple transports in an association.

    The scenario:
    If there are 3 transports - t1, t2, t3. Where t1 is the primary path, and t2 is the first choice for doing any retransmission with.  Assuming that chunks with TSN #1, #2, and #3 have been transmitted thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER flag on and destined to be sent thru t3.   Also, assuming that t1, t2, t3 have the same MTU sizes, and that each chunk would fit in the MTU just right.  So,
  Transmitted:
    t1: #1, #2, #3
    t2: nothing
    t3: #4

With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked for retramission but only #1 would be sent out due to the MTU constraint (RFC 2960 6.3 E3).  So we will end up with
    Transmitted:
    t1: nothing
    t2: #1
    t3: #4
    marked for retransmission: #2, #3

Next, if t3's T3-rtx timer pops, a retransmission needs to be made again thru t2, which chunk should be sent out?   Is it #1, or #2 or even #4?  In other words, which one of the following would be the result of this timeout? Is it

    Transmitted:
    t1: nothing
    t2: #1 (again)
    t3: nothing
    marked for retransmission: #2, #3. #4
or
    Transmitted:
    t1: nothing
    t2: #1, #2
    t3: nothing
    marked for retransmission:  #3. #4
or
    Transmitted:
    t1: nothing
    t2: #1, #4
    t3: nothing
    marked for retransmission:  #2, #3
 
  

-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
 
-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------2BB681E0B3CB1D14E94DBAAC-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 22 17:13:16 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04806 for ; Tue, 22 Oct 2002 17:13:14 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLAGxF021754 for ; Tue, 22 Oct 2002 14:10:16 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLAE9j021376 for ; Tue, 22 Oct 2002 14:10:14 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9MLA9w2018946 for ; Tue, 22 Oct 2002 14:10:10 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA06355; Tue, 22 Oct 2002 14:05:09 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA22095; Tue, 22 Oct 2002 14:05:09 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9ML56f26521; Tue, 22 Oct 2002 16:05:06 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA14323; Tue, 22 Oct 2002 16:06:14 -0500 (CDT) Message-ID: <3DB5BE21.B4D518ED@Motorola.com> Date: Tue, 22 Oct 2002 16:07:45 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daisy Chang CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Daisy, Admittedly, I haven't read through some late rtx rules enhancements in impl guide, but my intuition is that you are over-engineering over a simple problem. See my comments below... Daisy Chang wrote: > > Hi, > I was looking to fix a problem in our SCTP retransmission code and > had a confusion on the following scenario. I would like to clear it up > and make sure that we will do it right. The confusion is about > retransmission under the circumstances of outstanding chunks eligible > for retransmit (residuals from previous T3rtx timeout) and data on > multiple transports in an association. > > The scenario: > If there are 3 transports - t1, t2, t3. Where t1 is the primary > path, and t2 is the first choice for doing any retransmission with. > Assuming that chunks with TSN #1, #2, and #3 have been transmitted > thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER > flag on and destined to be sent thru t3. Also, assuming that t1, t2, > t3 have the same MTU sizes, and that each chunk would fit in the MTU > just right. So, > Transmitted: > t1: #1, #2, #3 > t2: nothing > t3: #4 > > With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked > for retramission but only #1 would be sent out due to the MTU > constraint (RFC 2960 6.3 E3). So we will end up with > Transmitted: > t1: nothing > t2: #1 > t3: #4 > marked for retransmission: #2, #3 > > Next, if t3's T3-rtx timer pops, a retransmission needs to be made > again thru t2, which chunk should be sent out? sequence of events should be straightforward here: 1) collapse t3 cwind to 1 MTU: done. 2) mark #4 for re-trans: done. 3) see if there is an alternate dest that is still up: yes (t1 and t2) Now the spec doesn't say how to select btw t1 or t2, but it doesn't matter that much I think. If you pick t1 and re-send #4 thru it (remember you still have 1 chunk/1 MTU cwnd quota available on t1), I think it's perfectly legal and nothing terrible can happen. If you pick t2 (as you seem to prefer), you will have to queue #4 behind #2 and #3, since you don't have any quato left on t2 since t2 is still under the "max one chunk of upto MTU in flight allowed" mode. But either way you would be just fine. -Qiaobing > Is it #1, or #2 or > even #4? In other words, which one of the following would be the > result of this timeout? Is it > > Transmitted: > t1: nothing > t2: #1 (again) > t3: nothing > marked for retransmission: #2, #3. #4 > or > Transmitted: > t1: nothing > t2: #1, #2 > t3: nothing > marked for retransmission: #3. #4 > or > Transmitted: > t1: nothing > t2: #1, #4 > t3: nothing > marked for retransmission: #2, #3 > > > > -- > > Thanks, > Daisy > > +--------------------------------------------------------------------------+ > Daisy Chang IBM Linux Technology Center > e-mail: tcdc@us.ibm.com > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 22 19:00:50 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07059 for ; Tue, 22 Oct 2002 19:00:48 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MMw8Im017327 for ; Tue, 22 Oct 2002 15:58:08 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MMw4IU023265 for ; Tue, 22 Oct 2002 15:58:04 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9MMvvw2019747 for ; Tue, 22 Oct 2002 15:57:58 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MMpWtB098884; Tue, 22 Oct 2002 18:51:32 -0400 Received: from us.ibm.com ([9.41.94.148]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MMpTh0175510; Tue, 22 Oct 2002 18:51:29 -0400 Sender: root@northrelay01.pok.ibm.com Message-ID: <3DB5D631.A7F9E378@us.ibm.com> Date: Tue, 22 Oct 2002 17:50:25 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> <3DB5BE21.B4D518ED@Motorola.com> Content-Type: multipart/alternative; boundary="------------83780D7175FA0BB80CFCF7C8" --------------83780D7175FA0BB80CFCF7C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > Daisy, > > Admittedly, I haven't read through some late rtx rules enhancements in > impl guide, but my intuition is that you are over-engineering over a > simple problem. See my comments below... > > Daisy Chang wrote: > > > > Hi, > > I was looking to fix a problem in our SCTP retransmission code and > > had a confusion on the following scenario. I would like to clear it up > > and make sure that we will do it right. The confusion is about > > retransmission under the circumstances of outstanding chunks eligible > > for retransmit (residuals from previous T3rtx timeout) and data on > > multiple transports in an association. > > > > The scenario: > > If there are 3 transports - t1, t2, t3. Where t1 is the primary > > path, and t2 is the first choice for doing any retransmission with. > > Assuming that chunks with TSN #1, #2, and #3 have been transmitted > > thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER > > flag on and destined to be sent thru t3. Also, assuming that t1, t2, > > t3 have the same MTU sizes, and that each chunk would fit in the MTU > > just right. So, > > Transmitted: > > t1: #1, #2, #3 > > t2: nothing > > t3: #4 > > > > With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked > > for retramission but only #1 would be sent out due to the MTU > > constraint (RFC 2960 6.3 E3). So we will end up with > > Transmitted: > > t1: nothing > > t2: #1 > > t3: #4 > > marked for retransmission: #2, #3 > > > > Next, if t3's T3-rtx timer pops, a retransmission needs to be made > > again thru t2, which chunk should be sent out? > > sequence of events should be straightforward here: > 1) collapse t3 cwind to 1 MTU: done. > 2) mark #4 for re-trans: done. > 3) see if there is an alternate dest that is still up: yes (t1 and t2) > > Now the spec doesn't say how to select btw t1 or t2, but it doesn't > matter that much I think. If you pick t1 and re-send #4 thru it > (remember you still have 1 chunk/1 MTU cwnd quota available on t1), I > think it's perfectly legal and nothing terrible can happen. If you pick > t2 (as you seem to prefer), you will have to queue #4 behind #2 and #3, > since you don't have any quato left on t2 since t2 is still under the > "max one chunk of upto MTU in flight allowed" mode. But either way you > would be just fine. > > -Qiaobing > Thanks, Qiaobing. This is very good information for me. Based on your answer, may I say that, different chunks might be retransmitted at different transport depends on the choices of the outgoing transport at the time, and since the choices of the outgoing transport for retransmission is up to the implementation, there is really not a definite sequence of chunks being mandated by the RFC for retransmission? I am not implying anything like retransmitting chunks in random order, on the contrary, my case is that we are considering retransmitting chunks always in the same order, regardless the choice of the transport. That is, back to the example, at the time of t3 timeout, we will queue #4 behind #2 and #3, and possibly send out #2 either on t1 or t2, regardless which we end up picking. This is OK, isn't it? One more thing, in your description, you said "if you pick t2 (as you seem to prefer), you will have to queue #4 behind #2 and #3, since you don't have any quato left on t2 since t2 is still under the 'max one chunk of upto MTU in flight allowed' mode", could you explain how t2 got into this mode? If we assume that, this example begins with all three transports' cwnd up to, let's say, 4 * MTU at the moment, do you think that t2 would still end up in this mode given the sequence of events? Best Regards Daisy > > > Is it #1, or #2 or > > even #4? In other words, which one of the following would be the > > result of this timeout? Is it > > > > Transmitted: > > t1: nothing > > t2: #1 (again) > > t3: nothing > > marked for retransmission: #2, #3. #4 > > or > > Transmitted: > > t1: nothing > > t2: #1, #2 > > t3: nothing > > marked for retransmission: #3. #4 > > or > > Transmitted: > > t1: nothing > > t2: #1, #4 > > t3: nothing > > marked for retransmission: #2, #3 > > > > > > > > -- > > > > Thanks, > > Daisy > > > > +--------------------------------------------------------------------------+ > > Daisy Chang IBM Linux Technology Center > > e-mail: tcdc@us.ibm.com > > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > > > -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------83780D7175FA0BB80CFCF7C8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Qiaobing Xie wrote:
Daisy,

Admittedly, I haven't read through some late rtx rules enhancements in
impl guide, but my intuition is that you are over-engineering over a
simple problem. See my comments below...

Daisy Chang wrote:
>
>  Hi,
>     I was looking to fix a problem in our SCTP retransmission code and
> had a confusion on the following scenario. I would like to clear it up
> and make sure that we will do it right.  The confusion is about
> retransmission under the circumstances of outstanding chunks eligible
> for retransmit (residuals from previous T3rtx timeout) and data on
> multiple transports in an association.
>
>     The scenario:
>     If there are 3 transports - t1, t2, t3. Where t1 is the primary
> path, and t2 is the first choice for doing any retransmission with.
> Assuming that chunks with TSN #1, #2, and #3 have been transmitted
> thru t1, and the next chunk, #4, was sent with sendmsg() MSG_ADDR_OVER
> flag on and destined to be sent thru t3.   Also, assuming that t1, t2,
> t3 have the same MTU sizes, and that each chunk would fit in the MTU
> just right.  So,
>   Transmitted:
>     t1: #1, #2, #3
>     t2: nothing
>     t3: #4
>
> With this, if t1's T3-rtx timer expired, #1, #2, #3 would be marked
> for retramission but only #1 would be sent out due to the MTU
> constraint (RFC 2960 6.3 E3).  So we will end up with
>     Transmitted:
>     t1: nothing
>     t2: #1
>     t3: #4
>     marked for retransmission: #2, #3
>
> Next, if t3's T3-rtx timer pops, a retransmission needs to be made
> again thru t2, which chunk should be sent out?

sequence of events should be straightforward here:
 1) collapse t3 cwind to 1 MTU: done.
 2) mark #4 for re-trans: done.
 3) see if there is an alternate dest that is still up: yes (t1 and t2)

Now the spec doesn't say how to select btw t1 or t2, but it doesn't
matter that much I think. If you pick t1 and re-send #4 thru it
(remember you still have 1 chunk/1 MTU cwnd quota available on t1), I
think it's perfectly legal and nothing terrible can happen. If you pick
t2 (as you seem to prefer), you will have to queue #4 behind #2 and #3,
since you don't have any quato left on t2 since t2 is still under the
"max one chunk of upto MTU in flight allowed" mode. But either way you
would be just fine.

-Qiaobing
 

Thanks, Qiaobing.  This is very good information for me.

Based on your answer, may I say that, different chunks might be retransmitted at different transport depends on the choices of the outgoing transport at the time, and since the choices of the outgoing transport for retransmission is up to the implementation, there is really not a definite sequence of chunks being mandated by the RFC for retransmission?  I am not implying anything like retransmitting chunks in random order, on the contrary, my case is that we are considering retransmitting chunks always in the same order, regardless the choice of the transport. That is, back to  the example, at the time of t3 timeout, we will queue #4 behind #2 and #3, and possibly send out #2 either on t1 or t2, regardless which we end up picking.  This is OK, isn't it?

One more thing, in your description,  you said "if you pick t2 (as you seem to prefer), you will have to queue #4 behind #2 and #3, since you don't have any quato left on t2 since t2 is still under the 'max one chunk of upto MTU in flight allowed' mode", could you explain how t2 got into this mode?  If we assume that, this example begins with all three transports' cwnd up to, let's say, 4 * MTU at the moment,  do you think that t2 would still end up in this mode given the sequence of events?

Best Regards
Daisy

 
> Is it #1, or #2 or
> even #4?  In other words, which one of the following would be the
> result of this timeout? Is it
>
>     Transmitted:
>     t1: nothing
>     t2: #1 (again)
>     t3: nothing
>     marked for retransmission: #2, #3. #4
> or
>     Transmitted:
>     t1: nothing
>     t2: #1, #2
>     t3: nothing
>     marked for retransmission:  #3. #4
> or
>     Transmitted:
>     t1: nothing
>     t2: #1, #4
>     t3: nothing
>     marked for retransmission:  #2, #3
>
>
>
> --
>
> Thanks,
> Daisy
>
> +--------------------------------------------------------------------------+
> Daisy Chang                     IBM Linux Technology Center
> e-mail: tcdc@us.ibm.com
> Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663
> 11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
>
>
-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------83780D7175FA0BB80CFCF7C8-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 22 19:55:12 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07979 for ; Tue, 22 Oct 2002 19:55:11 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9MNqsot010491 for ; Tue, 22 Oct 2002 16:52:54 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MNqrga000693 for ; Tue, 22 Oct 2002 16:52:53 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9MNqmw2013638 for ; Tue, 22 Oct 2002 16:52:48 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA21551; Tue, 22 Oct 2002 16:47:59 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA03700; Tue, 22 Oct 2002 16:47:49 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9MNlmf08359; Tue, 22 Oct 2002 18:47:48 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA14559; Tue, 22 Oct 2002 18:48:57 -0500 (CDT) Message-ID: <3DB5E445.531B38FC@Motorola.com> Date: Tue, 22 Oct 2002 18:50:29 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daisy Chang CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> <3DB5BE21.B4D518ED@Motorola.com> <3DB5D631.A7F9E378@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit .... > Thanks, Qiaobing. This is very good information for me. > > Based on your answer, may I say that, different chunks might be > retransmitted at different transport depends on the choices of the > outgoing transport at the time, and since the choices of the outgoing > transport for retransmission is up to the implementation, there is > really not a definite sequence of chunks being mandated by the RFC for > retransmission? I am not implying anything like retransmitting chunks > in random order, on the contrary, my case is that we are considering > retransmitting chunks always in the same order, regardless the choice > of the transport. What your scenario depicts is a case of multiple time-outs. I think it would be hard (and may not worth the effort) to still try to keep the tx order of all the affected chunks under such circumstance (and it would also be fruitless even if you try, since it won't mean much to the arrival order at the receiver side). IMO, it'd be nice to maintain the order in such a case. but if it's too much effort for the impl to do that, then why bother... > That is, back to the example, at the time of t3 > timeout, we will queue #4 behind #2 and #3, and possibly send out #2 > either on t1 or t2, regardless which we end up picking. This is OK, > isn't it? I believe so, as far as you always obey the cwnd rules. Also see below. > > One more thing, in your description, you said "if you pick t2 (as you > seem to prefer), you will have to queue #4 behind #2 and #3, since you > don't have any quato left on t2 since t2 is still under the 'max one > chunk of upto MTU in flight allowed' mode", could you explain how t2 > got into this mode? My mistake, when I wrote that I was thinking wrongly that t2 was the one that got timed-out. But the fact that you didn't rtx #2 and #3 along with #1 indicates that you ran out of cwnd on t2. So, if you insist to picking t2 for rtx #4, you have to queue it after #2 and #3. You basically have a case where you have more data marked for rtx than the cwnd of one dest addr allows and at the same time you have other dest addresses in the association that still have cwnd room available. My question to you is why keeping yourself from using the available cwnd on those alternate dest addresses to re-send the rest of the data? I don't think the spec prohibit that. It's up to the impl. > If we assume that, this example begins with all > three transports' cwnd up to, let's say, 4 * MTU at the moment, do > you think that t2 would still end up in this mode given the sequence > of events? > > Best Regards > Daisy > > > > > > Is it #1, or #2 or > > > even #4? In other words, which one of the following would be the > > > result of this timeout? Is it > > > > > > Transmitted: > > > t1: nothing > > > t2: #1 (again) > > > t3: nothing > > > marked for retransmission: #2, #3. #4 > > > or > > > Transmitted: > > > t1: nothing > > > t2: #1, #2 > > > t3: nothing > > > marked for retransmission: #3. #4 > > > or > > > Transmitted: > > > t1: nothing > > > t2: #1, #4 > > > t3: nothing > > > marked for retransmission: #2, #3 > > > > > > > > > > > > -- > > > > > > Thanks, > > > Daisy > > > > > > > > +--------------------------------------------------------------------------+ > > > > > Daisy Chang IBM Linux Technology Center > > > e-mail: tcdc@us.ibm.com > > > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > > > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > > > > > > > -- > > Thanks, > Daisy > > +--------------------------------------------------------------------------+ > Daisy Chang IBM Linux Technology Center > e-mail: tcdc@us.ibm.com > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 23 00:08:21 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14439 for ; Wed, 23 Oct 2002 00:08:19 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9N46aIm026451 for ; Tue, 22 Oct 2002 21:06:36 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9N46ZGV008342 for ; Tue, 22 Oct 2002 21:06:35 -0700 (PDT) Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9N46Qw2020808 for ; Tue, 22 Oct 2002 21:06:29 -0700 (PDT) Received: from ecvwall4 (ecvwall4.wipro.com [10.200.52.14]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g9N3lIR18438 for ; Wed, 23 Oct 2002 09:17:18 +0530 (IST) Received: from 164.164.23.9 by ecvwall4 (InterScan E-Mail VirusWall NT); Wed, 23 Oct 2002 09:15:06 +0530 Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H4F17Z00.B2V; Wed, 23 Oct 2002 09:17:59 +0530 Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 23 Oct 2002 09:17:59 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-100abbce-06bf-44b7-a69e-8170d5e00b4e" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: question regarding retransmission Date: Wed, 23 Oct 2002 09:17:59 +0530 Message-ID: Thread-Topic: question regarding retransmission Thread-Index: AcJ6KIRIrGHa6epsTOeu62mW3PdU/QAHi2N3 From: "Mohammed Ashraf" To: "Qiaobing Xie" , "Daisy Chang" Cc: X-OriginalArrivalTime: 23 Oct 2002 03:47:59.0599 (UTC) FILETIME=[FAEDE7F0:01C27A46] This is a multi-part message in MIME format. ------=_NextPartTM-000-100abbce-06bf-44b7-a69e-8170d5e00b4e Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Isn't always better to maintain the order while retransmiting also. = Since it helps to dequeue chunks from the sender Q fastly(otherwise it may result = in=20 blocking at the sender side ) -----Original Message----- From: Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] Sent: Wed 10/23/2002 5:20 AM To: Daisy Chang Cc: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission .... > Thanks, Qiaobing. This is very good information for me. >=20 > Based on your answer, may I say that, different chunks might be > retransmitted at different transport depends on the choices of the > outgoing transport at the time, and since the choices of the outgoing > transport for retransmission is up to the implementation, there is > really not a definite sequence of chunks being mandated by the RFC for > retransmission? I am not implying anything like retransmitting chunks > in random order, on the contrary, my case is that we are considering > retransmitting chunks always in the same order, regardless the choice > of the transport. What your scenario depicts is a case of multiple time-outs. I think it would be hard (and may not worth the effort) to still try to keep the tx order of all the affected chunks under such circumstance (and it would also be fruitless even if you try, since it won't mean much to the arrival order at the receiver side). IMO, it'd be nice to maintain the order in such a case. but if it's too much effort for the impl to do that, then why bother... > That is, back to the example, at the time of t3 > timeout, we will queue #4 behind #2 and #3, and possibly send out #2 > either on t1 or t2, regardless which we end up picking. This is OK, > isn't it? I believe so, as far as you always obey the cwnd rules. Also see below. >=20 > One more thing, in your description, you said "if you pick t2 (as you > seem to prefer), you will have to queue #4 behind #2 and #3, since you > don't have any quato left on t2 since t2 is still under the 'max one > chunk of upto MTU in flight allowed' mode", could you explain how t2 > got into this mode? =20 My mistake, when I wrote that I was thinking wrongly that t2 was the one that got timed-out. But the fact that you didn't rtx #2 and #3 along with #1 indicates that you ran out of cwnd on t2. So, if you insist to picking t2 for rtx #4, you have to queue it after #2 and #3. You basically have a case where you have more data marked for rtx than the cwnd of one dest addr allows and at the same time you have other dest addresses in the association that still have cwnd room available. My question to you is why keeping yourself from using the available cwnd on those alternate dest addresses to re-send the rest of the data? I don't think the spec prohibit that. It's up to the impl. > If we assume that, this example begins with all > three transports' cwnd up to, let's say, 4 * MTU at the moment, do > you think that t2 would still end up in this mode given the sequence > of events? >=20 > Best Regards > Daisy >=20 > > > > > Is it #1, or #2 or > > > even #4? In other words, which one of the following would be the > > > result of this timeout? Is it > > > > > > Transmitted: > > > t1: nothing > > > t2: #1 (again) > > > t3: nothing > > > marked for retransmission: #2, #3. #4 > > > or > > > Transmitted: > > > t1: nothing > > > t2: #1, #2 > > > t3: nothing > > > marked for retransmission: #3. #4 > > > or > > > Transmitted: > > > t1: nothing > > > t2: #1, #4 > > > t3: nothing > > > marked for retransmission: #2, #3 > > > > > > > > > > > > -- > > > > > > Thanks, > > > Daisy > > > > > > > > = +------------------------------------------------------------------------= --+ > > > > > Daisy Chang IBM Linux Technology Center > > > e-mail: tcdc@us.ibm.com > > > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > > > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > > > > > >=20 > -- >=20 > Thanks, > Daisy >=20 > = +------------------------------------------------------------------------= --+ > Daisy Chang IBM Linux Technology Center > e-mail: tcdc@us.ibm.com > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 >=20 > ------=_NextPartTM-000-100abbce-06bf-44b7-a69e-8170d5e00b4e Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************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. **************************************************************************************** ------=_NextPartTM-000-100abbce-06bf-44b7-a69e-8170d5e00b4e-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 23 05:53:38 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12397 for ; Wed, 23 Oct 2002 05:53:37 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9N9ZrIm016369 for ; Wed, 23 Oct 2002 02:35:53 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9N9ZqV4022511 for ; Wed, 23 Oct 2002 02:35:52 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9N9YKjp019867 for ; Wed, 23 Oct 2002 02:34:21 -0700 (PDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9N9Giw03927 for ; Wed, 23 Oct 2002 12:16:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 23 Oct 2002 12:17:03 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Oct 2002 12:17:03 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Oct 2002 12:17:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: question regarding retransmission Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Oct 2002 12:17:02 +0300 Message-ID: Thread-Topic: question regarding retransmission Thread-Index: AcJ6J5Pc7la6pcHGQHmBGtofJf3ocwAR1kQQ From: To: , Cc: X-OriginalArrivalTime: 23 Oct 2002 09:17:03.0077 (UTC) FILETIME=[F2F59150:01C27A74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA12397 Hi Daisy and Qiaobing, I will comment first Daisy's mail, and then Qiaobing's... > Transmitted: > t1: #1, #2, #3 > t2: nothing > t3: #4 > If t1 times out, we expect > Transmitted: > t1: (#1, #2, #3) > t2: #1 > t3: (#4) > marked for retransmission: #2, #3 Yes... you could have chosen t2 for the retransmission, but this is perfect as well... I also assume that all the TSNs are 1 MTU long, so you cannot retransmit more than one of them... > Now, if t3 times out next, which one is expected to happen? > Transmitted: > t1: (#1. #2, #3) > t2: (#1), #1 > t3: (#4) > marked for retransmission: #2, #3. #4 #1 is not marked for retransmission, so no way you do this... > or > Transmitted: > t1: (#1, #2, #3) > t2: (#1), #2 > t3: (#4) > marked for retransmission: #3. #4 This is what I would do... When t3 expires you mark #4 for retransmission and you issue a retransmission... But it happens that the oldest TSN marked for retransmission in #2, so you retransmit it... As #2 was last sent to t1, you can choose either t2 or t3... Again, I'm assuming that 1 TSN = 1 MTU... No matter which is the cwnd of the destination address, when retransmitting you send at most (and you are allowed to send at least) 1 MTU... Otherwise, you could bundle as many as you could in a single MTU of the destination address chosen for the retransmission... > or > Transmitted: > t1: (#1, #2, #3) > t2: (#1), #4 > t3: (#4) > marked for retransmission: #2, #3 > or I don't think that this is what you should do for the reasons I said above... Please note that this is just my suggestion (I cannot assure that I'm right :-)). (oops! I took a look to the RFC, and it seems that section 6.3.3 E3) says that you should precisely do this... Now I'm as confused as you, Daisy) And now about Qiaobing's comments... > What your scenario depicts is a case of multiple time-outs. I think it > would be hard (and may not worth the effort) to still try to keep the tx > order of all the affected chunks under such circumstance (and it would > also be fruitless even if you try, since it won't mean much to the > arrival order at the receiver side). IMO, it'd be nice to maintain the > order in such a case. but if it's too much effort for the impl to do > that, then why bother... Well... yes and not... If the DATA chunks are unordered, there could be a difference... But most probably, if they are unordered, it doesn't matter anyway... :-/ BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Oct 23 09:32:35 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23735 for ; Wed, 23 Oct 2002 09:32:35 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NDUFxF019029 for ; Wed, 23 Oct 2002 06:30:15 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NDUDcN002300 for ; Wed, 23 Oct 2002 06:30:13 -0700 (PDT) Received: from ottawa.pt.com ([206.191.2.130]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9NDUBWJ002847 for ; Wed, 23 Oct 2002 06:30:12 -0700 (PDT) Received: from pt.com (IDENT:root@todd.ottawa.pt.com [207.81.15.161]) by ottawa.pt.com (8.9.3/8.9.3) with ESMTP id FAA04506; Wed, 23 Oct 2002 05:33:14 -0400 Received: from pt.com (IDENT:root@localhost [127.0.0.1]) by pt.com (8.9.3/8.9.3) with ESMTP id JAA30661; Wed, 23 Oct 2002 09:20:15 -0400 Message-ID: <3DB6A39D.2020009@pt.com> Date: Wed, 23 Oct 2002 09:26:53 -0400 From: Laurent Glaude Organization: Performance Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: Qiaobing.Xie@motorola.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit That's also what I do. When I do retransmits, my first objective is to advance the cumulative TSN as fast as possible. I think it is the best and simplest approach : advancing the cumulative TSN makes you increase your cwnd, and reduces head-of-line blocking in the case where #1, #2, #3 and #4 are all on the same stream. -Laurent Ivan.Arias-Rodriguez@nokia.com wrote: >>or >> Transmitted: >> t1: (#1, #2, #3) >> t2: (#1), #2 >> t3: (#4) >> marked for retransmission: #3. #4 > > > This is what I would do... When t3 expires you mark #4 for retransmission and you issue a retransmission... But it happens that the oldest TSN marked for retransmission in #2, so you retransmit it... As #2 was last sent to t1, you can choose either t2 or t3... > > Again, I'm assuming that 1 TSN = 1 MTU... No matter which is the cwnd of the destination address, when retransmitting you send at most (and you are allowed to send at least) 1 MTU... Otherwise, you could bundle as many as you could in a single MTU of the destination address chosen for the retransmission... -- Laurent Glaude Software Engineer, Performance Technologies lglaude@pt.com - http://www.pt.com From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 23 12:28:44 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24465 for ; Wed, 23 Oct 2002 12:28:43 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NGQIIm028208 for ; Wed, 23 Oct 2002 09:26:18 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NGQGIR028778 for ; Wed, 23 Oct 2002 09:26:16 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9NGOgx5026991 for ; Wed, 23 Oct 2002 09:24:42 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NGJgUF009138; Wed, 23 Oct 2002 12:19:42 -0400 Received: from us.ibm.com ([9.41.94.148]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NGJdKc236414; Wed, 23 Oct 2002 12:19:40 -0400 Sender: root@northrelay01.pok.ibm.com Message-ID: <3DB6CBD8.C91E0450@us.ibm.com> Date: Wed, 23 Oct 2002 11:18:32 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> <3DB5BE21.B4D518ED@Motorola.com> <3DB5D631.A7F9E378@us.ibm.com> <3DB5E445.531B38FC@Motorola.com> Content-Type: multipart/alternative; boundary="------------1325B56EEE2BCD5D521DC9D9" --------------1325B56EEE2BCD5D521DC9D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > > > > One more thing, in your description, you said "if you pick t2 (as you > > seem to prefer), you will have to queue #4 behind #2 and #3, since you > > don't have any quato left on t2 since t2 is still under the 'max one > > chunk of upto MTU in flight allowed' mode", could you explain how t2 > > got into this mode? > > My mistake, when I wrote that I was thinking wrongly that t2 was the one > that got timed-out. But the fact that you didn't rtx #2 and #3 along > with #1 indicates that you ran out of cwnd on t2. So, if you insist to > picking t2 for rtx #4, you have to queue it after #2 and #3. > > You basically have a case where you have more data marked for rtx than > the cwnd of one dest addr allows and at the same time you have other > dest addresses in the association that still have cwnd room available. > My question to you is why keeping yourself from using the available cwnd > on those alternate dest addresses to re-send the rest of the data? I > don't think the spec prohibit that. It's up to the impl. > Ah, OK. I think that, the limitation of one MTU (single packet) came from RFC 6.3.3 (E3). Simply reading those bullets in 6.3.3, I would say that regardless the cwnd size of t2 at the time of t3 timeout, as long as it is bigger than, or equal to, 1 MTU, one and only one packet will be sent out with the retransmitted data. This is not a limitation from anything on t2, but rules for "Handle T3-rtx expiration". But apparently you were suggesting that we should send retransmission up to what is allowed by cwnd on t2. I gathered that you might be referring to the following paragraph in the end of 6.3.3, "Note: Any DATA chunks that were sent to the address for which the T3-rtx timer expired but did not fit in one MTU (rule E3 above), should be marked for retransmission and sent as soon as cwnd allows (normally when a SACK arrives)." Is that right? So, without SACK in the picture (not in our example), I should interprete this paragraph such that, the retransmission size at the T3-rtx timeout is subject to the cwnd size of the destination transport address to which the retransmission is being sent (this may be different from the address for which the timer expires). If this is true, I would agree that there is no reason why we couldn't send #2 and #3 on t2, right after #1, at the same time. The spec didn't prohibit that, but can be more clear, I think. :-) Thanks Daisy > > > If we assume that, this example begins with all > > three transports' cwnd up to, let's say, 4 * MTU at the moment, do > > you think that t2 would still end up in this mode given the sequence > > of events? > > > > Best Regards > > Daisy > > > > -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------1325B56EEE2BCD5D521DC9D9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit    Qiaobing Xie wrote:
>
> One more thing, in your description,  you said "if you pick t2 (as you
> seem to prefer), you will have to queue #4 behind #2 and #3, since you
> don't have any quato left on t2 since t2 is still under the 'max one
> chunk of upto MTU in flight allowed' mode", could you explain how t2
> got into this mode?

My mistake, when I wrote that I was thinking wrongly that t2 was the one
that got timed-out. But the fact that you didn't rtx #2 and #3 along
with #1 indicates that you ran out of cwnd on t2. So, if you insist to
picking t2 for rtx #4, you have to queue it after #2 and #3.

You basically have a case where you have more data marked for rtx than
the cwnd of one dest addr allows and at the same time you have other
dest addresses in the association that still have cwnd room available.
My question to you is why keeping yourself from using the available cwnd
on those alternate dest addresses to re-send the rest of the data? I
don't think the spec prohibit that. It's up to the impl.
 

Ah, OK.  I think that, the limitation of one MTU  (single packet) came from RFC 6.3.3 (E3).   Simply reading those bullets in 6.3.3, I would say that regardless the cwnd size of t2 at the time of t3 timeout, as long as it is bigger than, or equal to, 1 MTU, one and only one packet will be sent out with the retransmitted data.  This is not a limitation from anything on t2, but rules for "Handle T3-rtx expiration".

But apparently you were suggesting that we should send retransmission up to what is allowed by cwnd on t2.  I gathered that you might be referring to the following paragraph in the end of 6.3.3,

    "Note: Any DATA chunks that were sent to the address for which the
    T3-rtx timer expired but did not fit in one MTU (rule E3 above),
   should be marked for retransmission and sent as soon as cwnd allows
   (normally when a SACK arrives)."

Is that right? So, without SACK in the picture (not in our example), I should interprete this paragraph such that, the retransmission size at the T3-rtx timeout is subject to the cwnd size of the destination transport address to which the retransmission is being sent (this may be different from the address for which the timer expires).

If this is true, I would agree that there is no reason why we couldn't send #2 and #3 on t2, right after #1, at the same time.  The spec didn't prohibit that, but can be more clear, I think. :-)

Thanks
Daisy

 
> If we assume that, this example begins with all
> three transports' cwnd up to, let's say, 4 * MTU at the moment,  do
> you think that t2 would still end up in this mode given the sequence
> of events?
>
> Best Regards
> Daisy
>
>
-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------1325B56EEE2BCD5D521DC9D9-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 23 13:30:28 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26505 for ; Wed, 23 Oct 2002 13:30:27 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHMucl017503 for ; Wed, 23 Oct 2002 10:22:56 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHMvVu010878 for ; Wed, 23 Oct 2002 10:22:57 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9NHMtfB001648 for ; Wed, 23 Oct 2002 10:22:56 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA10766; Wed, 23 Oct 2002 10:17:24 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA29029; Wed, 23 Oct 2002 10:13:52 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9NHHLf18039; Wed, 23 Oct 2002 12:17:21 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA15718; Wed, 23 Oct 2002 12:18:30 -0500 (CDT) Message-ID: <3DB6DA49.BBB0096A@Motorola.com> Date: Wed, 23 Oct 2002 12:20:09 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daisy Chang CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> <3DB5BE21.B4D518ED@Motorola.com> <3DB5D631.A7F9E378@us.ibm.com> <3DB5E445.531B38FC@Motorola.com> <3DB6CBD8.C91E0450@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... > Ah, OK. I think that, the limitation of one MTU (single packet) came > from RFC 6.3.3 (E3). Simply reading those bullets in 6.3.3, I would > say that regardless the cwnd size of t2 at the time of t3 timeout, as > long as it is bigger than, or equal to, 1 MTU, one and only one packet > will be sent out with the retransmitted data. This is not a > limitation from anything on t2, but rules for "Handle T3-rtx > expiration". Remember SCTP congestion control is on a per dest addr basis (except for a shared rwnd for obvious reason). Time-out on one dest addr should not affect the CC behavior of any other dest addr. E.g., if you get a t-o on t3, you would not collapse cwnd of t2, would you? Some wording in the spec is made more for a single-homed peer (I think somewhere in the RFC Lixia made a comment on this). > > But apparently you were suggesting that we should send retransmission > up to what is allowed by cwnd on t2. I gathered that you might be > referring to the following paragraph in the end of 6.3.3, > > "Note: Any DATA chunks that were sent to the address for which the > T3-rtx timer expired but did not fit in one MTU (rule E3 above), > should be marked for retransmission and sent as soon as cwnd allows > (normally when a SACK arrives)." If the peer is single-homed, then you have to wait for a SACK to free up your cwnd. But in your case, you have 3 dest addrs and thus 3 cwnds and you still have room left in some of those 3 cwnds, right? Your impl does not have to take this advantage, but you can. > Is that right? So, without SACK in the picture (not in our example), I > should interprete this paragraph such that, the retransmission size at > the T3-rtx timeout is subject to the cwnd size of the destination > transport address to which the retransmission is being sent (this may > be different from the address for which the timer expires). You are almost right here. The exception is the dest addr which timed out.. that guy has one additional constraint - you can not have more than one packet in flight. > > If this is true, I would agree that there is no reason why we couldn't > send #2 and #3 on t2, right after #1, at the same time. The spec > didn't prohibit that, but can be more clear, I think. :-) The intention in the spec is that we discourage people from using more than one cwnd simultaneously if the peer is multi-homed, since otherwise an SCTP asoc would gain a unfair bandwidth advantage over a TCP connection. So we say in the spec "don't round-robin dest addresses". But when dealing with a t-o, I think it's reasonable to allow one take full advantage of the available cwnds. Of cause, an impl can choose not to... > > Thanks > Daisy > > > > > > If we assume that, this example begins with all > > > three transports' cwnd up to, let's say, 4 * MTU at the moment, > > do > > > you think that t2 would still end up in this mode given the > > sequence > > > of events? > > > > > > Best Regards > > > Daisy > > > > > > > > -- > > Thanks, > Daisy > > +--------------------------------------------------------------------------+ > Daisy Chang IBM Linux Technology Center > e-mail: tcdc@us.ibm.com > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 23 15:15:18 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00676 for ; Wed, 23 Oct 2002 15:15:13 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJ7Hcl017527 for ; Wed, 23 Oct 2002 12:07:17 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJ7FZ8017471 for ; Wed, 23 Oct 2002 12:07:15 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9NJ5nx5008951 for ; Wed, 23 Oct 2002 12:05:49 -0700 (PDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NJ0ool040146; Wed, 23 Oct 2002 15:00:54 -0400 Received: from us.ibm.com ([9.41.94.148]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NJ0n0k087796; Wed, 23 Oct 2002 13:00:49 -0600 Sender: root@westrelay01.boulder.ibm.com Message-ID: <3DB6F19C.50FE896B@us.ibm.com> Date: Wed, 23 Oct 2002 13:59:40 -0500 From: Daisy Chang X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: <3DB5A68F.DE8ECAD@us.ibm.com> <3DB5BE21.B4D518ED@Motorola.com> <3DB5D631.A7F9E378@us.ibm.com> <3DB5E445.531B38FC@Motorola.com> <3DB6CBD8.C91E0450@us.ibm.com> <3DB6DA49.BBB0096A@Motorola.com> Content-Type: multipart/alternative; boundary="------------4A1845F62BFA8EB3B2D78D7D" --------------4A1845F62BFA8EB3B2D78D7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Qiaobing, Your explanation really cleared up quite some confusions that I have in the past couple of days. Thank you so much. Regards, Daisy Qiaobing Xie wrote: > ... > > Ah, OK. I think that, the limitation of one MTU (single packet) came > > from RFC 6.3.3 (E3). Simply reading those bullets in 6.3.3, I would > > say that regardless the cwnd size of t2 at the time of t3 timeout, as > > long as it is bigger than, or equal to, 1 MTU, one and only one packet > > will be sent out with the retransmitted data. This is not a > > limitation from anything on t2, but rules for "Handle T3-rtx > > expiration". > > Remember SCTP congestion control is on a per dest addr basis (except for > a shared rwnd for obvious reason). Time-out on one dest addr should not > affect the CC behavior of any other dest addr. E.g., if you get a t-o on > t3, you would not collapse cwnd of t2, would you? Some wording in the > spec is made more for a single-homed peer (I think somewhere in the RFC > Lixia made a comment on this). > > > > > But apparently you were suggesting that we should send retransmission > > up to what is allowed by cwnd on t2. I gathered that you might be > > referring to the following paragraph in the end of 6.3.3, > > > > "Note: Any DATA chunks that were sent to the address for which the > > T3-rtx timer expired but did not fit in one MTU (rule E3 above), > > should be marked for retransmission and sent as soon as cwnd allows > > (normally when a SACK arrives)." > > If the peer is single-homed, then you have to wait for a SACK to free up > your cwnd. But in your case, you have 3 dest addrs and thus 3 cwnds and > you still have room left in some of those 3 cwnds, right? Your impl does > not have to take this advantage, but you can. > > > Is that right? So, without SACK in the picture (not in our example), I > > should interprete this paragraph such that, the retransmission size at > > the T3-rtx timeout is subject to the cwnd size of the destination > > transport address to which the retransmission is being sent (this may > > be different from the address for which the timer expires). > > You are almost right here. The exception is the dest addr which timed > out.. that guy has one additional constraint - you can not have more > than one packet in flight. > > > > > If this is true, I would agree that there is no reason why we couldn't > > send #2 and #3 on t2, right after #1, at the same time. The spec > > didn't prohibit that, but can be more clear, I think. :-) > > The intention in the spec is that we discourage people from using more > than one cwnd simultaneously if the peer is multi-homed, since otherwise > an SCTP asoc would gain a unfair bandwidth advantage over a TCP > connection. So we say in the spec "don't round-robin dest addresses". > But when dealing with a t-o, I think it's reasonable to allow one take > full advantage of the available cwnds. Of cause, an impl can choose not > to... > > > > > Thanks > > Daisy > > > > > > > > > If we assume that, this example begins with all > > > > three transports' cwnd up to, let's say, 4 * MTU at the moment, > > > do > > > > you think that t2 would still end up in this mode given the > > > sequence > > > > of events? > > > > > > > > Best Regards > > > > Daisy > > > > > > > > > > > > -- > > > > Thanks, > > Daisy > > > > +--------------------------------------------------------------------------+ > > Daisy Chang IBM Linux Technology Center > > e-mail: tcdc@us.ibm.com > > Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 > > 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 > > > > -- Thanks, Daisy +--------------------------------------------------------------------------+ Daisy Chang IBM Linux Technology Center e-mail: tcdc@us.ibm.com Tel: 512-838-4194 T/L: 678-4194 Fax: 512-838-4663 11400 Burnet Road, M/S 9812 Austin, TX 78758-3493 --------------4A1845F62BFA8EB3B2D78D7D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Qiaobing,
    Your explanation really cleared up quite some confusions that I have in the past couple of days.  Thank you so much.

Regards,
Daisy

Qiaobing Xie wrote:

...
> Ah, OK.  I think that, the limitation of one MTU  (single packet) came
> from RFC 6.3.3 (E3).   Simply reading those bullets in 6.3.3, I would
> say that regardless the cwnd size of t2 at the time of t3 timeout, as
> long as it is bigger than, or equal to, 1 MTU, one and only one packet
> will be sent out with the retransmitted data.  This is not a
> limitation from anything on t2, but rules for "Handle T3-rtx
> expiration".

Remember SCTP congestion control is on a per dest addr basis (except for
a shared rwnd for obvious reason). Time-out on one dest addr should not
affect the CC behavior of any other dest addr. E.g., if you get a t-o on
t3, you would not collapse cwnd of t2, would you? Some wording in the
spec is made more for a single-homed peer (I think somewhere in the RFC
Lixia made a comment on this).

>
> But apparently you were suggesting that we should send retransmission
> up to what is allowed by cwnd on t2.  I gathered that you might be
> referring to the following paragraph in the end of 6.3.3,
>
>    "Note: Any DATA chunks that were sent to the address for which the
>    T3-rtx timer expired but did not fit in one MTU (rule E3 above),
>    should be marked for retransmission and sent as soon as cwnd allows
>    (normally when a SACK arrives)."

If the peer is single-homed, then you have to wait for a SACK to free up
your cwnd. But in your case, you have 3 dest addrs and thus 3 cwnds and
you still have room left in some of those 3 cwnds, right? Your impl does
not have to take this advantage, but you can.

> Is that right? So, without SACK in the picture (not in our example), I
> should interprete this paragraph such that, the retransmission size at
> the T3-rtx timeout is subject to the cwnd size of the destination
> transport address to which the retransmission is being sent (this may
> be different from the address for which the timer expires).

You are almost right here. The exception is the dest addr which timed
out.. that guy has one additional constraint - you can not have more
than one packet in flight.

>
> If this is true, I would agree that there is no reason why we couldn't
> send #2 and #3 on t2, right after #1, at the same time.  The spec
> didn't prohibit that, but can be more clear, I think. :-)

The intention in the spec is that we discourage people from using more
than one cwnd simultaneously if the peer is multi-homed, since otherwise
an SCTP asoc would gain a unfair bandwidth advantage over a TCP
connection. So we say in the spec "don't round-robin dest addresses".
But when dealing with a t-o, I think it's reasonable to allow one take
full advantage of the available cwnds. Of cause, an impl can choose not
to...

>
> Thanks
> Daisy
>
> >
> > > If we assume that, this example begins with all
> > > three transports' cwnd up to, let's say, 4 * MTU at the moment,
> > do
> > > you think that t2 would still end up in this mode given the
> > sequence
> > > of events?
> > >
> > > Best Regards
> > > Daisy
> > >
> > >
>
> --
>
> Thanks,
> Daisy
>
> +--------------------------------------------------------------------------+
> Daisy Chang                     IBM Linux Technology Center
> e-mail: tcdc@us.ibm.com
> Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663
> 11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
>
>

-- 
 
Thanks,
Daisy

+--------------------------------------------------------------------------+
Daisy Chang                     IBM Linux Technology Center          
e-mail: tcdc@us.ibm.com 
Tel: 512-838-4194  T/L: 678-4194  Fax: 512-838-4663                  
11400 Burnet Road, M/S 9812     Austin, TX 78758-3493
  --------------4A1845F62BFA8EB3B2D78D7D-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 23 15:51:37 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03187 for ; Wed, 23 Oct 2002 15:51:36 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJjScl007739 for ; Wed, 23 Oct 2002 12:45:28 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJjTHS001087 for ; Wed, 23 Oct 2002 12:45:29 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9NJjNWJ023228 for ; Wed, 23 Oct 2002 12:45:24 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA03523; Wed, 23 Oct 2002 12:40:30 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA08163; Wed, 23 Oct 2002 12:40:19 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9NJeGf29793; Wed, 23 Oct 2002 14:40:16 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15845; Wed, 23 Oct 2002 14:41:25 -0500 (CDT) Message-ID: <3DB6EC86.5BBF51C4@Motorola.com> Date: Wed, 23 Oct 2002 13:37:58 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tcdc@us.ibm.com, sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ivan, In general I think you are interpretation the spec more restrictively than it intends to be... which is of cause good for the network :-) See my comments below... ... > > Transmitted: > > t1: (#1, #2, #3) > > t2: (#1), #2 > > t3: (#4) > > marked for retransmission: #3. #4 First, you can not re-send #2 to t2, because there is no cwnd left on t2 after you re-sent #1 over it, right? In fact at the point, your cwnd status should be: t1/1 MTU; t2/none; t3/1 MTU... You can choose to be conservative and not to use the remaining 2 MTU quota the network allows you.. This of cause is fine. > Again, I'm assuming that 1 TSN = 1 MTU... No matter which is the cwnd of the destination address, when retransmitting you send at most (and you are allowed to send at least) 1 MTU... Otherwise, you could bundle as many as you could in a single MTU of the destination address chosen for the retransmission... > This interpretation is very conservative, IMO. > > or > > Transmitted: > > t1: (#1, #2, #3) > > t2: (#1), #4 > > t3: (#4) > > marked for retransmission: #2, #3 > > or > > I don't think that this is what you should do for the reasons I said above... Please note that this is just my suggestion (I cannot assure that I'm right :-)). > > (oops! I took a look to the RFC, and it seems that section 6.3.3 E3) says that you should precisely do this... Now I'm as confused as you, Daisy) > Obviously the wording there is not meant to address a double t-o event like what we are talking about here :-) I probably will go for re-sending #2 first (i.e. the *overall oldest* TSN marked for re-trans). That makes better sense to me. -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 23 16:00:22 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03417 for ; Wed, 23 Oct 2002 16:00:21 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJn3cl009543 for ; Wed, 23 Oct 2002 12:49:03 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJn5sM023162 for ; Wed, 23 Oct 2002 12:49:05 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9NJmwWJ025180 for ; Wed, 23 Oct 2002 12:48:59 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA16420; Wed, 23 Oct 2002 12:43:58 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA07221; Wed, 23 Oct 2002 12:40:25 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9NJeEf29789; Wed, 23 Oct 2002 14:40:14 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15841; Wed, 23 Oct 2002 14:41:23 -0500 (CDT) Message-ID: <3DB6E628.9C9B5950@Motorola.com> Date: Wed, 23 Oct 2002 13:10:48 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mohammed Ashraf CC: Daisy Chang , sctp-impl@external.cisco.com Subject: Re: question regarding retransmission References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mohammed Ashraf wrote: > > Isn't always better to maintain the order while retransmiting also. Since it > helps to dequeue chunks from the sender Q fastly(otherwise it may result in > blocking at the sender side ) Sure, if the impl feels that is convenient to do.. From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 24 08:32:02 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04128 for ; Thu, 24 Oct 2002 08:32:01 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OCUGxF013298 for ; Thu, 24 Oct 2002 05:30:16 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OCUIrn028049 for ; Thu, 24 Oct 2002 05:30:18 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9OCU9Eo003731 for ; Thu, 24 Oct 2002 05:30:12 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9OCBbH02225 for ; Thu, 24 Oct 2002 15:11:37 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Oct 2002 15:11:23 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 15:11:22 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 15:11:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question regarding retransmission Date: Thu, 24 Oct 2002 15:11:21 +0300 Message-ID: Thread-Topic: question regarding retransmission Thread-Index: AcJ6zOkOG5LGKfU5TKK+hvuYRlWfTQAiCK3g From: To: Cc: , , X-OriginalArrivalTime: 24 Oct 2002 12:11:22.0032 (UTC) FILETIME=[77653300:01C27B56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04128 Aha... alright, now I'm completely lost... :-) I have always thought exactly this "why putting a limitation in the number of packets after a retransmission, other than the cwnd of the new destination address (and rwnd)?"... I simply didn't understand why... And I have always gotten the answer "we are dealing with multihomed peers, something new in the internet, and we have to be conservative. Besides, depending on your configuration, it is likely that even if the destination address is different, most of the network path is shared"... :-0 And now, what? If the idea is as Qiaobing says, then definitely the RFC is wrong. Because it clearly states that you send "one and only one" no matter where to... And this is what I have always done (internally thinking at the same time that it wasn't the best option, but...), because it has been what people have told me to do... :-/ And actually it was much easier coding it the other way (Qiaobing's)... Any more comments from some more people? I think this is not really something internal to the implementation but really an SCTP issue... I will send it also to the TSVWG (however, lacking the previous mails I don't know if they are going to understand much)... Thanks! BR Iván Arias Rodríguez > -----Original Message----- > From: ext Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > Sent: 23. October 2002 21:38 > To: Arias-Rodriguez Ivan (NRC/Helsinki) > Cc: tcdc@us.ibm.com; sctp-impl@external.cisco.com > Subject: Re: question regarding retransmission > > > Ivan, > > In general I think you are interpretation the spec more restrictively > than it intends to be... which is of cause good for the > network :-) See > my comments below... > > ... > > > Transmitted: > > > t1: (#1, #2, #3) > > > t2: (#1), #2 > > > t3: (#4) > > > marked for retransmission: #3. #4 > > First, you can not re-send #2 to t2, because there is no cwnd > left on t2 > after you re-sent #1 over it, right? > > In fact at the point, your cwnd status should be: t1/1 MTU; t2/none; > t3/1 MTU... You can choose to be conservative and not to use the > remaining 2 MTU quota the network allows you.. This of cause is fine. > > > Again, I'm assuming that 1 TSN = 1 MTU... No matter > which is the cwnd of the destination address, when > retransmitting you send at most (and you are allowed to send > at least) 1 MTU... Otherwise, you could bundle as many as you > could in a single MTU of the destination address chosen for > the retransmission... > > > > This interpretation is very conservative, IMO. > > > > or > > > Transmitted: > > > t1: (#1, #2, #3) > > > t2: (#1), #4 > > > t3: (#4) > > > marked for retransmission: #2, #3 > > > or > > > > I don't think that this is what you should do for > the reasons I said above... Please note that this is just my > suggestion (I cannot assure that I'm right :-)). > > > > (oops! I took a look to the RFC, and it seems that > section 6.3.3 E3) says that you should precisely do this... > Now I'm as confused as you, Daisy) > > > > Obviously the wording there is not meant to address a double t-o event > like what we are talking about here :-) I probably will go for > re-sending #2 first (i.e. the *overall oldest* TSN marked for > re-trans). > That makes better sense to me. > > -Qiaobing > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 24 12:19:59 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14345 for ; Thu, 24 Oct 2002 12:19:58 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9OGHOot003462 for ; Thu, 24 Oct 2002 09:17:24 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OGHJoB018510 for ; Thu, 24 Oct 2002 09:17:19 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9OGHMB4027177 for ; Thu, 24 Oct 2002 09:17:23 -0700 (PDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9OGApCf106608; Thu, 24 Oct 2002 12:10:51 -0400 Received: from d03nm125.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9OGCfmN058972; Thu, 24 Oct 2002 10:12:43 -0600 Importance: Normal Subject: Re: [Tsvwg] RE: question regarding retransmission To: Ivan.Arias-Rodriguez@nokia.com Cc: , tcdc@us.ibm.com, , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Daisy Chang" Date: Thu, 24 Oct 2002 11:14:25 -0500 X-MIMETrack: Serialize by Router on D03NM125/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/24/2002 10:10:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14345 Ivan, I definitely would say that the RFC could be clearer on this. The wording in RFC2960 6.3.3 (E3) is very misleading: "E3) Determine how many of the earliest (i.e., lowest TSN) outstanding ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DATA chunks for the address for which the T3-rtx has expired will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ fit into a single packet, subject to the MTU constraint for the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ path corresponding to the destination transport address to which the retransmission is being sent (this may be different from the address for which the timer expires [see Section 6.4]). Call this value K. Bundle and retransmit those K DATA chunks in a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ single packet to the destination endpoint." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From Qiaobing's answers to my question, I drew these conclusions myself, 1. The definition of "the earliest (i.e., lowest TSN) outstanding DATA chunks for the address for which T3-rtx has expired" is up to the implementation. With multiple transports, if the earliest outstanding DATA chunks were marked for retransmission due to timer expirations for other transports, they are certainly eligible to be taken into consideration. 2. The retransmission size is not limited to one packet (1 MTU). Implementations could retransmit up to what the cwnd of the outgoing transport would allow. If I didn't interpret Qiaobing's answers wrongly, I believe that this probably merits an amendment to implementator's guide to prevent people from having the same confusions that I have. Thanks, Daisy Chang IBM Linux Technology Center daisyc@us.ibm.com Tel: (512)-838-4194 T/L: 678-4194 FAX: (512)-838-4663 Ivan.Arias-Rodriguez@nokia.com@ietf.org on 10/24/2002 07:11:21 AM Sent by: tsvwg-admin@ietf.org To: cc: tcdc@us.ltcfwd.linux.ibm.com, , Subject: [Tsvwg] RE: question regarding retransmission Aha... alright, now I'm completely lost... :-) I have always thought exactly this "why putting a limitation in the number of packets after a retransmission, other than the cwnd of the new destination address (and rwnd)?"... I simply didn't understand why... And I have always gotten the answer "we are dealing with multihomed peers, something new in the internet, and we have to be conservative. Besides, depending on your configuration, it is likely that even if the destination address is different, most of the network path is shared"... :-0 And now, what? If the idea is as Qiaobing says, then definitely the RFC is wrong. Because it clearly states that you send "one and only one" no matter where to... And this is what I have always done (internally thinking at the same time that it wasn't the best option, but...), because it has been what people have told me to do... :-/ And actually it was much easier coding it the other way (Qiaobing's)... Any more comments from some more people? I think this is not really something internal to the implementation but really an SCTP issue... I will send it also to the TSVWG (however, lacking the previous mails I don't know if they are going to understand much)... Thanks! BR Iván Arias Rodríguez > -----Original Message----- > From: ext Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > Sent: 23. October 2002 21:38 > To: Arias-Rodriguez Ivan (NRC/Helsinki) > Cc: tcdc@us.ibm.com; sctp-impl@external.cisco.com > Subject: Re: question regarding retransmission > > > Ivan, > > In general I think you are interpretation the spec more restrictively > than it intends to be... which is of cause good for the > network :-) See > my comments below... > > ... > > > Transmitted: > > > t1: (#1, #2, #3) > > > t2: (#1), #2 > > > t3: (#4) > > > marked for retransmission: #3. #4 > > First, you can not re-send #2 to t2, because there is no cwnd > left on t2 > after you re-sent #1 over it, right? > > In fact at the point, your cwnd status should be: t1/1 MTU; t2/none; > t3/1 MTU... You can choose to be conservative and not to use the > remaining 2 MTU quota the network allows you.. This of cause is fine. > > > Again, I'm assuming that 1 TSN = 1 MTU... No matter > which is the cwnd of the destination address, when > retransmitting you send at most (and you are allowed to send > at least) 1 MTU... Otherwise, you could bundle as many as you > could in a single MTU of the destination address chosen for > the retransmission... > > > > This interpretation is very conservative, IMO. > > > > or > > > Transmitted: > > > t1: (#1, #2, #3) > > > t2: (#1), #4 > > > t3: (#4) > > > marked for retransmission: #2, #3 > > > or > > > > I don't think that this is what you should do for > the reasons I said above... Please note that this is just my > suggestion (I cannot assure that I'm right :-)). > > > > (oops! I took a look to the RFC, and it seems that > section 6.3.3 E3) says that you should precisely do this... > Now I'm as confused as you, Daisy) > > > > Obviously the wording there is not meant to address a double t-o event > like what we are talking about here :-) I probably will go for > re-sending #2 first (i.e. the *overall oldest* TSN marked for > re-trans). > That makes better sense to me. > > -Qiaobing > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 24 15:26:47 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20645 for ; Thu, 24 Oct 2002 15:26:46 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJP9ot027470 for ; Thu, 24 Oct 2002 12:25:09 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJP2YY008151 for ; Thu, 24 Oct 2002 12:25:02 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OJNYE3001043 for ; Thu, 24 Oct 2002 12:23:35 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA29839; Thu, 24 Oct 2002 12:20:01 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA09798; Thu, 24 Oct 2002 12:20:01 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9OJJwf17014; Thu, 24 Oct 2002 14:19:58 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA17111; Thu, 24 Oct 2002 14:21:07 -0500 (CDT) Message-ID: <3DB8488C.3788960E@Motorola.com> Date: Thu, 24 Oct 2002 14:22:52 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daisy Chang CC: Ivan.Arias-Rodriguez@nokia.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Ivan and Daisy, I disagree with you here. I think the RFC is well written. What you might have not paid enough attention to is the text above the rules you are now focusing on. When reading the detailed CC rules in chapter 7, one MUST keep in mind the assumptions made in 7.1 (Lixia and Vern please correct me if my memory is faulty here, you two are the owner of the text in 7). In particular: "The sender usually uses the same destination address..." and "The sender keeps a separate congestion control parameter set for each of the destination addresses..." **The CC rules that follow are narrated under this "same dest addr" assumptions** And multi-homed peer is dealt with in the first bullet in 7.1: "...(keep using the same dest addr) until being instructed by the upper layer otherwise; however, SCTP may change to an alternate destination in the event an address is marked inactive (see Section 8.2). Also, SCTP may retransmit to a different transport address than the original transmission" This lays out the three cases where a diff dest addr may become involved. And the second assumption in 7.1 makes it perfectly clear that this second dest addr, when becoming involved, will bring its **own** CC param and (implied) status. Now, to answer Ivan's question, let me ask you a question, when your dest addr t3 timed out and its CC status changed accordingly, why do you want to modify t2 and t1's CC status as well? (remember, applying "no more than one packet in-flight" globally constitutes a change of CC status of every dest address) -Qiaobing Daisy Chang wrote: > > Ivan, > I definitely would say that the RFC could be clearer on this. The > wording in > RFC2960 6.3.3 (E3) is very misleading: > > "E3) Determine how many of the earliest (i.e., lowest TSN) outstanding > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > DATA chunks for the address for which the T3-rtx has expired will > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > fit into a single packet, subject to the MTU constraint for the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > path corresponding to the destination transport address to which > the retransmission is being sent (this may be different from the > address for which the timer expires [see Section 6.4]). Call > this value K. Bundle and retransmit those K DATA chunks in a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > single packet to the destination endpoint." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > From Qiaobing's answers to my question, I drew these conclusions myself, > 1. The definition of "the earliest (i.e., lowest TSN) outstanding DATA chunks for the address > for which T3-rtx has expired" is up to the implementation. With multiple transports, if the earliest > outstanding DATA chunks were marked for retransmission due to timer expirations for other > transports, they are certainly eligible to be taken into consideration. > 2. The retransmission size is not limited to one packet (1 MTU). Implementations could > retransmit up to what the cwnd of the outgoing transport would allow. > > If I didn't interpret Qiaobing's answers wrongly, I believe that this probably merits an > amendment to implementator's guide to prevent people from having the same confusions > that I have. > > Thanks, > Daisy Chang > IBM Linux Technology Center > daisyc@us.ibm.com > Tel: (512)-838-4194 T/L: 678-4194 > FAX: (512)-838-4663 > > Ivan.Arias-Rodriguez@nokia.com@ietf.org on 10/24/2002 07:11:21 AM > > Sent by: tsvwg-admin@ietf.org > > To: > cc: tcdc@us.ltcfwd.linux.ibm.com, , > > Subject: [Tsvwg] RE: question regarding retransmission > > Aha... alright, now I'm completely lost... :-) > > I have always thought exactly this "why putting a limitation > in the number of packets after a retransmission, other than the cwnd of the > new destination address (and rwnd)?"... I simply didn't understand why... > And I have always gotten the answer "we are dealing with multihomed peers, > something new in the internet, and we have to be conservative. Besides, > depending on your configuration, it is likely that even if the destination > address is different, most of the network path is shared"... :-0 > > And now, what? > > If the idea is as Qiaobing says, then definitely the RFC is > wrong. Because it clearly states that you send "one and only one" no matter > where to... And this is what I have always done (internally thinking at the > same time that it wasn't the best option, but...), because it has been what > people have told me to do... :-/ And actually it was much easier coding it > the other way (Qiaobing's)... > > Any more comments from some more people? > > I think this is not really something internal to the > implementation but really an SCTP issue... I will send it also to the TSVWG > (however, lacking the previous mails I don't know if they are going to > understand much)... > > Thanks! > > BR Iván Arias Rodríguez > > > -----Original Message----- > > From: ext Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > > Sent: 23. October 2002 21:38 > > To: Arias-Rodriguez Ivan (NRC/Helsinki) > > Cc: tcdc@us.ibm.com; sctp-impl@external.cisco.com > > Subject: Re: question regarding retransmission > > > > > > Ivan, > > > > In general I think you are interpretation the spec more restrictively > > than it intends to be... which is of cause good for the > > network :-) See > > my comments below... > > > > ... > > > > Transmitted: > > > > t1: (#1, #2, #3) > > > > t2: (#1), #2 > > > > t3: (#4) > > > > marked for retransmission: #3. #4 > > > > First, you can not re-send #2 to t2, because there is no cwnd > > left on t2 > > after you re-sent #1 over it, right? > > > > In fact at the point, your cwnd status should be: t1/1 MTU; t2/none; > > t3/1 MTU... You can choose to be conservative and not to use the > > remaining 2 MTU quota the network allows you.. This of cause is fine. > > > > > Again, I'm assuming that 1 TSN = 1 MTU... No matter > > which is the cwnd of the destination address, when > > retransmitting you send at most (and you are allowed to send > > at least) 1 MTU... Otherwise, you could bundle as many as you > > could in a single MTU of the destination address chosen for > > the retransmission... > > > > > > > This interpretation is very conservative, IMO. > > > > > > or > > > > Transmitted: > > > > t1: (#1, #2, #3) > > > > t2: (#1), #4 > > > > t3: (#4) > > > > marked for retransmission: #2, #3 > > > > or > > > > > > I don't think that this is what you should do for > > the reasons I said above... Please note that this is just my > > suggestion (I cannot assure that I'm right :-)). > > > > > > (oops! I took a look to the RFC, and it seems that > > section 6.3.3 E3) says that you should precisely do this... > > Now I'm as confused as you, Daisy) > > > > > > > Obviously the wording there is not meant to address a double t-o event > > like what we are talking about here :-) I probably will go for > > re-sending #2 first (i.e. the *overall oldest* TSN marked for > > re-trans). > > That makes better sense to me. > > > > -Qiaobing > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 24 15:51:55 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21162 for ; Thu, 24 Oct 2002 15:51:53 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJogot013347 for ; Thu, 24 Oct 2002 12:50:43 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJogbe003924 for ; Thu, 24 Oct 2002 12:50:42 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OJn9E3017653 for ; Thu, 24 Oct 2002 12:49:10 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA26632; Thu, 24 Oct 2002 12:45:37 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA28470; Thu, 24 Oct 2002 12:45:36 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9OJjWf19105; Thu, 24 Oct 2002 14:45:33 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA17133; Thu, 24 Oct 2002 14:46:42 -0500 (CDT) Message-ID: <3DB84E8B.72D7B4DE@Motorola.com> Date: Thu, 24 Oct 2002 14:48:27 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daisy Chang , Ivan.Arias-Rodriguez@nokia.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: <3DB8488C.3788960E@Motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit .... > Now, to answer Ivan's question, let me ask you a question, when your > dest addr t3 timed out and its CC status changed accordingly, why do you > want to modify t2 and t1's CC status as well? (remember, applying "no > more than one packet in-flight" globally constitutes a change of CC > status of every dest address) BTW, as I said before, there is nothing wrong if an impl chooses to apply "no more than one packet in-flight" globally after a t-o on any dest addr. This is just be more conservative and the RFC specifically says in 7 that: IMPLEMENTATION NOTE: As far as its specific performance requirements are met, an implementation is always allowed to adopt a more conservative congestion control algorithm than the one defined below. So the comments you heard before that this is the right thing to do is always valid. -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 24 16:13:20 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21782 for ; Thu, 24 Oct 2002 16:13:19 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKBGIm014587 for ; Thu, 24 Oct 2002 13:11:16 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKBBRf017019 for ; Thu, 24 Oct 2002 13:11:11 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OK8pE3002875 for ; Thu, 24 Oct 2002 13:08:52 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA13211; Thu, 24 Oct 2002 13:04:14 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA04841; Thu, 24 Oct 2002 13:04:13 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9OK49f20629; Thu, 24 Oct 2002 15:04:10 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17147; Thu, 24 Oct 2002 15:05:19 -0500 (CDT) Message-ID: <3DB852E8.50D99513@Motorola.com> Date: Thu, 24 Oct 2002 15:07:04 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: daisyc@us.ibm.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... > The problem in my opinion, is that parts of the RFC are > written thinking in a "classical" host (single homed), while some > others do really take into account multihoming... This makes that > some paragraphs are confusing... This is the key to read the CC rules in RFC2960 correctly. And everything will start to make sense for you if you keep in mind that the rules are assuming "the same dest addr is being used for send and re-send" and a self-contained within a single dest addr. But I don't think this is a problem. I remember we talked about this and considered this is a good strategy to depict SCTP CC rules, because we wanted to have the rules be easily comparable with those of TCP's and be easily cross-examined later to ensure the fairness and friendliness between the two. The catch is that one must read and keep in mind the assumptions made at the beginning of the chapter. -Q From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 24 16:32:31 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22360 for ; Thu, 24 Oct 2002 16:32:30 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKUrot011979 for ; Thu, 24 Oct 2002 13:30:53 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKUpwl011683 for ; Thu, 24 Oct 2002 13:30:52 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9OKUnB4024971 for ; Thu, 24 Oct 2002 13:30:50 -0700 (PDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9OKAiw25912 for ; Thu, 24 Oct 2002 23:10:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Oct 2002 23:11:05 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 23:11:05 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 23:11:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] RE: question regarding retransmission Date: Thu, 24 Oct 2002 23:11:04 +0300 Message-ID: Thread-Topic: [Tsvwg] RE: question regarding retransmission Thread-Index: AcJ7mKzg2g1UWXShR5OrZqV6c/WdjQAAAs/w From: To: Cc: , , , X-OriginalArrivalTime: 24 Oct 2002 20:11:05.0037 (UTC) FILETIME=[7B6737D0:01C27B99] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA22360 > ... > > The problem in my opinion, is that parts of the RFC are > > written thinking in a "classical" host (single homed), while some > > others do really take into account multihoming... This makes that > > some paragraphs are confusing... > > This is the key to read the CC rules in RFC2960 correctly. And > everything will start to make sense for you if you keep in > mind that the > rules are assuming "the same dest addr is being used for send and > re-send" and a self-contained within a single dest addr. However, the possible existence of other addresses is clearly stated in section 6.3.3, even in E3)... > But I don't think this is a problem. I remember we talked > about this and > considered this is a good strategy to depict SCTP CC rules, because we > wanted to have the rules be easily comparable with those of > TCP's and be > easily cross-examined later to ensure the fairness and friendliness > between the two. The catch is that one must read and keep in mind the > assumptions made at the beginning of the chapter. Also, I remember asking about this same issue and being told that what I had to do was sending a single packet... It seems that different co-authors make different interpretations... At the end I think that a wise way to act is: don't do what the standard seems to say, but what you think is the way that makes more sense (as far as nobody can easily realize)... :-) Thanks! BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 24 16:47:14 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22806 for ; Thu, 24 Oct 2002 16:47:13 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKB8xF004863 for ; Thu, 24 Oct 2002 13:11:08 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKB6OI016923 for ; Thu, 24 Oct 2002 13:11:06 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OK8EE3002276 for ; Thu, 24 Oct 2002 13:08:16 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9OJp9H20153 for ; Thu, 24 Oct 2002 22:51:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Oct 2002 22:50:56 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 22:50:56 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 22:50:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] RE: question regarding retransmission Date: Thu, 24 Oct 2002 22:50:55 +0300 Message-ID: Thread-Topic: [Tsvwg] RE: question regarding retransmission Thread-Index: AcJ7kpG7MVv+0WMzQMeCrQrudrCqFAAAM/bg From: To: , Cc: , , X-OriginalArrivalTime: 24 Oct 2002 19:50:55.0567 (UTC) FILETIME=[AA80BDF0:01C27B96] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA22806 Qiaobing, I don't want to change the CC state of any other address but the one whose T3 expired... However, the E3) subsection of 6.3.3 leaves completely clear, in my opinion, than only one packet should be sent regarding this retransmission... And it even says that you send the TSN that were in flight when T3 expired, without taking into account that there could be some older TSNs still marked for retransmission due to, for example, fast retransmit... I see your point that nothing will stop me later to send more data... Yes, supposing I have two addresses t1 and t2, if T3 for t1 expires, I resend one TSN to t2. If right after that, the user gives me more data to send to t2, of course I will do it as far as cwnd allows... However, the statement in that section is really confusing... Well, from my point of view it clearly states a different thing than Qiaobing's interpretation... It says, send "a single packet"... In the normal case with two addresses and using one as primary, if T3 expires on t1 while have a lot of TSN in flight, then what Qiaobing says is that we should send 2*MTU worth of data (assuming t2 is in idle state), i.e., two packets, instead of one... The problem in my opinion, is that parts of the RFC are written thinking in a "classical" host (single homed), while some others do really take into account multihoming... This makes that some paragraphs are confusing... Is the general opinion here that only cwnd should limit? (this really makes sense for me but it is not what the RFC says). Thanks for your comments Daisy and Qiaobing! BR Iván Arias Rodríguez > -----Original Message----- > From: ext Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com] > Sent: 24. October 2002 22:23 > To: Daisy Chang > Cc: Arias-Rodriguez Ivan (NRC/Helsinki); tcdc@us.ibm.com; > sctp-impl@external.cisco.com; tsvwg@ietf.org > Subject: Re: [Tsvwg] RE: question regarding retransmission > > > Hi, Ivan and Daisy, > > I disagree with you here. I think the RFC is well written. What you > might have not paid enough attention to is the text above the > rules you > are now focusing on. > > When reading the detailed CC rules in chapter 7, one MUST keep in mind > the assumptions made in 7.1 (Lixia and Vern please correct me if my > memory is faulty here, you two are the owner of the text in 7). > > In particular: > > "The sender usually uses the same destination address..." > and > "The sender keeps a separate congestion control parameter set > for each of the destination addresses..." > > **The CC rules that follow are narrated under this "same dest addr" > assumptions** > > And multi-homed peer is dealt with in the first bullet in 7.1: > "...(keep using the same dest addr) until being instructed > by the upper layer otherwise; however, SCTP may change > to an alternate destination in the event an address is marked > inactive (see Section 8.2). Also, SCTP may retransmit to a > different transport address than the original transmission" > > This lays out the three cases where a diff dest addr may become > involved. And the second assumption in 7.1 makes it perfectly > clear that > this second dest addr, when becoming involved, will bring its > **own** CC > param and (implied) status. > > Now, to answer Ivan's question, let me ask you a question, when your > dest addr t3 timed out and its CC status changed accordingly, > why do you > want to modify t2 and t1's CC status as well? (remember, applying "no > more than one packet in-flight" globally constitutes a change of CC > status of every dest address) > > -Qiaobing > > Daisy Chang wrote: > > > > Ivan, > > I definitely would say that the RFC could be clearer > on this. The > > wording in > > RFC2960 6.3.3 (E3) is very misleading: > > > > "E3) Determine how many of the earliest (i.e., lowest TSN) > outstanding > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > DATA chunks for the address for which the T3-rtx has > expired will > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > fit into a single packet, subject to the MTU > constraint for the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > path corresponding to the destination transport > address to which > > the retransmission is being sent (this may be > different from the > > address for which the timer expires [see Section 6.4]). Call > > this value K. Bundle and retransmit those K DATA chunks in a > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > single packet to the destination endpoint." > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > From Qiaobing's answers to my question, I drew these > conclusions myself, > > 1. The definition of "the earliest (i.e., lowest TSN) > outstanding DATA chunks for the address > > for which T3-rtx has expired" is up to the implementation. > With multiple transports, if the earliest > > outstanding DATA chunks were marked for retransmission due > to timer expirations for other > > transports, they are certainly eligible to be taken into > consideration. > > 2. The retransmission size is not limited to one packet (1 > MTU). Implementations could > > retransmit up to what the cwnd of the outgoing transport > would allow. > > > > If I didn't interpret Qiaobing's answers wrongly, I > believe that this probably merits an > > amendment to implementator's guide to prevent people from > having the same confusions > > that I have. > > > > Thanks, > > Daisy Chang > > IBM Linux Technology Center > > daisyc@us.ibm.com > > Tel: (512)-838-4194 T/L: 678-4194 > > FAX: (512)-838-4663 > > > > Ivan.Arias-Rodriguez@nokia.com@ietf.org on 10/24/2002 07:11:21 AM > > > > Sent by: tsvwg-admin@ietf.org > > > > To: > > cc: tcdc@us.ltcfwd.linux.ibm.com, , > > > > Subject: [Tsvwg] RE: question regarding retransmission > > > > Aha... alright, now I'm completely lost... :-) > > > > I have always thought exactly this "why > putting a limitation > > in the number of packets after a retransmission, other than > the cwnd of the > > new destination address (and rwnd)?"... I simply didn't > understand why... > > And I have always gotten the answer "we are dealing with > multihomed peers, > > something new in the internet, and we have to be > conservative. Besides, > > depending on your configuration, it is likely that even if > the destination > > address is different, most of the network path is shared"... :-0 > > > > And now, what? > > > > If the idea is as Qiaobing says, then > definitely the RFC is > > wrong. Because it clearly states that you send "one and > only one" no matter > > where to... And this is what I have always done (internally > thinking at the > > same time that it wasn't the best option, but...), because > it has been what > > people have told me to do... :-/ And actually it was much > easier coding it > > the other way (Qiaobing's)... > > > > Any more comments from some more people? > > > > I think this is not really something internal to the > > implementation but really an SCTP issue... I will send it > also to the TSVWG > > (however, lacking the previous mails I don't know if they > are going to > > understand much)... > > > > Thanks! > > > > BR Iván Arias Rodríguez > > > > > -----Original Message----- > > > From: ext Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] > > > Sent: 23. October 2002 21:38 > > > To: Arias-Rodriguez Ivan (NRC/Helsinki) > > > Cc: tcdc@us.ibm.com; sctp-impl@external.cisco.com > > > Subject: Re: question regarding retransmission > > > > > > > > > Ivan, > > > > > > In general I think you are interpretation the spec more > restrictively > > > than it intends to be... which is of cause good for the > > > network :-) See > > > my comments below... > > > > > > ... > > > > > Transmitted: > > > > > t1: (#1, #2, #3) > > > > > t2: (#1), #2 > > > > > t3: (#4) > > > > > marked for retransmission: #3. #4 > > > > > > First, you can not re-send #2 to t2, because there is no cwnd > > > left on t2 > > > after you re-sent #1 over it, right? > > > > > > In fact at the point, your cwnd status should be: t1/1 > MTU; t2/none; > > > t3/1 MTU... You can choose to be conservative and not to use the > > > remaining 2 MTU quota the network allows you.. This of > cause is fine. > > > > > > > Again, I'm assuming that 1 TSN = 1 MTU... No matter > > > which is the cwnd of the destination address, when > > > retransmitting you send at most (and you are allowed to send > > > at least) 1 MTU... Otherwise, you could bundle as many as you > > > could in a single MTU of the destination address chosen for > > > the retransmission... > > > > > > > > > > This interpretation is very conservative, IMO. > > > > > > > > or > > > > > Transmitted: > > > > > t1: (#1, #2, #3) > > > > > t2: (#1), #4 > > > > > t3: (#4) > > > > > marked for retransmission: #2, #3 > > > > > or > > > > > > > > I don't think that this is what you should do for > > > the reasons I said above... Please note that this is just my > > > suggestion (I cannot assure that I'm right :-)). > > > > > > > > (oops! I took a look to the RFC, and it seems that > > > section 6.3.3 E3) says that you should precisely do this... > > > Now I'm as confused as you, Daisy) > > > > > > > > > > Obviously the wording there is not meant to address a > double t-o event > > > like what we are talking about here :-) I probably will go for > > > re-sending #2 first (i.e. the *overall oldest* TSN marked for > > > re-trans). > > > That makes better sense to me. > > > > > > -Qiaobing > > > > > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Oct 24 17:14:15 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23923 for ; Thu, 24 Oct 2002 17:14:14 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKcPgM021860 for ; Thu, 24 Oct 2002 13:38:25 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKcNir012683 for ; Thu, 24 Oct 2002 13:38:23 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OKaXE3026061 for ; Thu, 24 Oct 2002 13:36:34 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA07547 for ; Thu, 24 Oct 2002 13:33:01 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA03881 for ; Thu, 24 Oct 2002 13:29:27 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9OKTHf22822; Thu, 24 Oct 2002 15:29:17 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17173; Thu, 24 Oct 2002 15:30:27 -0500 (CDT) Message-ID: <3DB858CC.B02E2A22@Motorola.com> Date: Thu, 24 Oct 2002 15:32:12 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: daisyc@us.ibm.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit .... > Also, I remember asking about this same issue and being told that what I had to do was sending a single packet... It seems that different co-authors make different interpretations... I think we all agree on that we do not want to do anything more aggressive than what the RFC depicts, but we may be different on how conservative we want to be when it comes to a specific implementation. And we agree that we can disagree on the latter. So, we are all on the same page :-) > > At the end I think that a wise way to act is: don't do what the standard seems to say, but what you think is the way that makes more sense (as far as nobody can easily realize)... :-) I hope by "sense" here you meant one that is based on the understanding of the design spirit of the protocol. That would help one overcoming the limitation of textual communications :-) -Qiaobing > > Thanks! > > BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 24 19:48:31 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27280 for ; Thu, 24 Oct 2002 19:48:30 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKBGIm014587 for ; Thu, 24 Oct 2002 13:11:16 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9OKBBRf017019 for ; Thu, 24 Oct 2002 13:11:11 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9OK8pE3002875 for ; Thu, 24 Oct 2002 13:08:52 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA13211; Thu, 24 Oct 2002 13:04:14 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA04841; Thu, 24 Oct 2002 13:04:13 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9OK49f20629; Thu, 24 Oct 2002 15:04:10 -0500 (CDT) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17147; Thu, 24 Oct 2002 15:05:19 -0500 (CDT) Message-ID: <3DB852E8.50D99513@Motorola.com> Date: Thu, 24 Oct 2002 15:07:04 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: daisyc@us.ibm.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... > The problem in my opinion, is that parts of the RFC are > written thinking in a "classical" host (single homed), while some > others do really take into account multihoming... This makes that > some paragraphs are confusing... This is the key to read the CC rules in RFC2960 correctly. And everything will start to make sense for you if you keep in mind that the rules are assuming "the same dest addr is being used for send and re-send" and a self-contained within a single dest addr. But I don't think this is a problem. I remember we talked about this and considered this is a good strategy to depict SCTP CC rules, because we wanted to have the rules be easily comparable with those of TCP's and be easily cross-examined later to ensure the fairness and friendliness between the two. The catch is that one must read and keep in mind the assumptions made at the beginning of the chapter. -Q From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sat Oct 26 19:33:16 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14774 for ; Sat, 26 Oct 2002 19:33:15 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9QNTlot000903 for ; Sat, 26 Oct 2002 16:29:47 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9QNTkeh013577 for ; Sat, 26 Oct 2002 16:29:46 -0700 (PDT) Received: from mail.com (host-66-133-60-178.verestar.net [66.133.60.178]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id g9QNTMDn010523 for ; Sat, 26 Oct 2002 16:29:32 -0700 (PDT) Message-Id: <200210262329.g9QNTMDn010523@proxy1.cisco.com> From: "LOUISA E. ESTRADA" To: Subject: SOLICITING FOR YOUR ASSISTANCE. Sender: "LOUISA E. ESTRADA" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 27 Oct 2002 00:29:38 +0100 Reply-To: "LOUISA E. ESTRADA" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit FROM: MRS. LOUISA EJERCITOR ESTRADA Email: estradal@rediffmail.com estradalo@rediffmail.com E-fax: +1 775-458-2140 Dear Sir, I got your contact address through a reliable friend in my search for a reliable and trustworthy person who will assist me in a business investment venture in your country. I am Mrs. LOUISA EJERCITOR ESTRADA, the wife of Mr. Joseph Estrada the former president of Philippine located in the south East Asia. My husband was presently impeached from office by a backed uprising of mass demonstrators and the senate. During my husband's regime as president of Philippine, I realized US$21.540 millions of dollars from various contract projects I executed successfully. I had planned to invest this money for my children's future on real estate and industrial production. My husband is not aware of this because I wish to do it secretly for now. Before my husband was impeached from office, I concretely and secretly deposited this money and declared it computer ledger cards with diplomatic Security Company that transports valuable goods/consignment through diplomatic courier service to their offshore offices. The consignments that are contained in the two trunks are declared owned by my foreign business partners. I wish to discuss how much I will offer you if you will be willing to assist me claim the money and invest it in your country. I want to assure you that all modalities are put in place and it is a risk free transaction. I trust you as a God fearing person who will not sit on my life saving fund. This business demands absolute secrecy and confidentiality, thus all communications for now should be through e-mail because all my phone lines are connected to the Philippine's Telecommunication network services. I will furnish you with more details when I receive your positive response. Expecting your urgent reply. Thanking you for your anticipated co-operation. Best regards, MRS. LOUISA EJERCITOR ESTRADA From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Oct 28 05:12:00 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02065 for ; Mon, 28 Oct 2002 05:11:59 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9S9vXPP003328 for ; Mon, 28 Oct 2002 01:57:33 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9S9vVGM029947 for ; Mon, 28 Oct 2002 01:57:33 -0800 (PST) Received: from mail1c.webmessenger.it (mail2.webmessenger.it [193.70.193.55]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9S9vTWm007995 for ; Mon, 28 Oct 2002 01:57:32 -0800 (PST) Received: from coritel.it (193.205.164.76) by mail1c.webmessenger.it (6.5.028) (authenticated as senny_and@email.it) id 3DAC0AEB004A0086; Mon, 28 Oct 2002 10:38:54 +0100 Message-ID: <3DBD05A8.2020206@coritel.it> Date: Mon, 28 Oct 2002 10:38:48 +0100 From: Andrea Senatore Organization: CoRiTeL Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: [SCTP]Congestion Control Parameters Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi to all, I have a confusion on Section 7.1 of RFC 2960...... SCTP is designed to establish robust communication associations between two endpointeach of which may be reachableby more than one transport address. Potentially different addresses may lead to different data *paths* between the two endpoints, thus ideally one may need a *separate* set of congestion control parameters for each of the *paths*. ...... The sender keeps a separate congestion control parameter set for each of the destination address it can send to (*not* for each source-destination *pair* but for each *destination*). I don't understand.... "one need a *separate* set of congestion control parameters for each of the *path*, and then keeps this set *only* for each destination address". CWND, RTO, RTT, etc., depend upon used path and *not* upon destination address. When host send packets through a different interface but at same destination address this parameters must change because the path change... Best rgds -- Andrea ======================================================== Andrea Senatore, Mail: senatore@coritel.it, Address: CoRiTeL c/o Università degli Studi di Salerno, Facoltà di Ingegneria, via Ponte Don Melillo, 84084 - FISCIANO (SA) - Italy Tel: +39 089 964012 Fax: +39 089 964010 ======================================================== From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Oct 28 06:43:48 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04094 for ; Mon, 28 Oct 2002 06:43:47 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SBdMPP003200 for ; Mon, 28 Oct 2002 03:39:22 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SBdFqf023619 for ; Mon, 28 Oct 2002 03:39:15 -0800 (PST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9SBbior026095 for ; Mon, 28 Oct 2002 03:37:45 -0800 (PST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA22133; Mon, 28 Oct 2002 12:22:26 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA25697; Mon, 28 Oct 2002 12:22:25 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id ; Mon, 28 Oct 2002 12:21:50 +0100 Message-ID: From: Tuexen Michael To: "'Andrea Senatore'" , tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: RE: [SCTP]Congestion Control Parameters Date: Mon, 28 Oct 2002 12:21:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04094 Hi Andrea, in SCTP terminology a path towards a peer is a transport address. An outgoing interface is NOT considered. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Andrea Senatore [mailto:senatore@coritel.it] > Sent: Monday, October 28, 2002 10:39 AM > To: tsvwg@ietf.org; sctp-impl@external.cisco.com > Subject: [SCTP]Congestion Control Parameters > > > Hi to all, > I have a confusion on Section 7.1 of RFC 2960...... > > > > > SCTP is designed to establish robust communication > associations between > two endpointeach of which may be reachableby more than one transport > address. Potentially different addresses may lead to different data > *paths* between the two endpoints, thus ideally one may need a > *separate* set of congestion control parameters for each of > the *paths*. > > ...... > > The sender keeps a separate congestion control parameter set > for each of > the destination address it can send to (*not* for each > source-destination *pair* but for each *destination*). > > > I don't understand.... "one need a *separate* set of > congestion control > parameters for each of the *path*, and then keeps this set *only* for > each destination address". > CWND, RTO, RTT, etc., depend upon used path and *not* upon > destination > address. > When host send packets through a different interface but at same > destination address this parameters must change because the > path change... > > Best rgds > > -- Andrea > ======================================================== > Andrea Senatore, > Mail: senatore@coritel.it, > Address: CoRiTeL c/o Università degli Studi di Salerno, > Facoltà di Ingegneria, via Ponte Don Melillo, > 84084 - FISCIANO (SA) - Italy > Tel: +39 089 964012 > Fax: +39 089 964010 > ======================================================== > > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Oct 28 07:58:32 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06712 for ; Mon, 28 Oct 2002 07:58:30 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9SCqTot020448; Mon, 28 Oct 2002 04:52:29 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAM41187; Mon, 28 Oct 2002 04:52:26 -0800 (PST) Message-ID: <3DBD330A.5060506@cisco.com> Date: Mon, 28 Oct 2002 06:52:26 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: Qiaobing.Xie@motorola.com, daisyc@us.ibm.com, tcdc@us.ibm.com, sctp-impl@external.cisco.com, tsvwg@ietf.org Subject: Re: [Tsvwg] RE: question regarding retransmission References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ivan: I have read all of this thread except Qiaobing's last post... and kept quite .. but not now. Qiaobing, I also was a large part of this text and I think it IS clear here what we were trying to do.. and we DO NOT send a full cwnd to the new address. Now I must admit we were NOT thinking of a triple homed endpoint.. but a plain 2 address peer... so adding this second time-out is a bit of a twist. What should happen? Well using Daisy's scenario: a1: c1 c3 c4 a2: a3: c2 Assuming all chunks fit in a single MTU When a1 expires I get a1: none a2: c1 a3: none c3/c4 marked for retransmission c2 still awaiting a SACK Now when a3 expires (assuming after a1) The implementation gets a choice... as Qiaobing illustrated. It can do a1: c2 a2: none a3: none c1 pending c3/c4 marked for retran OR a1:none a2: c2 a3: none c1 pending c3/c4 marked for retran ... why.. Well first you can pick any alternate that is up.. this gives us the choice. And at ANY single retransmission we can only send ONE MTU out.. someplace... So at the retransmission we go to send C2 (the only one to retransmit) out... now we still must obey the cwnd of any destination.. so if by chance a2 had its flight size equal to its cwnd size.. then we could not send c2 out a2.. but lets assume it was higher than that... then we WOULD send c2 out. Could we send c3 or c4 ahead of C2? I suppose one could.. but this does not help you advance your cum-ack.. which is the only way you can get cwnd growth.. Basically any time you get a timeout you: 1) mark those pending tsn's for retransmission 2) select an alternate destination... this was our choice a1/a2 3) Once the choice is made you pick the lowest TSN pending retransmisison against that address and send it... by chance our chunk sent to a3 was lower than any other on a2 when we went to retransmit. One could also invision where we had a1: c1 c2 c3 a2: none a3: c4 in this scenario with the same timeouts then you would at c4's timeout retransmit c2 again out a2... since IT is the lowest (assuming you did not pick a1.. which you are allowed to do). R Ivan.Arias-Rodriguez@nokia.com wrote: > Qiaobing, > > I don't want to change the CC state of any other address but the one whose T3 expired... However, the E3) subsection of 6.3.3 leaves completely clear, in my opinion, than only one packet should be sent regarding this retransmission... And it even says that you send the TSN that were in flight when T3 expired, without taking into account that there could be some older TSNs still marked for retransmission due to, for example, fast retransmit... > > I see your point that nothing will stop me later to send more data... Yes, supposing I have two addresses t1 and t2, if T3 for t1 expires, I resend one TSN to t2. If right after that, the user gives me more data to send to t2, of course I will do it as far as cwnd allows... > > However, the statement in that section is really confusing... Well, from my point of view it clearly states a different thing than Qiaobing's interpretation... It says, send "a single packet"... In the normal case with two addresses and using one as primary, if T3 expires on t1 while have a lot of TSN in flight, then what Qiaobing says is that we should send 2*MTU worth of data (assuming t2 is in idle state), i.e., two packets, instead of one... > > The problem in my opinion, is that parts of the RFC are written thinking in a "classical" host (single homed), while some others do really take into account multihoming... This makes that some paragraphs are confusing... > > Is the general opinion here that only cwnd should limit? (this really makes sense for me but it is not what the RFC says). > > Thanks for your comments Daisy and Qiaobing! > > BR Iván Arias Rodríguez > > > >>-----Original Message----- >>From: ext Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com] >>Sent: 24. October 2002 22:23 >>To: Daisy Chang >>Cc: Arias-Rodriguez Ivan (NRC/Helsinki); tcdc@us.ibm.com; >>sctp-impl@external.cisco.com; tsvwg@ietf.org >>Subject: Re: [Tsvwg] RE: question regarding retransmission >> >> >>Hi, Ivan and Daisy, >> >>I disagree with you here. I think the RFC is well written. What you >>might have not paid enough attention to is the text above the >>rules you >>are now focusing on. >> >>When reading the detailed CC rules in chapter 7, one MUST keep in mind >>the assumptions made in 7.1 (Lixia and Vern please correct me if my >>memory is faulty here, you two are the owner of the text in 7). >> >>In particular: >> >> "The sender usually uses the same destination address..." >>and >> "The sender keeps a separate congestion control parameter set >> for each of the destination addresses..." >> >>**The CC rules that follow are narrated under this "same dest addr" >>assumptions** >> >>And multi-homed peer is dealt with in the first bullet in 7.1: >> "...(keep using the same dest addr) until being instructed >> by the upper layer otherwise; however, SCTP may change >> to an alternate destination in the event an address is marked >> inactive (see Section 8.2). Also, SCTP may retransmit to a >> different transport address than the original transmission" >> >>This lays out the three cases where a diff dest addr may become >>involved. And the second assumption in 7.1 makes it perfectly >>clear that >>this second dest addr, when becoming involved, will bring its >>**own** CC >>param and (implied) status. >> >>Now, to answer Ivan's question, let me ask you a question, when your >>dest addr t3 timed out and its CC status changed accordingly, >>why do you >>want to modify t2 and t1's CC status as well? (remember, applying "no >>more than one packet in-flight" globally constitutes a change of CC >>status of every dest address) >> >>-Qiaobing >> >>Daisy Chang wrote: >> >> >>>Ivan, >>> I definitely would say that the RFC could be clearer >>> >>> >>on this. The >> >> >>>wording in >>>RFC2960 6.3.3 (E3) is very misleading: >>> >>>"E3) Determine how many of the earliest (i.e., lowest TSN) >>> >>> >>outstanding >> >> >>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> DATA chunks for the address for which the T3-rtx has >>> >>> >>expired will >> >> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> fit into a single packet, subject to the MTU >>> >>> >>constraint for the >> >> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> path corresponding to the destination transport >>> >>> >>address to which >> >> >>> the retransmission is being sent (this may be >>> >>> >>different from the >> >> >>> address for which the timer expires [see Section 6.4]). Call >>> this value K. Bundle and retransmit those K DATA chunks in a >>> >>> >>> >>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >>> single packet to the destination endpoint." >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> From Qiaobing's answers to my question, I drew these >>> >>> >>conclusions myself, >> >> >>>1. The definition of "the earliest (i.e., lowest TSN) >>> >>> >>outstanding DATA chunks for the address >> >> >>>for which T3-rtx has expired" is up to the implementation. >>> >>> >>With multiple transports, if the earliest >> >> >>>outstanding DATA chunks were marked for retransmission due >>> >>> >>to timer expirations for other >> >> >>>transports, they are certainly eligible to be taken into >>> >>> >>consideration. >> >> >>>2. The retransmission size is not limited to one packet (1 >>> >>> >>MTU). Implementations could >> >> >>>retransmit up to what the cwnd of the outgoing transport >>> >>> >>would allow. >> >> >>> If I didn't interpret Qiaobing's answers wrongly, I >>> >>> >>believe that this probably merits an >> >> >>>amendment to implementator's guide to prevent people from >>> >>> >>having the same confusions >> >> >>>that I have. >>> >>>Thanks, >>>Daisy Chang >>>IBM Linux Technology Center >>>daisyc@us.ibm.com >>>Tel: (512)-838-4194 T/L: 678-4194 >>>FAX: (512)-838-4663 >>> >>>Ivan.Arias-Rodriguez@nokia.com@ietf.org on 10/24/2002 07:11:21 AM >>> >>>Sent by: tsvwg-admin@ietf.org >>> >>>To: >>>cc: tcdc@us.ltcfwd.linux.ibm.com, , >>> >>>Subject: [Tsvwg] RE: question regarding retransmission >>> >>> Aha... alright, now I'm completely lost... :-) >>> >>> I have always thought exactly this "why >>> >>> >>putting a limitation >> >> >>>in the number of packets after a retransmission, other than >>> >>> >>the cwnd of the >> >> >>>new destination address (and rwnd)?"... I simply didn't >>> >>> >>understand why... >> >> >>>And I have always gotten the answer "we are dealing with >>> >>> >>multihomed peers, >> >> >>>something new in the internet, and we have to be >>> >>> >>conservative. Besides, >> >> >>>depending on your configuration, it is likely that even if >>> >>> >>the destination >> >> >>>address is different, most of the network path is shared"... :-0 >>> >>> And now, what? >>> >>> If the idea is as Qiaobing says, then >>> >>> >>definitely the RFC is >> >> >>>wrong. Because it clearly states that you send "one and >>> >>> >>only one" no matter >> >> >>>where to... And this is what I have always done (internally >>> >>> >>thinking at the >> >> >>>same time that it wasn't the best option, but...), because >>> >>> >>it has been what >> >> >>>people have told me to do... :-/ And actually it was much >>> >>> >>easier coding it >> >> >>>the other way (Qiaobing's)... >>> >>> Any more comments from some more people? >>> >>> I think this is not really something internal to the >>>implementation but really an SCTP issue... I will send it >>> >>> >>also to the TSVWG >> >> >>>(however, lacking the previous mails I don't know if they >>> >>> >>are going to >> >> >>>understand much)... >>> >>> Thanks! >>> >>> BR Iván Arias Rodríguez >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] >>>>Sent: 23. October 2002 21:38 >>>>To: Arias-Rodriguez Ivan (NRC/Helsinki) >>>>Cc: tcdc@us.ibm.com; sctp-impl@external.cisco.com >>>>Subject: Re: question regarding retransmission >>>> >>>> >>>>Ivan, >>>> >>>>In general I think you are interpretation the spec more >>>> >>>> >>restrictively >> >> >>>>than it intends to be... which is of cause good for the >>>>network :-) See >>>>my comments below... >>>> >>>>... >>>> >>>> >>>>>> Transmitted: >>>>>> t1: (#1, #2, #3) >>>>>> t2: (#1), #2 >>>>>> t3: (#4) >>>>>> marked for retransmission: #3. #4 >>>>>> >>>>>> >>>>First, you can not re-send #2 to t2, because there is no cwnd >>>>left on t2 >>>>after you re-sent #1 over it, right? >>>> >>>>In fact at the point, your cwnd status should be: t1/1 >>>> >>>> >>MTU; t2/none; >> >> >>>>t3/1 MTU... You can choose to be conservative and not to use the >>>>remaining 2 MTU quota the network allows you.. This of >>>> >>>> >>cause is fine. >> >> >>>>> Again, I'm assuming that 1 TSN = 1 MTU... No matter >>>>> >>>>> >>>>which is the cwnd of the destination address, when >>>>retransmitting you send at most (and you are allowed to send >>>>at least) 1 MTU... Otherwise, you could bundle as many as you >>>>could in a single MTU of the destination address chosen for >>>>the retransmission... >>>> >>>> >>>>This interpretation is very conservative, IMO. >>>> >>>> >>>> >>>>>>or >>>>>> Transmitted: >>>>>> t1: (#1, #2, #3) >>>>>> t2: (#1), #4 >>>>>> t3: (#4) >>>>>> marked for retransmission: #2, #3 >>>>>>or >>>>>> >>>>>> >>>>> I don't think that this is what you should do for >>>>> >>>>> >>>>the reasons I said above... Please note that this is just my >>>>suggestion (I cannot assure that I'm right :-)). >>>> >>>> >>>>> (oops! I took a look to the RFC, and it seems that >>>>> >>>>> >>>>section 6.3.3 E3) says that you should precisely do this... >>>>Now I'm as confused as you, Daisy) >>>> >>>> >>>>Obviously the wording there is not meant to address a >>>> >>>> >>double t-o event >> >> >>>>like what we are talking about here :-) I probably will go for >>>>re-sending #2 first (i.e. the *overall oldest* TSN marked for >>>>re-trans). >>>>That makes better sense to me. >>>> >>>>-Qiaobing >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Oct 28 14:06:13 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25023 for ; Mon, 28 Oct 2002 14:06:12 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9SIxbxF011914 for ; Mon, 28 Oct 2002 10:59:37 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SIxYmR023147 for ; Mon, 28 Oct 2002 10:59:34 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9SIw1Sf020791 for ; Mon, 28 Oct 2002 10:58:01 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA12799; Mon, 28 Oct 2002 11:54:33 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA03635; Mon, 28 Oct 2002 11:54:32 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id g9SIsTf16961; Mon, 28 Oct 2002 12:54:30 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA00869; Mon, 28 Oct 2002 12:55:40 -0600 (CST) Message-ID: <3DBD87F2.9EFD2B04@Motorola.com> Date: Mon, 28 Oct 2002 12:54:42 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Senatore CC: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [SCTP]Congestion Control Parameters References: <3DBD05A8.2020206@coritel.it> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Andrea, Andrea Senatore wrote: > > Hi to all, > I have a confusion on Section 7.1 of RFC 2960...... > > > SCTP is designed to establish robust communication associations between > two endpointeach of which may be reachableby more than one transport > address. Potentially different addresses may lead to different data > *paths* between the two endpoints, thus ideally one may need a ^^^^^^^^^^^^^^^ Consider this a note for the future research on SCTP. Ideally, it makes a lot of sense in theory that CC be performed on a per-path basis, but no one knows how to achieve this without adding crippling complexity to the protocol. So, the current SCTP per-dest-addr based CC is a design compromise or simplification. -Qiaobing > *separate* set of congestion control parameters for each of the *paths*. > > ...... > > The sender keeps a separate congestion control parameter set for each of > the destination address it can send to (*not* for each > source-destination *pair* but for each *destination*). > > > I don't understand.... "one need a *separate* set of congestion control > parameters for each of the *path*, and then keeps this set *only* for > each destination address". > CWND, RTO, RTT, etc., depend upon used path and *not* upon destination > address. > When host send packets through a different interface but at same > destination address this parameters must change because the path change... > > Best rgds > > -- Andrea > ======================================================== > Andrea Senatore, > Mail: senatore@coritel.it, > Address: CoRiTeL c/o Università degli Studi di Salerno, > Facoltà di Ingegneria, via Ponte Don Melillo, > 84084 - FISCIANO (SA) - Italy > Tel: +39 089 964012 > Fax: +39 089 964010 > ======================================================== From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Oct 28 14:26:31 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25730 for ; Mon, 28 Oct 2002 14:26:30 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJO5xF002917 for ; Mon, 28 Oct 2002 11:24:05 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJO37Z015955 for ; Mon, 28 Oct 2002 11:24:03 -0800 (PST) Received: from mail1c.webmessenger.it (mail2.webmessenger.it [193.70.193.55]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9SJO23U016589 for ; Mon, 28 Oct 2002 11:24:03 -0800 (PST) Received: from coritel.it (193.205.164.76) by mail1c.webmessenger.it (6.5.028) (authenticated as senny_and@email.it) id 3DAC0AEB004D0900; Mon, 28 Oct 2002 20:05:28 +0100 Message-ID: <3DBD8A71.5040902@coritel.it> Date: Mon, 28 Oct 2002 20:05:21 +0100 From: Andrea Senatore Organization: CoRiTeL Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuexen Michael , tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [SCTP]Congestion Control Parameters References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Tuexen Michael wrote: >Hi Andrea, > Hi Michael, > > >this would mean that you have m * n path if one peer has >n the other m IP addresses. Using the current terminology >has only n + m. This was considered less complexity. > You could use fixed paths associating every node of interface to one destination. So you has only min(n,m) paths... > > >The other reason is that normally the IP layer selects the >source address of the packet according to its forwarding table. >Selecting the source address at the SCTP layer (called source >selection) is not very easy and even if you select an IP-address >as a source address the IP layer may send it out on an interface >which has not bound that address. In the bakeoff some implementations >showed up with using source address selection and it came out >that it is a difficult task to get that stuff right. > Sorry I did not know these issues...but I think that a good congestion control mechanism should keep congestion parameters for each used path. > > >In general, the forwarding in an IP network is mostly based on >the destination address, not on the source address. > >These are some of the reasons why this notion was choosen. > ....... :-/ > > >I know of some people working on the path notion which is defined >as a pair of source and destination addresses and it is not a trivial >part. > >Best regards >Michael > >Michael Tuexen Tel.: +49 89 722 47210 >Siemens AG Fax: +49 89 722 48212 >ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com > >>-----Original Message----- >>From: Andrea Senatore [mailto:senatore@coritel.it] >>Sent: Monday, October 28, 2002 5:05 PM >>To: Tuexen Michael >>Subject: Re: [SCTP]Congestion Control Parameters >> >> >>Tuexen Michael wrote: >> >>>Hi Andrea, >>> >>>it is a definition, so it is not correct or incorrect. That >>>is the term used. >>> >>>What 'behaviour' of SCTP are you thinking to be not correct? >>> >>IMHO "congestion control parameters" would be kept for each >>source-destination pair (i.e. sender interface <----------> receiver >>interface) and not for >>each destination as written in RFC. >>These parameters depends on destination only when the sender has a >>single interface. >>Best Regards, >> >>-- Andrea >>======================================================== >>Andrea Senatore, >>Mail: senatore@coritel.it, >>Address: CoRiTeL c/o Università degli Studi di Salerno, >> Facoltà di Ingegneria, via Ponte Don Melillo, >> 84084 - FISCIANO (SA) - Italy >>Tel: +39 089 964012 >>Fax: +39 089 964010 >>======================================================== >> >> >> > > Thanks Michael, best regards , -- Andrea ======================================================== Andrea Senatore, Mail: senatore@coritel.it, Address: CoRiTeL c/o Università degli Studi di Salerno, Facoltà di Ingegneria, via Ponte Don Melillo, 84084 - FISCIANO (SA) - Italy Tel: +39 089 964012 Fax: +39 089 964010 ======================================================== From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 29 02:01:22 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15208 for ; Tue, 29 Oct 2002 02:01:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9T6eTxF027394 for ; Mon, 28 Oct 2002 22:40:34 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T6eSrm012478 for ; Mon, 28 Oct 2002 22:40:33 -0800 (PST) Received: from gw.openss7.com (IDENT:JAaE/7A5Y7mD6g3KdKFxZ1Mkb9dlXIp4@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9T6cov8006784 for ; Mon, 28 Oct 2002 22:38:51 -0800 (PST) Received: from ns.pigworks.openss7.net (ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id g9T6ZON08816; Mon, 28 Oct 2002 23:35:24 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id g9T6ZNo31074; Mon, 28 Oct 2002 23:35:23 -0700 Date: Mon, 28 Oct 2002 23:35:23 -0700 From: "Brian F. G. Bidulock" To: Andrea Senatore Cc: Tuexen Michael , tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] Re: [SCTP]Congestion Control Parameters Message-ID: <20021028233523.A31021@openss7.org> Reply-To: bidulock@openss7.org References: <3DBD8A71.5040902@coritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DBD8A71.5040902@coritel.it>; from senatore@coritel.it on Mon, Oct 28, 2002 at 08:05:21PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Andrea, What definition do you use for "path"? And, how do you ensure that such a definition of "path" has meaning in the underlying network? This was one of the difficulties in the original SCTP work. Do you use destination IP address? Do you use source-destination pairs? Do you use interfaces? Interface pairing? In general there is not a definition of path which suits all networks and all circumstances. The approximation to treat all paths as a single path with variable characteristics is a usable compromise. --brian On Mon, 28 Oct 2002, Andrea Senatore wrote: > > Sorry I did not know these issues...but I think that a good congestion > control mechanism should keep congestion parameters for each used path. > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Oct 29 03:01:22 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24419 for ; Tue, 29 Oct 2002 03:01:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9T7hVgM010576 for ; Mon, 28 Oct 2002 23:43:31 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T7hYqG015944 for ; Mon, 28 Oct 2002 23:43:34 -0800 (PST) Received: from sm205.163.com ([202.108.44.205]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9T7hSQW026619 for ; Mon, 28 Oct 2002 23:43:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sm205.163.com (Postfix) with SMTP id 1BA801C640753 for ; Tue, 29 Oct 2002 15:27:30 +0800 (CST) Received: from WHT (unknown [202.112.101.179]) by 192.168.1.205 (Coremail) with SMTP id pzEAAFk4vj0vBGWz.3 for ; Tue, 29 Oct 2002 15:27:30 +0800 (CST) Date: Tue, 29 Oct 2002 15:30:28 +0800 From: ÍõºêÌÎ To: SCTP mailist Subject: reliable messages in PRSCTP X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20021029072730.1BA801C640753@sm205.163.com> Content-Transfer-Encoding: 7bit I am working on the prsctp module for ns-2. I have a question. when the receiver prcessing a FORWARD TSN, "receiver must use the stream sequence information to examine all of the listed stream reordering queues, and immediately make available for delivery stream sequence number earlier or equal to the stream sequence number listed in the FORWARD TSN." as mentioned in prsctp draft. I want to know that if receiver should delivery the reliable messages whose SSN are earlier ot equal to the stream sequence number listed in the FORWARD TSN. -------------------------------------------------- Hongtao WANG National Key Lab. Beijing University of Posts and Telecommunications Beijing ,100876,P.R.China Tel:(8610)-62283757 Email:wang.ht2002@163.com -------------------------------------------------- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 29 03:16:44 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24620 for ; Tue, 29 Oct 2002 03:16:43 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T870PP029104 for ; Tue, 29 Oct 2002 00:07:00 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T870Wg026343 for ; Tue, 29 Oct 2002 00:07:00 -0800 (PST) Received: from sm205.163.com ([202.108.44.205]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9T86pQW005140 for ; Tue, 29 Oct 2002 00:06:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sm205.163.com (Postfix) with SMTP id 193701C664248 for ; Tue, 29 Oct 2002 15:50:51 +0800 (CST) Received: from WHT (unknown [202.112.101.179]) by 192.168.1.205 (Coremail) with SMTP id vTEAANc9vj25BWWz.3 for ; Tue, 29 Oct 2002 15:50:51 +0800 (CST) Date: Tue, 29 Oct 2002 15:53:50 +0800 From: ÍõºêÌÎ To: SCTP mailist X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20021029075051.193701C664248@sm205.163.com> Content-Transfer-Encoding: 7bit hello all! I have a confusion on the section 3.6 of prsctp draft. as following.... "during processing of a FORWARD TSN, the receiver MUST use the stream sequence information to examine all of the listed stream reordering queues, and immediately make available for delivery stream sequence numbers earlier than or equal to the stream sequence number listed inside the FORWARD TSN. After receiving and processing a FORWARD TSN, ... The receiver MUST remove any partially reassembled message which is still missing one or more TSNs earlier than or equal to the new cumulative TSN point." Should the receiver delivery the full reliable messages which are not expired and t their SSN are earlier than or equal to the stream sequence number listed inside the FORWARD TSN, but they are still missing some chunks (their TSN is earlier than or equal to the new cumulative TSN point). If the receiver do so, the lifetime of full reliable messages are not usful.in fact the reliable messages are not reliable because they are delivered partially before the their lifetime expire. -------------------------------------------------- Hongtao WANG National Switching Technology and Communication Network Lab. Beijing University of Posts and Telecommunications Beijing ,100876,P.R.China Tel:(+8610)-62283757 Email:wang.ht2002@163.com -------------------------------------------------- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 29 04:42:16 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26140 for ; Tue, 29 Oct 2002 04:42:15 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T9eoPP001060 for ; Tue, 29 Oct 2002 01:40:50 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9T9enTE011034 for ; Tue, 29 Oct 2002 01:40:49 -0800 (PST) Received: from mail1c.webmessenger.it (mail2.webmessenger.it [193.70.193.55]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9T9ei3U014167 for ; Tue, 29 Oct 2002 01:40:45 -0800 (PST) Received: from coritel.it (193.205.164.76) by mail1c.webmessenger.it (6.5.028) (authenticated as senny_and@email.it) id 3DAC0AEB0050268F; Tue, 29 Oct 2002 10:22:03 +0100 Message-ID: <3DBE5336.8070104@coritel.it> Date: Tue, 29 Oct 2002 10:21:58 +0100 From: Andrea Senatore Organization: CoRiTeL Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org, tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] Re: [SCTP]Congestion Control Parameters References: <3DBD8A71.5040902@coritel.it> <20021028233523.A31021@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Brian F. G. Bidulock wrote: >Andrea, > Hi Brian, > > >What definition do you use for "path"? And, how do you ensure >that such a definition of "path" has meaning in the underlying >network? > >This was one of the difficulties in the original SCTP work. Do >you use destination IP address? Do you use source-destination >pairs? Do you use interfaces? Interface pairing? > An endpoint cannot control completely the path used to send packets (i.e. all routers), but can choose the source and destination IP address. I believe that source-destination IP pairs identifies the path better than only destination IP address. Why need I use different congestion control parameters for different IP destination in SCTP ? Because if I change the IP destination address, probably the path changes, and then all congestion control parameters MUST change. But the path changes also if I change IP source address (if is it possible..) and, for the same reasons, all congestion control parameters MUST change. This is the reason for which I say that a good congestion control mechanism should keep congestion parameters for each used path.. > > >In general there is not a definition of path which suits all >networks and all circumstances. The approximation to treat all >paths as a single path with variable characteristics is a usable >compromise. > >--brian > >On Mon, 28 Oct 2002, Andrea Senatore wrote: > >>Sorry I did not know these issues...but I think that a good congestion >>control mechanism should keep congestion parameters for each used path. >> > Best Regards, -- Andrea ======================================================== Andrea Senatore, Mail: senatore@coritel.it, Address: CoRiTeL c/o Università degli Studi di Salerno, Facoltà di Ingegneria, via Ponte Don Melillo, 84084 - FISCIANO (SA) - Italy Tel: +39 089 964012 Fax: +39 089 964010 ======================================================== From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 29 05:57:28 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27291 for ; Tue, 29 Oct 2002 05:57:27 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TAtePP024386 for ; Tue, 29 Oct 2002 02:55:41 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9TAtYVS027293 for ; Tue, 29 Oct 2002 02:55:34 -0800 (PST) Received: from gw.openss7.com (IDENT:6taYyLNTRwP+teD373jFH1phmFp0zuBR@gw.openss7.com [142.179.199.224]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9TAs2v8015738 for ; Tue, 29 Oct 2002 02:54:03 -0800 (PST) Received: from ns.pigworks.openss7.net (ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id g9TApHN12917; Tue, 29 Oct 2002 03:51:17 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id g9TApHT04028; Tue, 29 Oct 2002 03:51:17 -0700 Date: Tue, 29 Oct 2002 03:51:16 -0700 From: "Brian F. G. Bidulock" To: Andrea Senatore Cc: tsvwg@ietf.org, sctp-impl@external.cisco.com Subject: Re: [Tsvwg] Re: [SCTP]Congestion Control Parameters Message-ID: <20021029035116.A3449@openss7.org> Reply-To: bidulock@openss7.org References: <3DBD8A71.5040902@coritel.it> <20021028233523.A31021@openss7.org> <3DBE5336.8070104@coritel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DBE5336.8070104@coritel.it>; from senatore@coritel.it on Tue, Oct 29, 2002 at 10:21:58AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: 8bit Andrea, On Tue, 29 Oct 2002, Andrea Senatore wrote: > > I believe that source-destination IP pairs identifies the path better > than only destination IP address. How so? Source address typically has no bearing on the path taken by a packet through an IP network (nor on which interface the outgoing packet is sent). > Why need I use different congestion control parameters for different IP > destination in SCTP ? Because the only valuable use of SCTP multi-homing is to have each destination IP address correspond to a different interface on the destination host, which is, indeed, a different path for each destination address. > Because if I change the IP destination address, probably the path > changes, and then all congestion control parameters MUST change. The useful application of SCTP multi-homing means that the path does change when the destination address changes and thus, per RFC 2960, the congestion control parameters MUST change. > But the path changes also if I change IP source address (if is it > possible..) and, for the same reasons, all congestion control > parameters MUST change. No. Path does not change when IP source address changes. The IP source address is merely a return address. In a typical IP stack or router, changing the source address has no bearing on the path taken by the packet. Only destination address does. Source address has a bearing on the return path for packets, but CC on the return path is the business of the peer. > This is the reason for which I say that a good congestion control > mechanism should keep congestion parameters for each used path.. The host will chose the outgoing interface based on the destination address and will not consider the source address when selecting the outgoing interface. Some IP implementations permit routing based on source address, but this is atypical. Regardless, it is outgoing interface and destination address that determines path, not source address. In the absence of failures and network reconfigurations, it is true that destination address alone determines path. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 29 06:55:24 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29661 for ; Tue, 29 Oct 2002 06:55:23 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9TBsJxF006343 for ; Tue, 29 Oct 2002 03:54:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TBsNQZ011730 for ; Tue, 29 Oct 2002 03:54:23 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9TBqiv8010089 for ; Tue, 29 Oct 2002 03:52:45 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TBggb25524 for ; Tue, 29 Oct 2002 13:42:42 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 13:43:02 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 13:43:02 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 13:43:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 13:43:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Re: [SCTP]Congestion Control Parameters Date: Tue, 29 Oct 2002 13:43:01 +0200 Message-ID: Thread-Topic: [Tsvwg] Re: [SCTP]Congestion Control Parameters Thread-Index: AcJ/MC59KF+WK7+NRYe1JrcsaSwB+gADyNVQ From: To: , , , X-OriginalArrivalTime: 29 Oct 2002 11:43:01.0778 (UTC) FILETIME=[5607C720:01C27F40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA29661 snip... > An endpoint cannot control completely the path used to send packets > (i.e. all routers), but can choose the source and destination > IP address. > I believe that source-destination IP pairs identifies the path better > than only destination IP address. > Why need I use different congestion control parameters for > different IP > destination in SCTP ? > Because if I change the IP destination address, probably the path > changes, and then all congestion control parameters MUST change. > But the path changes also if I change IP source address (if is it > possible..) and, for the same reasons, all congestion control > parameters MUST change. This is precisely the problem... If you change your source address, logically the packets are sent from that address... However, in most of the cases, physically nothing changes: packets go out from the same network card with an "artificial" change in the source address... :-/ So, in most of the cases, changing the source address simply involves changes in the return path (the acks are sent back to the other address rather than the "real" source address). Besides, this situation in which you set your source address to an "artificial" ones is not really a nice thing... Imagine that you are in this situation, having two source addresses. In this case no matter which one of your network adapters stop working, the association will fail as soon as one of them crashes (you loss either the DATA or the SACKs, i.e., you never receive the SACKs for your DATA chunks). In this case the "reliability" added by the use of two adapters really becomes "unreliability" (you have about twice the possibilities of losing the connection). BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Oct 29 06:56:58 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29759 for ; Tue, 29 Oct 2002 06:56:57 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9TBp7gM022169 for ; Tue, 29 Oct 2002 03:51:07 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9TBp4aY022640 for ; Tue, 29 Oct 2002 03:51:04 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9TBnVv8009017 for ; Tue, 29 Oct 2002 03:49:32 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TBZib20425 for ; Tue, 29 Oct 2002 13:35:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Oct 2002 13:36:06 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 13:36:06 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 13:36:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Subject: RE: reliable messages in PRSCTP Date: Tue, 29 Oct 2002 13:36:04 +0200 Message-ID: Thread-Index: AcJ/JDzHZHJlkIw8TNWuRAeqldqZPwAGkjHA From: To: , X-OriginalArrivalTime: 29 Oct 2002 11:36:04.0945 (UTC) FILETIME=[5D941C10:01C27F3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA29759 > hello all! Hi Wang! > I have a confusion on the section 3.6 of prsctp draft. as > following.... > > "during processing of a FORWARD TSN, the receiver MUST > use the stream sequence information to examine all of the listed > stream reordering queues, and immediately make available > for delivery > stream sequence numbers earlier than or equal to the > stream sequence > number listed inside the FORWARD TSN. > > After receiving and processing a FORWARD TSN, ... The receiver MUST > remove any partially reassembled message which is still missing one > or more TSNs earlier than or equal to the new cumulative > TSN point." > > Should the receiver delivery the full reliable messages > which are not expired and t their SSN are earlier than or > equal to the stream sequence number listed inside the FORWARD > TSN, but they are still missing some chunks (their TSN is > earlier than or equal to the new cumulative TSN point). Nope... Just take into account that the receiver doesn't know which SSNs are reliable are which are not... If an SSN is reliable, simply the data sender will never send you a FORWARD TSN chunk with a TSN newer than the oldest TSN of a reliable SSN pending receipt... If you receive a FORWARD TSN with let's say TSN 100, and TSN 95 was still missing, it means that TSN 95 was part of an unreliable SSN... So don't worry, you won't ever be in this situation :-) > If the receiver do so, the lifetime of full reliable > messages are not usful.in fact the reliable messages are not > reliable because they are delivered partially before the > their lifetime expire. See above... (note also that the lifetime of a reliable message is "forever"). BR Iv¨¢n Arias Rodr¨ªguez From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 29 08:24:33 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02701 for ; Tue, 29 Oct 2002 08:24:31 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9TDIXot027811 for ; Tue, 29 Oct 2002 05:18:33 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TDIWFT020759 for ; Tue, 29 Oct 2002 05:18:32 -0800 (PST) Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9TDIPuT000599 for ; Tue, 29 Oct 2002 05:18:26 -0800 (PST) Received: from duck ([67.201.25.123]) by out007.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021029125935.BKLA10046.out007.verizon.net@duck> for ; Tue, 29 Oct 2002 06:59:35 -0600 Message-ID: <62814-220021022913222320@duck> X-Priority: 3 Reply-To: res02mg1@gte.net X-MSMail-Priority: Normal Errors-to: res02mg1@gte.net Organization: Market*Access From: "David Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Three Conferences: Mobile&Wireless, Cyber, Info Sharing, Arl. Va, Nov-Dec 02 Date: Tue, 29 Oct 2002 08:02:22 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA02701 To: SCTP-IMPL@EXTERNAL.CISCO.COM TRAINING CONFERENCE - MOBILE AND WIRELESS SOLUTIONS Homeland Defense Training Conference Event Produced by Market*Access International, Inc. WHEN: November 13, 2002 ***** NEW SPEAKERS ADDED ***** WHERE: Executive Conference Center NRECA Building 4301 Wilson Boulevard Arlington, Virginia 22203 Time: 7:00 AM Registration Program Starts: 8:30 AM Wrap-up: 4:45 PM Continental Breakfast, Refreshments, Lunch included. HOTLINE AVAILABLE - Call 703-807-2027 to learn how you can register on-line and view the most current agenda. *** To obtain information on any conference, register and pay on line, call our hot line at 703-807-2027 for instructions. *** *** Special Note: We have three conferences planned in November and December 2002. These include: * Mobile and Wireless Solutions, Nov 13, 2002, Arlington, Va. * Protecting America's Infrastructure - Cyber Defense, Nov 19, 2002, Arlington, Va. * Information Sharing Strategies, Dec 4, 2002, Arlington, Va. **** Additional Conferences of Note **** * Homeland Defense: Regional, State and Local Strategies, Jan 14-16, 2002, Colorado Springs, Co. * Global E-Government with USTDA and Department of State, November 20-22, Wash. D.C. SPEAKERS -- Mobile and Wireless Solutions Training Conference * US Senator Conrad Burns (R-MT), advocate of emergency responder communications and member of the Senate Appropriations Committee * Communication Directorate, Advanced Technology Office, ARMY CECOM (Invited) * Chris Lewis, Office of the CIO, Department of the Interior * Michael D. Duffy, Director, Telecommunications Services Staff and Wireless Management Office (Executive Director for the Justice/Treasury Integrated Wireless Network (IWN) Program), US Department of Justice (Invited) * GSA Federal Technology Service (FTS) * Wayne Jansen, Principal Scientist, Computer Security Division, NIST * Chris Rangel, Assistant Vice President, Alvarion, Inc. * Andrew Krieg, President, Wireless Communications Association International (WCAI) * Gregory D. Meacham, Vice President, Nextel Communications * Carolyn Jondahl, RIM/BlackBerry ....other speakers to be announced. SPEAKERS WILL REPRESENT: Government agency applications of mobile and wireless technologies Communication managers and program analysts Technology development leaders representing academic efforts and private sector research and development programs and devices dedicated to mobile and wireless solutions. These speakers will provide attendees with up to date reports on current local and national programs, new technological advances, demonstration project updates, common challenges and the outlook for the future. ABOUT MOBILE AND WIRELESS SOLUTIONS From townships to federal agencies, mobile-wireless technology is making inroads into traditional government business, public safety and operational solutions. Government IT Executives are quickly recognizing the exciting opportunity to extend their reach beyond the web to devices like cell phones, handheld computers, interactive pagers, Palm Pilots, and other PDAs. The commercial growth potential for this market is just about to explode. IDC Research projects that 61.5 million people will be using wireless devices to access the Internet in 2003. This is a 728% increase from the 7.4 million users today. Government business applications of wireless will track this explosive growth. Products and solutions that address wireless security, business continuity, reliability and disaster recovery will experience high growth due to the recent terrorist attacks and the need to improve communications and security. CONFERNECE GOAL Market*Access will host a training conference for industry and government focusing on agency needs and requirements in Mobile and Wireless Solutions in the area of Homeland Defense. This will be a public-level series of training presentations on the challenges ahead. Speakers will represent federal agencies and leading security, equipment and systems suppliers. The goal of this meeting is to begin to prepare U.S. government and industry for the changes that will come about regarding mobile and wireless solutions for Homeland Defense. EXHIBITORS WILL INCLUDE * Wireless and mobile solution providers * Mobile and wireless communications * Security planners * Federal systems integrators * Network and Systems Security Training and Consulting * Disaster recovery and facility security WHO SHOULD ATTEND * Agency IT Executives * Agency mobile and wireless program managers * Tele-work and Telecomm Directors & Managers * Functional area managers using mobile computing * Wireless and mobile solutions providers * Federal systems integrators and solutions providers * Federal, State and Local CIOs and IT teams WHAT YOU WILL LEARN * Understanding new programs, issues and requirements * Strategies for mobile and wireless applications * New products in development and on the drawing boards in terms of Mobile and Wireless Solutions * New initiatives being planned at the federal, state and local levels. * Civil agency organization and planning * R&D Initiatives POINTS OF CONTACT: For information on SPONSORSHIP arrangements, please contact Mr. George Groesbeck, 406-723-3488 For REGISTRATION or general information about this event, please contact Mr. David Dickson, 703/807-2742. **** THERE IS LIMITED SEATING SO PLEASE REGISTER EARLY **** REGISTRATION FEE * Industry - Credit Card or Check in Advance $595 * Government - Credit Card or Check in Advance $395 * Fax: registration form to 703-807-2728. * Mail: registration form to: Market*Access International, Inc. Attn: David Dickson 4301 Wilson Blvd. #1003 Arlington, VA 22203 ----------------------------------------------------------------------------------------- **** REGISTRATION FORM **** Mobile and Wireless Solutions - November 13, 2002 Attendee Name: Title: Company/Agency: Address: City: State: Zip Code: Email: Telephone: Fax: Registration Fee: * Industry - Credit Card or Check in Advance $595 * Government - Credit Card or Check in Advance $395 Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Blvd. #1003, Arlington, VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order I am interested in continuing to receive updates and information by email regarding future conferences in this area. Select one: _____Yes _____No Registration: Call David Dickson (703) 807-2742 Fax this form to 703-807-2728. Thank you. To register and pay on line, call our hot line at 703-807-2027 for instructions. *** SPECIAL NOTE *** This message is being sent to you as a service to inform you and your organization of a training conference directed at federal and industry managers. If this business communication was sent to you in error or is not of interest, please let us know by REPLY'ing to this message and place REMOVE in the SUBJECT line. We will remove your name immediately. If however, you wish to receive additional information about this Conference, how you can register on-line and other related training opportunities, please place SUBSCRIBE TRAINING in the SUBJECT line and REPLY to this message. We will include you in future notices concerning this topic. *** SPECIAL NOTE *** HOMELAND DEFENSE JOURNAL FREE SUBSCRIPTION IS AVAILABLE NOW **** The Homeland Defense Journal is published twice a month and distributed as a PDF file by email. If you would like a free subscription, please REPLY to this message and place SUBSCRIBE HOMELAND in the SUBJECT line and you will receive our next issue -- Issue #19 - This paper has a distribution of over 45,000 subscribers at federal, state and local levels. Our last issue was downloaded over 126,000 times. To get information on how you can download past issues free, call our Homeland Defense Journal HOTLINE at 703-807-2758. If you wish to be removed from this list, place REMOVE in the subject line and REPLY back to res02mg1@gte.net. From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Oct 29 10:47:00 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09630 for ; Tue, 29 Oct 2002 10:46:59 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9TFVpxF029447 for ; Tue, 29 Oct 2002 07:31:51 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9TFVtIo011799 for ; Tue, 29 Oct 2002 07:31:55 -0800 (PST) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9TFVsgX026107 for ; Tue, 29 Oct 2002 07:31:55 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g9TFQad20359 for sctp-impl@external.cisco.com; Tue, 29 Oct 2002 10:26:36 -0500 Date: Tue, 29 Oct 2002 10:26:36 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: OPNET module for SCTP? Message-ID: <20021029102636.A20338@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hi, From the http://www.sctp.org web page, I know there is an ns-2 module for SCTP developed at University of Delaware. Does an OPNET ( http://www.sctp.org ) module for SCTP exist? -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Oct 29 15:07:28 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22529 for ; Tue, 29 Oct 2002 15:07:27 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9TK5eot026158 for ; Tue, 29 Oct 2002 12:05:40 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TK5dQE002524 for ; Tue, 29 Oct 2002 12:05:39 -0800 (PST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g9TK41ur016402 for ; Tue, 29 Oct 2002 12:04:01 -0800 (PST) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa13663; 29 Oct 2002 14:57 EST Date: Tue, 29 Oct 2002 14:57:19 -0500 (EST) From: "Armando L. Caro Jr." Reply-To: "Armando L. Caro Jr." To: Craig Rodrigues cc: sctp-impl@external.cisco.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: OPNET module for SCTP? In-Reply-To: <20021029102636.A20338@bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 29 Oct 2002, Craig Rodrigues wrote: > From the http://www.sctp.org web page, I know there > is an ns-2 module for SCTP developed at University of Delaware. > > Does an OPNET ( http://www.sctp.org ) module for SCTP exist? Yes, but I don't know much about it other than it was developed by R. Brennan and T. Curran of Dublin City University. ~armando 0-- --0 | Armando L. Caro Jr. | acaro@cis.udel.edu | | University of Delaware | www.cis.udel.edu/~acaro | 0-- --0 From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Oct 29 21:16:31 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04780 for ; Tue, 29 Oct 2002 21:16:31 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9U2AiPP021501 for ; Tue, 29 Oct 2002 18:10:44 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9U2AbCR011804 for ; Tue, 29 Oct 2002 18:10:38 -0800 (PST) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9U2AbuT002889 for ; Tue, 29 Oct 2002 18:10:38 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g9U26L306897 for sctp-impl@external.cisco.com; Tue, 29 Oct 2002 21:06:21 -0500 Date: Tue, 29 Oct 2002 21:06:21 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: Re: OPNET module for SCTP? Message-ID: <20021029210621.A6803@bbn.com> References: <20021029102636.A20338@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from acaro@mail.eecis.udel.edu on Tue, Oct 29, 2002 at 02:57:19PM -0500 On Tue, Oct 29, 2002 at 02:57:19PM -0500, Armando L. Caro Jr. wrote: > On Tue, 29 Oct 2002, Craig Rodrigues wrote: > > Does an OPNET ( http://www.opnet.com ) module for SCTP exist? > > Yes, but I don't know much about it other than it was developed by R. > Brennan and T. Curran of Dublin City University. Cool, thanks. I'll look into it. They have a nice paper about their work: http://www.eeng.dcu.ie/~opnet/#[Brennan2001] -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 30 07:50:05 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12262 for ; Wed, 30 Oct 2002 07:50:04 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UChcPP013403 for ; Wed, 30 Oct 2002 04:43:38 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9UChVwC004761 for ; Wed, 30 Oct 2002 04:43:31 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9UChbqj000203 for ; Wed, 30 Oct 2002 04:43:38 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id A0BE8C1C86 for ; Wed, 30 Oct 2002 07:24:14 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g9UCOET11614 for sctp-impl@external.cisco.com; Wed, 30 Oct 2002 07:24:14 -0500 Date: Wed, 30 Oct 2002 07:24:14 -0500 From: Chuck Winters To: sctp-impl@external.cisco.com Subject: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] Message-ID: <20021030072414.A11598@atl.lmco.com> Mail-Followup-To: sctp-impl@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i It didn't look like tsvwg wanted to take this, so I figured I would forward it over here :) Chuck ----- Forwarded message from Chuck Winters ----- Date: Tue, 29 Oct 2002 08:58:33 -0500 From: Chuck Winters To: tsvwg@ietf.org Subject: [Tsvwg] SCTP Sockets API Question User-Agent: Mutt/1.2.5i Hello All, There are a few questions I would like to ask. I noticed that there was a major effort made to keep the UDP style and TCP style SCTP sockets compatible with current programs written to use UDP or TCP. There also seems to be an unnecessary restriction on the UDP style SCTP socket. Why the error when calling accept on a UDP style socket? I understand we want TCP and UDP compatability, but this seems unnecessary. Thanks, Chuck Winters _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ----- End forwarded message ----- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 30 08:37:55 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14183 for ; Wed, 30 Oct 2002 08:37:55 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UDW8PP001939; Wed, 30 Oct 2002 05:32:08 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN13004; Wed, 30 Oct 2002 05:32:06 -0800 (PST) Message-ID: <3DBFDF56.30601@cisco.com> Date: Wed, 30 Oct 2002 07:32:06 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl@external.cisco.com Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] References: <20021030072414.A11598@atl.lmco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck: Sorry I have been traveling or I would have answered there... still catching up in email :> A UDP style socket is more correctly called a 1 <-> Many type socket. I.e. a socket represents multiple associations. Now calling listen() makes sense to enable the server side (if you will) to get incoming associations... however how would one in a 1 <-> Many socket use accept? Accept is used to give you an new socket descriptor that holds the incoming association... but that would be the same descriptor in the case of a UDP style socket... Unless you wanted to take one of the associations into its own socket.. but which one? You can't specify an address to accept() so this is why sctppeeloff() was put into the spec.. Hope that helps.. R Chuck Winters wrote: >It didn't look like tsvwg wanted to take this, so I figured I would >forward it over here :) > >Chuck >----- Forwarded message from Chuck Winters ----- > >Date: Tue, 29 Oct 2002 08:58:33 -0500 >From: Chuck Winters >To: tsvwg@ietf.org >Subject: [Tsvwg] SCTP Sockets API Question >User-Agent: Mutt/1.2.5i > >Hello All, > There are a few questions I would like to ask. I noticed that there was >a major effort made to keep the UDP style and TCP style SCTP sockets >compatible with current programs written to use UDP or TCP. There also >seems to be an unnecessary restriction on the UDP style SCTP socket. Why >the error when calling accept on a UDP style socket? I understand we want >TCP and UDP compatability, but this seems unnecessary. > >Thanks, >Chuck Winters >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > >----- End forwarded message ----- > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Oct 30 08:43:41 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14481 for ; Wed, 30 Oct 2002 08:43:40 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9UDc5ot011560; Wed, 30 Oct 2002 05:38:05 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN13060; Wed, 30 Oct 2002 05:38:04 -0800 (PST) Message-ID: <3DBFE0BC.8030605@cisco.com> Date: Wed, 30 Oct 2002 07:38:04 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?GB2312?B?zfW66szO?= CC: SCTP mailist Subject: Re: References: <20021029075051.193701C664248@sm205.163.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Wang: I will attempt to answer your question. ÍõºêÌÎ wrote: >hello all! > >I have a confusion on the section 3.6 of prsctp draft. as following.... > > "during processing of a FORWARD TSN, the receiver MUST > use the stream sequence information to examine all of the listed > stream reordering queues, and immediately make available for delivery > stream sequence numbers earlier than or equal to the stream sequence > number listed inside the FORWARD TSN. > > The above tells you that you are to deliver anything held in stream reordering queues... so if you get SSN2, SSN3 ... and then get a FWD-TSN that tells you you can deliver up to SSN3 (skipping the TSN of SSN1) then you can deliver SSN2 and SSN3... > After receiving and processing a FORWARD TSN, ... The receiver MUST > remove any partially reassembled message which is still missing one > or more TSNs earlier than or equal to the new cumulative TSN point." > > Should the receiver delivery the full reliable messages which are not expired and t their SSN are earlier than or equal to the stream sequence number listed inside the FORWARD TSN, but they are still missing some chunks (their TSN is earlier than or equal to the new cumulative TSN point). > You would never get this situation... Consider SSN5 in TSN1, 2, 3, 4. sent reliable SSN6 in TSN5 sent unreliabile SSN7 in TSN6 sent reliable. Now lets say TSN5 is lost and dropped.. TSN3 is also missing. In this case a fwd-tsn would NOT be issued until the receiver sent a SACK that reported 1-4 present.. Anytime there are reliable un-ack'ed chunks outstanding the sender can NOT send the FWD-TSN. Once TSN4 is sacked .. then the sender would send a FWD-TSN (TSN5)----> to the peer Hope that helps.. R > If the receiver do so, the lifetime of full reliable messages are not usful.in fact the reliable messages are not reliable because they are delivered partially before the their lifetime expire. > > > >-------------------------------------------------- >Hongtao WANG >National Switching Technology and Communication Network Lab. >Beijing University of Posts and Telecommunications >Beijing ,100876,P.R.China >Tel:(+8610)-62283757 >Email:wang.ht2002@163.com >-------------------------------------------------- > > > > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Oct 30 09:48:06 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17087 for ; Wed, 30 Oct 2002 09:48:05 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9UEduxF024906 for ; Wed, 30 Oct 2002 06:39:56 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UEdrqa005042 for ; Wed, 30 Oct 2002 06:39:53 -0800 (PST) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9UEcDLr006384 for ; Wed, 30 Oct 2002 06:38:14 -0800 (PST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA15606; Wed, 30 Oct 2002 08:25:04 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA32600; Wed, 30 Oct 2002 08:33:08 -0600 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA03930; Wed, 30 Oct 2002 08:33:07 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DBFE67F.1E195D2B@us.ibm.com> Date: Wed, 30 Oct 2002 08:02:39 -0600 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.44 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl@external.cisco.com Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] References: <20021030072414.A11598@atl.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Chuck, Chuck Winters wrote: > > It didn't look like tsvwg wanted to take this, so I figured I would > forward it over here :) > > Chuck > ----- Forwarded message from Chuck Winters ----- > > Date: Tue, 29 Oct 2002 08:58:33 -0500 > From: Chuck Winters > To: tsvwg@ietf.org > Subject: [Tsvwg] SCTP Sockets API Question > User-Agent: Mutt/1.2.5i > > Hello All, > There are a few questions I would like to ask. I noticed that there was > a major effort made to keep the UDP style and TCP style SCTP sockets > compatible with current programs written to use UDP or TCP. Well, I'll at least agree on with you on TCP-style being a close approximation to SOCK_STREAM/TCP semantics, but not so with UDP-style. Both are more programming models with an API on top of them to propogate that model. At the last bakeoff we discussed some of the defaults that might make UDP-style more SOCK_DGRAM like -> auto-accept (listen) ON, all events OFF, auto-close ON. However, this would likely not be the right thing to do, as this would just further confuse folks into thinking that UDP-style is attempting SOCK_DGRAM/UDP transparency. > seems to be an unnecessary restriction on the UDP style SCTP socket. Why > the error when calling accept on a UDP style socket? I understand we want > TCP and UDP compatability, but this seems unnecessary. > I'd have to understand why you were interested. If we could disable auto-accept on listen() behavior, it seems possible to queue up the associations and let them get accept()ed manually by the application, instead of auto-accept. So its probably possible to write, However..... ....if you are porting a UDP application, you wouldn't do an 'accept()', and if you aren't, you have other alternatives - such as peeloff and events which are more powerful/flexible. If you really _do_ want 'accept()' maybe TCP-style is better suited for your application?? Just some half-baked thoughts, Jon Grimm > Thanks, > Chuck Winters > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > ----- End forwarded message ----- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Oct 30 10:38:16 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20534 for ; Wed, 30 Oct 2002 10:38:11 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9UFZGgM010071 for ; Wed, 30 Oct 2002 07:35:16 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UFZIgf015328 for ; Wed, 30 Oct 2002 07:35:19 -0800 (PST) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9UFXdLr014739 for ; Wed, 30 Oct 2002 07:33:40 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g9UFVev25483 for sctp-impl@external.cisco.com; Wed, 30 Oct 2002 10:31:40 -0500 Date: Wed, 30 Oct 2002 10:31:39 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: Preprocessor constants indicated SCTP is available? Message-ID: <20021030103139.B25253@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hi, What preprocessor constants do the various SCTP implementations use to indicate the presence of SCTP on a platform? If I want to have a piece of code that optionally compiles in SCTP stuff it is available on some platform, I'd like to do something like: #include #include #ifdef SCTP_AVAILABLE sctp code here #endif The POSIX standard uses this approach. For example, on a POSIX compliant system, if you #include , constants like _POSIX_REALTIME_SIGNALS, _POSIX_THREADS, etc. will get defined if those features are available on a system. Thanksable on a system. Thanks -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Oct 30 15:38:03 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09882 for ; Wed, 30 Oct 2002 15:38:02 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UKSHPP020118; Wed, 30 Oct 2002 12:28:17 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN27095; Wed, 30 Oct 2002 12:28:14 -0800 (PST) Message-ID: <3DC040DE.6050607@cisco.com> Date: Wed, 30 Oct 2002 14:28:14 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues CC: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? References: <20021030103139.B25253@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Craig: Good question... maybe we should have some standard SCTP_IS_PRESENT defined in a standard place.. such as sctp.h in lieu of this for the Apache APR work that I have been assiting in.. what they did is fix their configure.in to generate a small program to do a sd = socket(...,IPPROTO_SCTP); and if it did NOT error it defines a apr.h variable #define HAVE_SCTP 1 else if sd == -1 #define HAVE_SCTP 0 That way a #if HAVE_SCTP .... #endif could be done in apache code.. R Craig Rodrigues wrote: >Hi, > >What preprocessor constants do the various SCTP implementations use >to indicate the presence of SCTP on a platform? > >If I want to have a piece of code that optionally compiles in SCTP >stuff it is available on some platform, I'd like to do something like: > >#include >#include > >#ifdef SCTP_AVAILABLE > > sctp code here > >#endif > > >The POSIX standard uses this approach. For example, on a POSIX compliant >system, if you #include , constants like >_POSIX_REALTIME_SIGNALS, _POSIX_THREADS, etc. will get defined >if those features are available on a system. > >Thanksable on a system. > >Thanks > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 31 06:15:00 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13172 for ; Thu, 31 Oct 2002 06:14:59 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9VBDCot004204 for ; Thu, 31 Oct 2002 03:13:12 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VBDBRZ020205 for ; Thu, 31 Oct 2002 03:13:12 -0800 (PST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9VBD1qj023393 for ; Thu, 31 Oct 2002 03:13:02 -0800 (PST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA24960; Thu, 31 Oct 2002 11:56:04 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA00636; Thu, 31 Oct 2002 11:55:53 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Oct 2002 11:55:20 +0100 Message-ID: From: Tuexen Michael To: "'Randall Stewart (cisco)'" , Craig Rodrigues Cc: sctp-impl@external.cisco.com Subject: RE: Preprocessor constants indicated SCTP is available? Date: Thu, 31 Oct 2002 11:55:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Dear all, we use a constant HAVE_KERNEL_SCTP to handle the case where an kernel implementation of SCTP is available. If not our userland implementation is used. It would be nice if kernel implementations could define such a constant such we are able to provide SCTP services in userland if no kernel services are available. However, it is not a big deal, but it would simplify things. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Wednesday, October 30, 2002 9:28 PM > To: Craig Rodrigues > Cc: sctp-impl@external.cisco.com > Subject: Re: Preprocessor constants indicated SCTP is available? > > > Craig: > > Good question... maybe we should have some standard > > SCTP_IS_PRESENT > > defined in a standard place.. such as sctp.h > > in lieu of this for the Apache APR work that I have been > assiting in.. > what they > did is fix their configure.in to generate a small program to do a > > sd = socket(...,IPPROTO_SCTP); > > and if it did NOT error it defines a apr.h variable > > #define HAVE_SCTP 1 > > else if sd == -1 > > #define HAVE_SCTP 0 > > That way a > > #if HAVE_SCTP > > .... > > #endif > > could be done in apache code.. > > R > > Craig Rodrigues wrote: > > >Hi, > > > >What preprocessor constants do the various SCTP implementations use > >to indicate the presence of SCTP on a platform? > > > >If I want to have a piece of code that optionally compiles in SCTP > >stuff it is available on some platform, I'd like to do > something like: > > > >#include > >#include > > > >#ifdef SCTP_AVAILABLE > > > > sctp code here > > > >#endif > > > > > >The POSIX standard uses this approach. For example, on a > POSIX compliant > >system, if you #include , constants like > >_POSIX_REALTIME_SIGNALS, _POSIX_THREADS, etc. will get defined > >if those features are available on a system. > > > >Thanksable on a system. > > > >Thanks > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 31 08:43:05 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18745 for ; Thu, 31 Oct 2002 08:43:04 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VDf3PP019831 for ; Thu, 31 Oct 2002 05:41:03 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VDf2LE003081 for ; Thu, 31 Oct 2002 05:41:02 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9VDf1qj002620 for ; Thu, 31 Oct 2002 05:41:02 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 0EC10C1CF4 for ; Thu, 31 Oct 2002 08:21:46 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g9VDLjg01454 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 08:21:45 -0500 Date: Thu, 31 Oct 2002 08:21:45 -0500 From: Chuck Winters To: sctp-impl@external.cisco.com Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] Message-ID: <20021031082145.A1421@atl.lmco.com> Mail-Followup-To: sctp-impl@external.cisco.com References: <20021030072414.A11598@atl.lmco.com> <3DBFDF56.30601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DBFDF56.30601@cisco.com>; from rrs@cisco.com on Wed, Oct 30, 2002 at 07:32:06AM -0600 Randall, On Wed, Oct 30, 2002 at 07:32:06AM -0600, Randall Stewart (cisco) wrote: > Chuck: > > Sorry I have been traveling or I would have answered there... still catching > up in email :> > > A UDP style socket is more correctly called a 1 <-> Many type socket. I.e. a > socket represents multiple associations. Now calling listen() makes sense > to enable the server side (if you will) to get incoming associations... > however > how would one in a 1 <-> Many socket use accept? What type of application would use this interface? > > Accept is used to give you an new socket descriptor that holds the incoming > association... but that would be the same descriptor in the case of a UDP > style socket... Unless you wanted to take one of the associations into its > own socket.. but which one? You can't specify an address to accept() so this > is why sctppeeloff() was put into the spec.. What about accept() have semantics something like sctppeeloff where accept() returns the first association in it's list? > > Hope that helps.. > > R Chuck -- Chuck Winters | Email: cwinters@atl.lmco.com Distributed Processing Laboratory | Phone: 856-338-3987 Lockheed Martin Advanced Technology Labs | 1 Federal St - A&E-3W | Camden, NJ 08102 | From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Oct 31 08:47:44 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18991 for ; Thu, 31 Oct 2002 08:47:42 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VDjDgM017202 for ; Thu, 31 Oct 2002 05:45:13 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VDjAg1008607 for ; Thu, 31 Oct 2002 05:45:10 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9VDjFqj004880 for ; Thu, 31 Oct 2002 05:45:16 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 67EC1C1D22 for ; Thu, 31 Oct 2002 08:26:00 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g9VDQ0g01479 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 08:26:00 -0500 Date: Thu, 31 Oct 2002 08:26:00 -0500 From: Chuck Winters To: sctp-impl@external.cisco.com Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] Message-ID: <20021031082600.B1421@atl.lmco.com> Mail-Followup-To: sctp-impl@external.cisco.com References: <20021030072414.A11598@atl.lmco.com> <3DBFE67F.1E195D2B@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DBFE67F.1E195D2B@us.ibm.com>; from jgrimm2@us.ibm.com on Wed, Oct 30, 2002 at 08:02:39AM -0600 Jon, On Wed, Oct 30, 2002 at 08:02:39AM -0600, Jon Grimm wrote: > Hi Chuck, > > Chuck Winters wrote: > > > > > It didn't look like tsvwg wanted to take this, so I figured I would > > forward it over here :) > > > > Chuck > > ----- Forwarded message from Chuck Winters ----- > > > > Date: Tue, 29 Oct 2002 08:58:33 -0500 > > From: Chuck Winters > > To: tsvwg@ietf.org > > Subject: [Tsvwg] SCTP Sockets API Question > > User-Agent: Mutt/1.2.5i > > > > Hello All, > > There are a few questions I would like to ask. I noticed that there was > > a major effort made to keep the UDP style and TCP style SCTP sockets > > compatible with current programs written to use UDP or TCP. > > Well, I'll at least agree on with you on TCP-style being a close > approximation to SOCK_STREAM/TCP semantics, but not so with UDP-style. > Both are more programming models with an API on top of them to propogate > that model. Could you clarify a little what the programming model of the UDP-style is? > > > At the last bakeoff we discussed some of the defaults that might make > UDP-style more SOCK_DGRAM like -> auto-accept (listen) ON, all events > OFF, auto-close ON. However, this would likely not be the right thing > to do, as this would just further confuse folks into thinking that > UDP-style is attempting SOCK_DGRAM/UDP transparency. > > > > seems to be an unnecessary restriction on the UDP style SCTP socket. Why > > the error when calling accept on a UDP style socket? I understand we want > > TCP and UDP compatability, but this seems unnecessary. > > > > I'd have to understand why you were interested. If we could disable > auto-accept on listen() behavior, it seems possible to queue up the > associations and let them get accept()ed manually by the application, > instead of auto-accept. So its probably possible to write, However..... > > ....if you are porting a UDP application, you wouldn't do an 'accept()', > and if you aren't, you have other alternatives - such as peeloff and > events which are more powerful/flexible. If you really _do_ want > 'accept()' maybe TCP-style is better suited for your application?? I'm not really looking for UDP transparency, I'm looking more at a connected datagram type of service for new applications. > > Just some half-baked thoughts, > Jon Grimm > Thanks, Chuck -- Chuck Winters | Email: cwinters@atl.lmco.com Distributed Processing Laboratory | Phone: 856-338-3987 Lockheed Martin Advanced Technology Labs | 1 Federal St - A&E-3W | Camden, NJ 08102 | From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 31 09:54:31 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22271 for ; Thu, 31 Oct 2002 09:54:30 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VErNPP022123 for ; Thu, 31 Oct 2002 06:53:23 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VErMx5029984 for ; Thu, 31 Oct 2002 06:53:22 -0800 (PST) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9VEpgMg021707 for ; Thu, 31 Oct 2002 06:51:42 -0800 (PST) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA11676 for ; Thu, 31 Oct 2002 08:44:49 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA35308 for ; Thu, 31 Oct 2002 08:46:56 -0600 Received: from us.ibm.com (grimm.dynamic.austin.ibm.com [9.41.94.118] (may be forged)) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA27026 for ; Thu, 31 Oct 2002 08:46:55 -0600 Message-ID: <3DC140E3.8060200@us.ibm.com> Date: Thu, 31 Oct 2002 08:40:35 -0600 From: Jon Grimm Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl Subject: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Forgot to cc the mailing list too. Hi again, Chuck Winters wrote: >Jon Grimm wrote: >>....if you are porting a UDP application, you wouldn't do an 'accept()', >>and if you aren't, you have other alternatives - such as peeloff and >>events which are more powerful/flexible. If you really _do_ want >>'accept()' maybe TCP-style is better suited for your application?? > > I'm not really looking for UDP transparency, I'm looking more at a connected > datagram type of service for new applications. > Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP is message based, both API styles preserve this concept (especially if you stick to sendmsg/recvmsg). Best Regards, Jon Grimm From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 31 09:58:52 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23156 for ; Thu, 31 Oct 2002 09:58:51 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VEtLxF011155; Thu, 31 Oct 2002 06:55:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN50427; Thu, 31 Oct 2002 06:55:26 -0800 (PST) Message-ID: <3DC1445D.4090003@cisco.com> Date: Thu, 31 Oct 2002 08:55:25 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl@external.cisco.com Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] References: <20021030072414.A11598@atl.lmco.com> <3DBFE67F.1E195D2B@us.ibm.com> <20021031082600.B1421@atl.lmco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck: Ok... I think the basic question you are asking is what/why would you use the UDP model/style Now from my view here is what the UDP or 1 to N style gets you: 1) Automatic acceptance of associations (you still have to specify a listen() call.. even though in the socketapi authors group I fought against this .. you don't always get what you want ) 2) The ability to auto close idle associations 3) Only one socket descriptor to manage/worry about Basically the idea is to have a single socket that gets all associations and just gets data from various endpoints.. much like a open UDP socket. I, the application programmer, no longer must worry about accepting connections and tracking file descriptors... instead it looks akin to UDP where I just get data from various peers and when I send to a peer it just goes there... This also allows bundling of data on the cookie-echo message (3rd leg of the 4-way handshake in SCTP)... the tcp style can not do this due to the vaguries of the socket api interface. In all of my servers using the UDP style I would: 1) turn autoclose on. 2) do a single listen() 3) receive messages and respond to them Nothing else is required... R Chuck Winters wrote: >Jon, > >On Wed, Oct 30, 2002 at 08:02:39AM -0600, Jon Grimm wrote: > > >>Hi Chuck, >> >>Chuck Winters wrote: >> >> >> >>>It didn't look like tsvwg wanted to take this, so I figured I would >>>forward it over here :) >>> >>>Chuck >>>----- Forwarded message from Chuck Winters ----- >>> >>>Date: Tue, 29 Oct 2002 08:58:33 -0500 >>>From: Chuck Winters >>>To: tsvwg@ietf.org >>>Subject: [Tsvwg] SCTP Sockets API Question >>>User-Agent: Mutt/1.2.5i >>> >>>Hello All, >>> There are a few questions I would like to ask. I noticed that there was >>>a major effort made to keep the UDP style and TCP style SCTP sockets >>>compatible with current programs written to use UDP or TCP. >>> >>> >>Well, I'll at least agree on with you on TCP-style being a close >>approximation to SOCK_STREAM/TCP semantics, but not so with UDP-style. >>Both are more programming models with an API on top of them to propogate >>that model. >> >> >Could you clarify a little what the programming model of the UDP-style is? > > >>At the last bakeoff we discussed some of the defaults that might make >>UDP-style more SOCK_DGRAM like -> auto-accept (listen) ON, all events >>OFF, auto-close ON. However, this would likely not be the right thing >>to do, as this would just further confuse folks into thinking that >>UDP-style is attempting SOCK_DGRAM/UDP transparency. >> >> >> >> >>>seems to be an unnecessary restriction on the UDP style SCTP socket. Why >>>the error when calling accept on a UDP style socket? I understand we want >>>TCP and UDP compatability, but this seems unnecessary. >>> >>> >>> >>I'd have to understand why you were interested. If we could disable >>auto-accept on listen() behavior, it seems possible to queue up the >>associations and let them get accept()ed manually by the application, >>instead of auto-accept. So its probably possible to write, However..... >> >>....if you are porting a UDP application, you wouldn't do an 'accept()', >>and if you aren't, you have other alternatives - such as peeloff and >>events which are more powerful/flexible. If you really _do_ want >>'accept()' maybe TCP-style is better suited for your application?? >> >> >I'm not really looking for UDP transparency, I'm looking more at a connected >datagram type of service for new applications. > > >>Just some half-baked thoughts, >>Jon Grimm >> >> >> >Thanks, >Chuck > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 31 10:02:34 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23345 for ; Thu, 31 Oct 2002 10:02:33 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VF0uxF014519; Thu, 31 Oct 2002 07:00:56 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN50526; Thu, 31 Oct 2002 07:01:00 -0800 (PST) Message-ID: <3DC145AB.2090803@cisco.com> Date: Thu, 31 Oct 2002 09:00:59 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: Tuexen Michael , Craig Rodrigues , sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? References: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit La Monte: I jive with most of your items but I do have questions: _POSIX_SCTP_ESP _POSIX_SCTP_IPAH - supports RFC2402 IP Authentication Header??, _POSIX_SCTP_ISAKMP - supports RFC2408 ISAKMP??, _POSIX_SCTP_IKE How in the world are these SCTP things... if the O/S supports ESP/IPAH/IKE etc is this not an issue with the underlying O/S? I also assume that : _POSIX_SCTP_SAFE_MAC - MAC secret key is cryptographic (RFC1750), means that you are using a SHA-1 or MD5 type encrytpt on the cookies? Or do you mean it to mean we are using Good random numbers in pciking the INIT-TSN and VTAG? R La Monte Henry Piggy Yarroll wrote: >May I suggest the somewhat presumptuous _POSIX_SCTP? We should also >define _POSIX_SCTP_PRSCTP, _POSIX_SCTP_ADDIP, and similar symbols for >any optional features in the RFC. > >A quick scan of the MAY clauses shows mostly minor behavioral and >implementation options. The only ones I can IMAGINE being useful to >an application writer are: > >_POSIX_SCTP_BUNDLING - supports outbound bundling, >_POSIX_SCTP_FRAGMENTATION - supports outbound fragmentation, >_POSIX_SCTP_ESP - supports IP Encapsulating Security Payload, >_POSIX_SCTP_ECN - supports Explicit Congestion Notification, > >A quick scan of SHOULD clauses turns up: > >_POSIX_SCTP_HOSTNAME - can generate HOSTNAME-based INITs, >_POSIX_SCTP_SMALL_COOKIE - implementation generates a small cookie :-), >_POSIX_SCTP_RESTART - generates RESTART notifications, >_POSIX_SCTP_DELAYED_ACK - implements delayed ACK, >_POSIX_SCTP_GAP_ACK - will generate SACK GAP ACK blocks, >_POSIX_SCTP_DUP - will generate SACK DUP reports, >_POSIX_SCTP_REVOCATION - can revoke GAP ACKd DATA, >_POSIX_SCTP_GAP_DISABLES_DACK - GAP reports disable delayed ACK, >_POSIX_SCTP_PATH_FAILURE - generates notification on path failure, >_POSIX_SCTP_IPAH - supports RFC2402 IP Authentication Header??, >_POSIX_SCTP_ISAKMP - supports RFC2408 ISAKMP??, >_POSIX_SCTP_IKE - supports RFC2409 Internet Key Exchange??, >_POSIX_SCTP_SAFE_MAC - MAC secret key is cryptographic (RFC1750), > >On Thu, 31 Oct 2002 11:55:17 +0100, Tuexen Michael > wrote: > > >>Dear all, >> >>we use a constant >> >>HAVE_KERNEL_SCTP >> >>to handle the case where an kernel implementation of SCTP is >>available. If not our userland implementation is used. >> >>It would be nice if kernel implementations could define >>such a constant such we are able to provide SCTP services >>in userland if no kernel services are available. >> >>However, it is not a big deal, but it would simplify things. >> >>Best regards >>Michael >> >>Michael Tuexen Tel.: +49 89 722 47210 >>Siemens AG Fax: +49 89 722 48212 >>ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com >> >> >> >>>-----Original Message----- >>>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] >>>Sent: Wednesday, October 30, 2002 9:28 PM >>>To: Craig Rodrigues >>>Cc: sctp-impl@external.cisco.com >>>Subject: Re: Preprocessor constants indicated SCTP is available? >>> >>> >>>Craig: >>> >>>Good question... maybe we should have some standard >>> >>>SCTP_IS_PRESENT >>> >>>defined in a standard place.. such as sctp.h >>> >>>in lieu of this for the Apache APR work that I have been >>>assiting in.. >>>what they >>>did is fix their configure.in to generate a small program to do a >>> >>>sd = socket(...,IPPROTO_SCTP); >>> >>>and if it did NOT error it defines a apr.h variable >>> >>>#define HAVE_SCTP 1 >>> >>>else if sd == -1 >>> >>>#define HAVE_SCTP 0 >>> >>>That way a >>> >>>#if HAVE_SCTP >>> >>>.... >>> >>>#endif >>> >>>could be done in apache code.. >>> >>>R >>> >>>Craig Rodrigues wrote: >>> >>> >>> >>>>Hi, >>>> >>>>What preprocessor constants do the various SCTP implementations use >>>>to indicate the presence of SCTP on a platform? >>>> >>>>If I want to have a piece of code that optionally compiles in SCTP >>>>stuff it is available on some platform, I'd like to do >>>> >>>> >>>something like: >>> >>> >>>>#include >>>>#include >>>> >>>>#ifdef SCTP_AVAILABLE >>>> >>>> sctp code here >>>> >>>>#endif >>>> >>>> >>>>The POSIX standard uses this approach. For example, on a >>>> >>>> >>>POSIX compliant >>> >>> >>>>system, if you #include , constants like >>>>_POSIX_REALTIME_SIGNALS, _POSIX_THREADS, etc. will get defined >>>>if those features are available on a system. >>>> >>>>Thanksable on a system. >>>> >>>>Thanks >>>> >>>> >>>> >>>> >>>-- >>>Randall R. Stewart >>>ITD >>>Cisco Systems Inc. >>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>> >>> >>> >>> >>> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Oct 31 10:25:05 2002 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24858 for ; Thu, 31 Oct 2002 10:25:03 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9VFLxot020231 for ; Thu, 31 Oct 2002 07:21:59 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VFLw1g009380 for ; Thu, 31 Oct 2002 07:21:58 -0800 (PST) Received: from baqaqi.chi.il.us (12-249-3-4.client.attbi.com [12.249.3.4]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9VFKHMg010160 for ; Thu, 31 Oct 2002 07:20:18 -0800 (PST) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g9VEPbv05584; Thu, 31 Oct 2002 08:25:42 -0600 Message-Id: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> To: Tuexen Michael cc: "'Randall Stewart (cisco)'" , Craig Rodrigues , sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: Preprocessor constants indicated SCTP is available? In-reply-to: Your message of Thu, 31 Oct 2002 11:55:17 +0100. Date: Thu, 31 Oct 2002 08:25:37 -0600 Sender: piggy@baqaqi.chi.il.us May I suggest the somewhat presumptuous _POSIX_SCTP? We should also define _POSIX_SCTP_PRSCTP, _POSIX_SCTP_ADDIP, and similar symbols for any optional features in the RFC. A quick scan of the MAY clauses shows mostly minor behavioral and implementation options. The only ones I can IMAGINE being useful to an application writer are: _POSIX_SCTP_BUNDLING - supports outbound bundling, _POSIX_SCTP_FRAGMENTATION - supports outbound fragmentation, _POSIX_SCTP_ESP - supports IP Encapsulating Security Payload, _POSIX_SCTP_ECN - supports Explicit Congestion Notification, A quick scan of SHOULD clauses turns up: _POSIX_SCTP_HOSTNAME - can generate HOSTNAME-based INITs, _POSIX_SCTP_SMALL_COOKIE - implementation generates a small cookie :-), _POSIX_SCTP_RESTART - generates RESTART notifications, _POSIX_SCTP_DELAYED_ACK - implements delayed ACK, _POSIX_SCTP_GAP_ACK - will generate SACK GAP ACK blocks, _POSIX_SCTP_DUP - will generate SACK DUP reports, _POSIX_SCTP_REVOCATION - can revoke GAP ACKd DATA, _POSIX_SCTP_GAP_DISABLES_DACK - GAP reports disable delayed ACK, _POSIX_SCTP_PATH_FAILURE - generates notification on path failure, _POSIX_SCTP_IPAH - supports RFC2402 IP Authentication Header??, _POSIX_SCTP_ISAKMP - supports RFC2408 ISAKMP??, _POSIX_SCTP_IKE - supports RFC2409 Internet Key Exchange??, _POSIX_SCTP_SAFE_MAC - MAC secret key is cryptographic (RFC1750), On Thu, 31 Oct 2002 11:55:17 +0100, Tuexen Michael wrote: > Dear all, > > we use a constant > > HAVE_KERNEL_SCTP > > to handle the case where an kernel implementation of SCTP is > available. If not our userland implementation is used. > > It would be nice if kernel implementations could define > such a constant such we are able to provide SCTP services > in userland if no kernel services are available. > > However, it is not a big deal, but it would simplify things. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN WN CC SE 7 e-mail: Michael.Tuexen@siemens.com > > > -----Original Message----- > > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > > Sent: Wednesday, October 30, 2002 9:28 PM > > To: Craig Rodrigues > > Cc: sctp-impl@external.cisco.com > > Subject: Re: Preprocessor constants indicated SCTP is available? > > > > > > Craig: > > > > Good question... maybe we should have some standard > > > > SCTP_IS_PRESENT > > > > defined in a standard place.. such as sctp.h > > > > in lieu of this for the Apache APR work that I have been > > assiting in.. > > what they > > did is fix their configure.in to generate a small program to do a > > > > sd = socket(...,IPPROTO_SCTP); > > > > and if it did NOT error it defines a apr.h variable > > > > #define HAVE_SCTP 1 > > > > else if sd == -1 > > > > #define HAVE_SCTP 0 > > > > That way a > > > > #if HAVE_SCTP > > > > .... > > > > #endif > > > > could be done in apache code.. > > > > R > > > > Craig Rodrigues wrote: > > > > >Hi, > > > > > >What preprocessor constants do the various SCTP implementations use > > >to indicate the presence of SCTP on a platform? > > > > > >If I want to have a piece of code that optionally compiles in SCTP > > >stuff it is available on some platform, I'd like to do > > something like: > > > > > >#include > > >#include > > > > > >#ifdef SCTP_AVAILABLE > > > > > > sctp code here > > > > > >#endif > > > > > > > > >The POSIX standard uses this approach. For example, on a > > POSIX compliant > > >system, if you #include , constants like > > >_POSIX_REALTIME_SIGNALS, _POSIX_THREADS, etc. will get defined > > >if those features are available on a system. > > > > > >Thanksable on a system. > > > > > >Thanks > > > > > > > > > > > > -- > > Randall R. Stewart > > ITD > > Cisco Systems Inc. > > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Oct 31 10:52:23 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26745 for ; Thu, 31 Oct 2002 10:52:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VFpBgM009279 for ; Thu, 31 Oct 2002 07:51:11 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VFpEIw001382 for ; Thu, 31 Oct 2002 07:51:14 -0800 (PST) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9VFnXMg029509 for ; Thu, 31 Oct 2002 07:49:34 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g9VFjg020419 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 10:45:42 -0500 Date: Thu, 31 Oct 2002 10:45:42 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? Message-ID: <20021031104542.A20411@bbn.com> References: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200210311425.g9VEPbv05584@baqaqi.chi.il.us>; from piggy@baqaqi.chi.il.us on Thu, Oct 31, 2002 at 08:25:37AM -0600 On Thu, Oct 31, 2002 at 08:25:37AM -0600, La Monte Henry Piggy Yarroll wrote: > May I suggest the somewhat presumptuous _POSIX_SCTP? We should also > define _POSIX_SCTP_PRSCTP, _POSIX_SCTP_ADDIP, and similar symbols for > any optional features in the RFC. > > A quick scan of the MAY clauses shows mostly minor behavioral and > implementation options. The only ones I can IMAGINE being useful to > an application writer are: > > _POSIX_SCTP_BUNDLING - supports outbound bundling, > _POSIX_SCTP_FRAGMENTATION - supports outbound fragmentation, > _POSIX_SCTP_ESP - supports IP Encapsulating Security Payload, > _POSIX_SCTP_ECN - supports Explicit Congestion Notification, Lamonte, You're on the right track for what I'm looking for. I think it is great, and will make writing portable code a lot easier!! If all the SCTP implementations could agree on something, that would be super. The only thing is, I caution you about using _POSIX_ as the prefix, since none of these constants have gone through the standards process yet, so they are not "officially" approved by POSIX. It might be OK, but I would consult with a standards guru before proceeding. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Oct 31 11:09:46 2002 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27884 for ; Thu, 31 Oct 2002 11:09:44 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VG7xgM018145; Thu, 31 Oct 2002 08:07:59 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN51974; Thu, 31 Oct 2002 08:08:01 -0800 (PST) Message-ID: <3DC15559.2090803@cisco.com> Date: Thu, 31 Oct 2002 10:07:53 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues CC: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? References: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> <20021031104542.A20411@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Craig: Why don't we just use _HAVE_SCTP_xxxxxx and then define these all in the next pass of the sockets draft.. if posix standardizes it then you can do a define _POSIX_SCTP_xxxx _HAVE_SCTP_xxxx R Craig Rodrigues wrote: >On Thu, Oct 31, 2002 at 08:25:37AM -0600, La Monte Henry Piggy Yarroll wrote: > > >>May I suggest the somewhat presumptuous _POSIX_SCTP? We should also >>define _POSIX_SCTP_PRSCTP, _POSIX_SCTP_ADDIP, and similar symbols for >>any optional features in the RFC. >> >>A quick scan of the MAY clauses shows mostly minor behavioral and >>implementation options. The only ones I can IMAGINE being useful to >>an application writer are: >> >>_POSIX_SCTP_BUNDLING - supports outbound bundling, >>_POSIX_SCTP_FRAGMENTATION - supports outbound fragmentation, >>_POSIX_SCTP_ESP - supports IP Encapsulating Security Payload, >>_POSIX_SCTP_ECN - supports Explicit Congestion Notification, >> >> > >Lamonte, > >You're on the right track for what I'm looking for. >I think it is great, and will make writing portable code a lot easier!! >If all the SCTP implementations could agree on something, that would be super. > >The only thing is, I caution you about using _POSIX_ as the prefix, since none >of these constants have gone through the standards process yet, >so they are not "officially" approved by POSIX. > >It might be OK, but I would consult with a standards guru before proceeding. > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 31 11:50:04 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00638 for ; Thu, 31 Oct 2002 11:50:03 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VGmLxF027555 for ; Thu, 31 Oct 2002 08:48:21 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VGmKJw017233 for ; Thu, 31 Oct 2002 08:48:20 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9VGkiMg012611 for ; Thu, 31 Oct 2002 08:46:45 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id BE034C1D04 for ; Thu, 31 Oct 2002 11:29:33 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g9VGTXN02535 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 11:29:33 -0500 Date: Thu, 31 Oct 2002 11:29:33 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021031112933.A2350@atl.lmco.com> Mail-Followup-To: sctp-impl References: <3DC140E3.8060200@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DC140E3.8060200@us.ibm.com>; from jgrimm2@us.ibm.com on Thu, Oct 31, 2002 at 08:40:35AM -0600 Jon, On Thu, Oct 31, 2002 at 08:40:35AM -0600, Jon Grimm wrote: > Forgot to cc the mailing list too. > > Hi again, > > Chuck Winters wrote: > >Jon Grimm wrote: > >>....if you are porting a UDP application, you wouldn't do an 'accept()', > >>and if you aren't, you have other alternatives - such as peeloff and > >>events which are more powerful/flexible. If you really _do_ want > >>'accept()' maybe TCP-style is better suited for your application?? > > > > I'm not really looking for UDP transparency, I'm looking more at a > connected > > datagram type of service for new applications. > > > > Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP > is message based, both API styles preserve this concept (especially if > you stick to sendmsg/recvmsg). I was under the impression that if you used the TCP-style model, when you read from the socket, you would get as many bytes as you asked for(excluding EPIPE, etc), and not just the next chunk. So, for instance if SCTP received 2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket, you would get 100 bytes of the first chunk, and 20 bytes from the next chunk. Is that not how the stream api works? > > > Best Regards, > Jon Grimm > Chuck -- Chuck Winters | Email: cwinters@atl.lmco.com Distributed Processing Laboratory | Phone: 856-338-3987 Lockheed Martin Advanced Technology Labs | 1 Federal St - A&E-3W | Camden, NJ 08102 | From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 31 12:31:12 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02871 for ; Thu, 31 Oct 2002 12:31:06 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHTHxF028662 for ; Thu, 31 Oct 2002 09:29:17 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHTFvl023124 for ; Thu, 31 Oct 2002 09:29:15 -0800 (PST) Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g9VHQeMg018354 for ; Thu, 31 Oct 2002 09:26:41 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g9VHN2220755 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 12:23:02 -0500 Date: Thu, 31 Oct 2002 12:23:02 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? Message-ID: <20021031122302.A20743@bbn.com> References: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> <20021031104542.A20411@bbn.com> <3DC15559.2090803@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DC15559.2090803@cisco.com>; from rrs@cisco.com on Thu, Oct 31, 2002 at 10:07:53AM -0600 On Thu, Oct 31, 2002 at 10:07:53AM -0600, Randall Stewart (cisco) wrote: > > Craig: > > Why don't we just use > > _HAVE_SCTP_xxxxxx > > and then define these all in the next pass of the sockets draft.. > if posix standardizes it then you can do a > > define _POSIX_SCTP_xxxx _HAVE_SCTP_xxxx Sounds good to me. I would even just leave the _HAVE prefix out of it. #define _SCTP_xxxx 1 When the standards people realize what an awesome thing SCTP is, they can do: #define _POSIX_SCTP_xxx _SCTP_xxx or whatever. By the way, for those who are curious, the latest POSIX standard (IEEE Std 1003.1-2001) has merged with the latest Single Unix Specification, and it is all free to read on the web: http://www.opengroup.org/onlinepubs/007904975/toc.htm -- Craig Rodrigues Distributed Systems and Logistics, Office 6/325A crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Oct 31 12:44:32 2002 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03844 for ; Thu, 31 Oct 2002 12:44:31 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHgYxF009857 for ; Thu, 31 Oct 2002 09:42:34 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VHgWrw005330 for ; Thu, 31 Oct 2002 09:42:33 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9VHgXqj022735 for ; Thu, 31 Oct 2002 09:42:35 -0800 (PST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA47672; Thu, 31 Oct 2002 11:37:55 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA18204; Thu, 31 Oct 2002 11:35:35 -0600 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id LAA34444; Thu, 31 Oct 2002 11:35:34 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC1627D.54497BDC@us.ibm.com> Date: Thu, 31 Oct 2002 11:03:57 -0600 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.44 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] References: <3DC140E3.8060200@us.ibm.com> <20021031112933.A2350@atl.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi again, > > > > > > > Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP > > is message based, both API styles preserve this concept (especially if > > you stick to sendmsg/recvmsg). > I was under the impression that if you used the TCP-style model, when you > read from the socket, you would get as many bytes as you asked for(excluding > EPIPE, etc), and not just the next chunk. So, for instance if SCTP received > 2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket, > you would get 100 bytes of the first chunk, and 20 bytes from the next chunk. > Is that not how the stream api works? > Certainly an application must allow for thie behavior with read/recv (though I hope apps are also written to account for short reads 'cause it happens). However, I don't see strong requirements on this from the implementor's standpoint, where I may choose to send up message length reads - the application should never count on this though. The recvmsg wording in the I-D currently only says there are two differences in the behavior of sendmsg/recvmsg between TCP style and UDP style. MSG_EOR is not one of those differences, so my current read on the I-D says that the message boundaries behavior is preserved. This is why I tacked on the sendmsg/recvmsg words to my response above. IMO, you need to use sendmsg/recvmsg in either bottle to take advantage of the SCTP features anyway. I'm pretty sure I'll get thumped down if I'm reading this all wrong.. so its good you ask this so I can get this all straight in my head. ;-) Best Regards, Jon > > > > > > Best Regards, > > Jon Grimm > > > > Chuck > -- > Chuck Winters | Email: cwinters@atl.lmco.com > Distributed Processing Laboratory | Phone: 856-338-3987 > Lockheed Martin Advanced Technology Labs | > 1 Federal St - A&E-3W | > Camden, NJ 08102 | From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 31 14:21:40 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09461 for ; Thu, 31 Oct 2002 14:21:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VJGLPP006703 for ; Thu, 31 Oct 2002 11:16:21 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VJGJ1V018721 for ; Thu, 31 Oct 2002 11:16:20 -0800 (PST) Received: from enterprise.atl.lmco.com ([192.35.37.50]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g9VJG9Gj017237 for ; Thu, 31 Oct 2002 11:16:14 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id C555CC1D07 for ; Thu, 31 Oct 2002 13:55:59 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id g9VItxV03392 for sctp-impl@external.cisco.com; Thu, 31 Oct 2002 13:55:59 -0500 Date: Thu, 31 Oct 2002 13:55:59 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021031135559.A3263@atl.lmco.com> Mail-Followup-To: sctp-impl References: <3DC140E3.8060200@us.ibm.com> <20021031112933.A2350@atl.lmco.com> <3DC1627D.54497BDC@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DC1627D.54497BDC@us.ibm.com>; from jgrimm2@us.ibm.com on Thu, Oct 31, 2002 at 11:03:57AM -0600 It's me again, On Thu, Oct 31, 2002 at 11:03:57AM -0600, Jon Grimm wrote: > Hi again, > > > > > > > > > > > > Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP > > > is message based, both API styles preserve this concept (especially if > > > you stick to sendmsg/recvmsg). > > > I was under the impression that if you used the TCP-style model, when you > > read from the socket, you would get as many bytes as you asked for(excluding > > EPIPE, etc), and not just the next chunk. So, for instance if SCTP received > > 2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket, > > you would get 100 bytes of the first chunk, and 20 bytes from the next chunk. > > Is that not how the stream api works? > > > > Certainly an application must allow for thie behavior with read/recv > (though I hope apps are also written to account for short reads 'cause > it happens). However, I don't see strong requirements on this from the > implementor's standpoint, where I may choose to send up message length > reads - the application should never count on this though. "Should" and "Do" are two totally different things :) > > The recvmsg wording in the I-D currently only says there are two > differences in the behavior of sendmsg/recvmsg between TCP style and UDP > style. MSG_EOR is not one of those differences, so my current read on > the I-D says that the message boundaries behavior is preserved. This is > why I tacked on the sendmsg/recvmsg words to my response above. IMO, > you need to use sendmsg/recvmsg in either bottle to take advantage of > the SCTP features anyway. Correct me if I'm wrong, bug if message boundaries are preserved, the semantics should be that a read on the socket should return one message, or part of a message(if the buffer it is being read into is too small). If the message is smaller than the buffer, still only 1 message is read into the buffer. Now, if message boundaries are preserved, and the previously stated semantics are correct, then why is SOCK_STREAM used as a service type? Wouldn't SOCK_DGRAM be a better fit? Chuck > > I'm pretty sure I'll get thumped down if I'm reading this all wrong.. so > its good you ask this so I can get this all straight in my head. ;-) > > Best Regards, > Jon > > > > > > > > > > > Best Regards, > > > Jon Grimm > > > > > > > Chuck > > -- > > Chuck Winters | Email: cwinters@atl.lmco.com > > Distributed Processing Laboratory | Phone: 856-338-3987 > > Lockheed Martin Advanced Technology Labs | > > 1 Federal St - A&E-3W | > > Camden, NJ 08102 | -- Chuck Winters | Email: cwinters@atl.lmco.com Distributed Processing Laboratory | Phone: 856-338-3987 Lockheed Martin Advanced Technology Labs | 1 Federal St - A&E-3W | Camden, NJ 08102 | From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 31 15:31:20 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13461 for ; Thu, 31 Oct 2002 15:31:18 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VKTKPP025679 for ; Thu, 31 Oct 2002 12:29:20 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VKTI90016575 for ; Thu, 31 Oct 2002 12:29:19 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g9VKTGqj001822 for ; Thu, 31 Oct 2002 12:29:17 -0800 (PST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA26124; Thu, 31 Oct 2002 14:24:47 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA23306; Thu, 31 Oct 2002 14:22:27 -0600 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id OAA26218; Thu, 31 Oct 2002 14:22:26 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC18993.E07014E8@us.ibm.com> Date: Thu, 31 Oct 2002 13:50:43 -0600 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.44 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] References: <3DC140E3.8060200@us.ibm.com> <20021031112933.A2350@atl.lmco.com> <3DC1627D.54497BDC@us.ibm.com> <20021031135559.A3263@atl.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck Winters wrote: > > It's me again, > > On Thu, Oct 31, 2002 at 11:03:57AM -0600, Jon Grimm wrote: > > Hi again, > > > > > > > > > > > > > > > > > Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP > > > > is message based, both API styles preserve this concept (especially if > > > > you stick to sendmsg/recvmsg). > > > > > I was under the impression that if you used the TCP-style model, when you > > > read from the socket, you would get as many bytes as you asked for(excluding > > > EPIPE, etc), and not just the next chunk. So, for instance if SCTP received > > > 2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket, > > > you would get 100 bytes of the first chunk, and 20 bytes from the next chunk. > > > Is that not how the stream api works? > > > > > > > Certainly an application must allow for thie behavior with read/recv > > (though I hope apps are also written to account for short reads 'cause > > it happens). However, I don't see strong requirements on this from the > > implementor's standpoint, where I may choose to send up message length > > reads - the application should never count on this though. > "Should" and "Do" are two totally different things :) Yep, I tried to word that all _very_ carefully. > > > > The recvmsg wording in the I-D currently only says there are two > > differences in the behavior of sendmsg/recvmsg between TCP style and UDP > > style. MSG_EOR is not one of those differences, so my current read on > > the I-D says that the message boundaries behavior is preserved. This is > > why I tacked on the sendmsg/recvmsg words to my response above. IMO, > > you need to use sendmsg/recvmsg in either bottle to take advantage of > > the SCTP features anyway. > Correct me if I'm wrong, bug if message boundaries are preserved, the semantics > should be that a read on the socket should return one message, or part of a > message(if the buffer it is being read into is too small). If the message is > smaller than the buffer, still only 1 message is read into the buffer. Now, > if message boundaries are preserved, and the previously stated semantics are > correct, then why is SOCK_STREAM used as a service type? > Wouldn't SOCK_DGRAM be a better fit? > Well its a little hard to call it a bug if its not specified. I just call'em like I read'em. The recvmsg behavior needs to be there for applications that want to bite off a little bit of SCTP knowledge. I prefer not to have differing behaviors for read vs recvmsg. Due to layering, it may even be quite difficult to force two different behaviors at the read vs recvmsg interface. In the linux case, read/recv/recvfrom all wrapper recvmsg before entry into the transport specific layer. Its a little weird to put SCTP under SOCK_STREAM anyway. IMO, 1-1 should have been SOCK_SEQPACKET and 1-many something new entirely.. SOCK_SCTP. I'm guessing the original thoughts on the I-D were a tradeoff in application porting vs semantics vs getting at all the kewl bits in SCTP. For impementation reasons I need it to be specified either as: a) TCP-style recvmsg MUST preserve message boundaries read/recv MAY preserve boundaries. b) TCP-style read/recv MUST preserve stream semantics, recvmsg MAY preserve message semantics The current I-D allows (a) (though possibly by oversight), but I could tolerate (b) too The third option, which require differing behaviors, will not always be possible, so... the app will need to be ready for this situation anyway. Best Regards, Jon From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Oct 31 16:22:57 2002 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15714 for ; Thu, 31 Oct 2002 16:22:55 -0500 (EST) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9VL37PP015976; Thu, 31 Oct 2002 13:03:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN64125; Thu, 31 Oct 2002 13:03:06 -0800 (PST) Message-ID: <3DC19A89.6090009@cisco.com> Date: Thu, 31 Oct 2002 15:03:05 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Grimm CC: Chuck Winters , sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] References: <3DC140E3.8060200@us.ibm.com> <20021031112933.A2350@atl.lmco.com> <3DC1627D.54497BDC@us.ibm.com> <20021031135559.A3263@atl.lmco.com> <3DC18993.E07014E8@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon: Some answers to both of you: 1) First and formost.. YOU MUST preserve message boundaries no matter which you open UDP or TCP style 2) There will be no MUST/MUST NOT wording in the current ID.. there cannot be since it will in the end be an informational RFC. 3) What ties the MUST into number 1 is RFC2960.. since it emphasis message boundary preservation... So basically you should either get a FULL message or a part of a message.. but NEVER the end of one message and the beginning of the other... otherwise you end up with NO message boundaries and break the SCTP symantics. Now as to why we made the choices we did.. I think your (Jon's) guesses are about right on.. and we wanted to avoid defining new types i.e. SOCK_SCTP etc.. R Jon Grimm wrote: >Chuck Winters wrote: > > >>It's me again, >> >>On Thu, Oct 31, 2002 at 11:03:57AM -0600, Jon Grimm wrote: >> >> >>>Hi again, >>> >>> >>> >>> >>>>> > >>>>> >>>>>Ah... Well, why not just use the TCP-style model (1-1)? Since SCTP >>>>>is message based, both API styles preserve this concept (especially if >>>>>you stick to sendmsg/recvmsg). >>>>> >>>>> >>>>I was under the impression that if you used the TCP-style model, when you >>>>read from the socket, you would get as many bytes as you asked for(excluding >>>>EPIPE, etc), and not just the next chunk. So, for instance if SCTP received >>>>2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket, >>>>you would get 100 bytes of the first chunk, and 20 bytes from the next chunk. >>>>Is that not how the stream api works? >>>> >>>> >>>> >>>Certainly an application must allow for thie behavior with read/recv >>>(though I hope apps are also written to account for short reads 'cause >>>it happens). However, I don't see strong requirements on this from the >>>implementor's standpoint, where I may choose to send up message length >>>reads - the application should never count on this though. >>> >>> >>"Should" and "Do" are two totally different things :) >> >> > >Yep, I tried to word that all _very_ carefully. > > > >>>The recvmsg wording in the I-D currently only says there are two >>>differences in the behavior of sendmsg/recvmsg between TCP style and UDP >>>style. MSG_EOR is not one of those differences, so my current read on >>>the I-D says that the message boundaries behavior is preserved. This is >>>why I tacked on the sendmsg/recvmsg words to my response above. IMO, >>>you need to use sendmsg/recvmsg in either bottle to take advantage of >>>the SCTP features anyway. >>> >>> > > > >>Correct me if I'm wrong, bug if message boundaries are preserved, the semantics >>should be that a read on the socket should return one message, or part of a >>message(if the buffer it is being read into is too small). If the message is >>smaller than the buffer, still only 1 message is read into the buffer. Now, >>if message boundaries are preserved, and the previously stated semantics are >>correct, then why is SOCK_STREAM used as a service type? >>Wouldn't SOCK_DGRAM be a better fit? >> >> >> > >Well its a little hard to call it a bug if its not specified. > >I just call'em like I read'em. The recvmsg behavior needs to be there >for applications that want to bite off a little bit of SCTP knowledge. >I prefer not to have differing behaviors for read vs recvmsg. Due to >layering, it may even be quite difficult to force two different >behaviors at the read vs recvmsg interface. In the linux case, >read/recv/recvfrom all wrapper recvmsg before entry into the transport >specific layer. > >Its a little weird to put SCTP under SOCK_STREAM anyway. IMO, 1-1 >should have been SOCK_SEQPACKET and 1-many something new entirely.. >SOCK_SCTP. I'm guessing the original thoughts on the I-D were a >tradeoff in application porting vs semantics vs getting at all the kewl >bits in SCTP. > >For impementation reasons I need it to be specified either as: >a) TCP-style recvmsg MUST preserve message boundaries read/recv MAY >preserve boundaries. >b) TCP-style read/recv MUST preserve stream semantics, recvmsg MAY >preserve message semantics > >The current I-D allows (a) (though possibly by oversight), but I could >tolerate (b) too >The third option, which require differing behaviors, will not always be >possible, so... the app will need to be ready for this situation >anyway. > > >Best Regards, >Jon > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)