From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Fri Nov 1 07:51: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 HAA05230 for ; Fri, 1 Nov 2002 07:51:29 -0500 (EST) 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 gA1CjGgM023811 for ; Fri, 1 Nov 2002 04:45:16 -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 gA1CjJ3K011392 for ; Fri, 1 Nov 2002 04:45:19 -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 gA1Chcx9012039 for ; Fri, 1 Nov 2002 04:43:38 -0800 (PST) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id gA1Ce6B09446; Fri, 1 Nov 2002 06:40:07 -0600 Message-Id: <200211011240.gA1Ce6B09446@baqaqi.chi.il.us> To: "Randall Stewart (cisco)" cc: 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 10:07:53 -0600. <3DC15559.2090803@cisco.com> Date: Fri, 01 Nov 2002 06:40:05 -0600 Sender: piggy@baqaqi.chi.il.us On Thu, 31 Oct 2002 10:07:53 -0600, "Randall Stewart (cisco)" w rote: > > 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 Renaming is hard. The draft API will be done LONG before POSIX actually standardizes it. Is there a serious problem with using the _POSIX_SCTP_ prefix? Can we get Open Group to allocate it to us for preliminary work? > 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-4.cisco.com Fri Nov 1 08:23:34 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 IAA05711 for ; Fri, 1 Nov 2002 08:23:32 -0500 (EST) 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 gA1DM3ot000781 for ; Fri, 1 Nov 2002 05:22:03 -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 gA1DM2jj027663 for ; Fri, 1 Nov 2002 05:22:02 -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 gA1DKLx9025104 for ; Fri, 1 Nov 2002 05:20:22 -0800 (PST) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id gA1CKvV09234; Fri, 1 Nov 2002 06:20:57 -0600 Message-Id: <200211011220.gA1CKvV09234@baqaqi.chi.il.us> To: "Randall Stewart (cisco)" cc: Tuexen Michael , 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 09:00:59 -0600. <3DC145AB.2090803@cisco.com> Date: Fri, 01 Nov 2002 06:20:56 -0600 Sender: piggy@baqaqi.chi.il.us On Thu, 31 Oct 2002 09:00:59 -0600, "Randall Stewart (cisco)" w rote: > 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've never used any of these, so I didn't know if there were any direct interactions with the transport layer. They are all listed explicitly in RFC2960. > 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? This one should have had a smiley :-) on it too. It just means the implementation uses Good random numbers picking INIT-TSN and VTAG. You had no question about _POSIX_SCTP_SMALL_COOKIE? :-) > 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-2.cisco.com Fri Nov 1 09:00:24 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 JAA07320 for ; Fri, 1 Nov 2002 09:00: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-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA1CsSgM026001 for ; Fri, 1 Nov 2002 04:54:28 -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 gA1CsVnM023543 for ; Fri, 1 Nov 2002 04:54:31 -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 gA1Cqox9015577 for ; Fri, 1 Nov 2002 04:52:51 -0800 (PST) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id gA1CnMR09520; Fri, 1 Nov 2002 06:49:27 -0600 Message-Id: <200211011249.gA1CnMR09520@baqaqi.chi.il.us> To: Chuck Winters cc: sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question] In-reply-to: Your message of Thu, 31 Oct 2002 08:21:45 -0500. <20021031082145.A1421@atl.lmco.com> Date: Fri, 01 Nov 2002 06:49:22 -0600 Sender: piggy@baqaqi.chi.il.us On Thu, 31 Oct 2002 08:21:45 -0500, Chuck Winters wrote : > Randall, > > On Wed, Oct 30, 2002 at 07:32:06AM -0600, Randall Stewart (cisco) > > wrote: 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? The sctppeeloff() call allows you to extract a single association which you plan to handle separately, e.g. in another thread. With your proposed semantics, it would not make very much sense to use accept() for only a subset of the associations since the semantics would essentially be "pick a random association to peel off". If you use accept() for every association, you have a poor approximation of the TCP-style interface. Randy, how about renaming sctppeeloff() to sctp_accept()? > > 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-1.cisco.com Fri Nov 1 09:43: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 JAA12474 for ; Fri, 1 Nov 2002 09:43:41 -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 gA1EfsPP028920 for ; Fri, 1 Nov 2002 06:41:54 -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 gA1EfkoP004202 for ; Fri, 1 Nov 2002 06:41:47 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA1Efldv009976 for ; Fri, 1 Nov 2002 06:41:47 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id F2AC5C1D02 for ; Fri, 1 Nov 2002 09:22:36 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id gA1EMaV09023 for sctp-impl@external.cisco.com; Fri, 1 Nov 2002 09:22:36 -0500 Date: Fri, 1 Nov 2002 09:22:36 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021101092236.A8590@atl.lmco.com> Mail-Followup-To: sctp-impl 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DC18993.E07014E8@us.ibm.com>; from jgrimm2@us.ibm.com on Thu, Oct 31, 2002 at 01:50:43PM -0600 Hey again, On Thu, Oct 31, 2002 at 01:50:43PM -0600, Jon Grimm wrote: > > 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. Sorry, should be "but" not "bug". > > 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. I agree, recvmsg must be there, and it must be able to get info from SCTP. > > 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. It is probably better to fit SCTP to current service types rather than make new ones. > > 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. IMO recv/read/readv/recvmsg should have the same semantics for the same service type. > > > Best Regards, > Jon Later, 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 Fri Nov 1 09:51:43 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 JAA13788 for ; Fri, 1 Nov 2002 09:51:42 -0500 (EST) 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 gA1Eo4gM003227 for ; Fri, 1 Nov 2002 06:50:04 -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 gA1Eo74Z013186 for ; Fri, 1 Nov 2002 06:50:07 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA1Eo1dv012978 for ; Fri, 1 Nov 2002 06:50:01 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 25B43C1D0F for ; Fri, 1 Nov 2002 09:30:31 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id gA1EUVv09062 for sctp-impl@external.cisco.com; Fri, 1 Nov 2002 09:30:31 -0500 Date: Fri, 1 Nov 2002 09:30:31 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021101093031.B8590@atl.lmco.com> Mail-Followup-To: sctp-impl 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> <3DC19A89.6090009@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: <3DC19A89.6090009@cisco.com>; from rrs@cisco.com on Thu, Oct 31, 2002 at 03:03:05PM -0600 Hi again, On Thu, Oct 31, 2002 at 03:03:05PM -0600, Randall Stewart (cisco) wrote: > 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. Then why use SOCK_STREAM? IMO, the service type defines how the data is presented to the upper layer. There is no indication(in my mind) that SOCK_STREAM means "connected socket" other than the historical fact that TCP uses SOCK_STREAM. I believe that SOCK_DGRAM would be a much better fit to the way data is structured in SCTP. > > 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.. Agreed, not a good idea. I think that one would be hard to get by a standards commitee > > R > > Later, 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 Fri Nov 1 10:34:19 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 KAA16963 for ; Fri, 1 Nov 2002 10:34:18 -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 gA1FWVgM019732; Fri, 1 Nov 2002 07:32:31 -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 AAN85035; Fri, 1 Nov 2002 07:32:33 -0800 (PST) Message-ID: <3DC29E90.8070205@cisco.com> Date: Fri, 01 Nov 2002 09:32:32 -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 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> <3DC19A89.6090009@cisco.com> <20021101093031.B8590@atl.lmco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck Winters wrote: >Hi again, > >On Thu, Oct 31, 2002 at 03:03:05PM -0600, Randall Stewart (cisco) wrote: > > >>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. >> >> >Then why use SOCK_STREAM? IMO, the service type defines how the data is >presented to the upper layer. There is no indication(in my mind) that >SOCK_STREAM means "connected socket" other than the historical fact that >TCP uses SOCK_STREAM. I believe that SOCK_DGRAM would be a much better >fit to the way data is structured in SCTP. > The reason I believe we selectecd SOCK_STREAM is that we DID want a mode that looked like TCP. Making it be SOCK_DGRAM would imply it looked like UDP not TCP. And we have been quite sucessful simulating TCP's interface. Take a look at the www.sctp.org web page and you can find a mozilla and an apache that use the TCP style and don't even know that they are using SCTP. We have also somewhere in our backlog of things to put on the web site a ftp/ftpd and openssh.. all with simple changes to the socket() call to make SCTP be used.. I think SOCK_DGRAM just plain implies that one would open it and read.. much like our UDP style. Tradition in the network coding world dicatates that SOCK_STREAM is connection oriented with the accept()/connect()/listen() calls. R > > >>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.. >> >> >Agreed, not a good idea. I think that one would be hard to get by a standards >commitee > > >>R >> >> >> >> > > >Later, >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-4.cisco.com Fri Nov 1 10:36:15 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 KAA17099 for ; Fri, 1 Nov 2002 10:36:14 -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 gA1FYfot025640; Fri, 1 Nov 2002 07:34:41 -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 AAN85060; Fri, 1 Nov 2002 07:34:40 -0800 (PST) Message-ID: <3DC29F10.2070805@cisco.com> Date: Fri, 01 Nov 2002 09:34:40 -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 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> <20021101092236.A8590@atl.lmco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck Winters wrote: >Hey again, > >On Thu, Oct 31, 2002 at 01:50:43PM -0600, Jon Grimm wrote: > > > > >>>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. >> >> >Sorry, should be "but" not "bug". > > >>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. >> >> >I agree, recvmsg must be there, and it must be able to get info from SCTP. > > >>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. >> >> >It is probably better to fit SCTP to current service types rather than >make new ones. > > >>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. >> >> >IMO recv/read/readv/recvmsg should have the same semantics for the same service type. > > If you look closely at a TCP service style.. the same service is being offered by the SCTP model as well... TCP NEVER returns a two seperate messages... there is always either the whole message read or some number of parts.. of course there is always only one message :-) This IS consistent with what SCTP is doing :-> R > > >>Best Regards, >>Jon >> >> > >Later, >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 Fri Nov 1 12:27:10 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 MAA24053 for ; Fri, 1 Nov 2002 12:27:09 -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 gA1HFCxF005698 for ; Fri, 1 Nov 2002 09:15:12 -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 gA1HFHxo028631 for ; Fri, 1 Nov 2002 09:15:17 -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 gA1HFAdv023604 for ; Fri, 1 Nov 2002 09:15:11 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id gA1HB4I27081 for sctp-impl@external.cisco.com; Fri, 1 Nov 2002 12:11:04 -0500 Date: Fri, 1 Nov 2002 12:11:04 -0500 From: Craig Rodrigues To: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? Message-ID: <20021101121104.A27077@bbn.com> References: <3DC15559.2090803@cisco.com> <200211011240.gA1Ce6B09446@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: <200211011240.gA1Ce6B09446@baqaqi.chi.il.us>; from piggy@baqaqi.chi.il.us on Fri, Nov 01, 2002 at 06:40:05AM -0600 On Fri, Nov 01, 2002 at 06:40:05AM -0600, La Monte Henry Piggy Yarroll wrote: > On Thu, 31 Oct 2002 10:07:53 -0600, "Randall Stewart (cisco)" w > rote: > > > > 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 > > Renaming is hard. The draft API will be done LONG before POSIX > actually standardizes it. Is there a serious problem with using the > _POSIX_SCTP_ prefix? Can we get Open Group to allocate it to us for > preliminary work? Let me try contacting someone at the Opengroup. POSIX comes under IEEE, so IEEE may feel that they own the _POSIX_* namespace. That's the only reason why I suggested holding off on using it. But give me a few days to find the right contact in Opengroup. Opengroup did some work recently in taking some of the IETF work with the IPv6 socket API and added that to the Single Unix Specification, v3, so there is a precedent for adding new networking API's to the standards. -- 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 Fri Nov 1 13:30:58 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 NAA27824 for ; Fri, 1 Nov 2002 13:30: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-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA1ITwot017838 for ; Fri, 1 Nov 2002 10:29:58 -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 gA1IToNO025498 for ; Fri, 1 Nov 2002 10:29:50 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA1ITodv001545 for ; Fri, 1 Nov 2002 10:29:51 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 438BFC1D02 for ; Fri, 1 Nov 2002 13:11:02 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id gA1IB2s10486 for sctp-impl@external.cisco.com; Fri, 1 Nov 2002 13:11:02 -0500 Date: Fri, 1 Nov 2002 13:11:02 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021101131102.A9678@atl.lmco.com> Mail-Followup-To: sctp-impl 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> <20021101092236.A8590@atl.lmco.com> <3DC29F10.2070805@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: <3DC29F10.2070805@cisco.com>; from rrs@cisco.com on Fri, Nov 01, 2002 at 09:34:40AM -0600 On Fri, Nov 01, 2002 at 09:34:40AM -0600, Randall Stewart (cisco) wrote: > > If you look closely at a TCP service style.. the same service is being > offered by > the SCTP model as well... TCP NEVER returns a two seperate messages... > there is > always either the whole message read or some number of parts.. of course > there is > always only one message :-) > > This IS consistent with what SCTP is doing :-> > > R > Nice point :) That's like following the letter of the law instead of the spirit of the law. 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 Fri Nov 1 14:20:05 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 OAA29874 for ; Fri, 1 Nov 2002 14:20: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-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA1JGxxF006544 for ; Fri, 1 Nov 2002 11:17:03 -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 gA1JGuwp005581 for ; Fri, 1 Nov 2002 11:16:57 -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 gA1JH2qj010485 for ; Fri, 1 Nov 2002 11:17:03 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 43E6CC1D02 for ; Fri, 1 Nov 2002 13:57:52 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id gA1IvqM10784 for sctp-impl@external.cisco.com; Fri, 1 Nov 2002 13:57:52 -0500 Date: Fri, 1 Nov 2002 13:57:52 -0500 From: Chuck Winters To: sctp-impl Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] Message-ID: <20021101135752.B9678@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 Hello All, So, I decided to take lunch and think about my position a little more. I looked at this page: http://www.opengroup.org/onlinepubs/007904975/functions/socket.html to get a little guidance on the subject, and this is what I found: The type argument specifies the socket type, which determines the semantics of communication over the socket. The following socket types are defined; implementations may specify additional socket types: SOCK_STREAM Provides sequenced, reliable, bidirectional, connection-mode byte streams, and may provide a transmission mechanism for out-of-band data. SOCK_DGRAM Provides datagrams, which are connectionless-mode, unreliable messages of fixed maximum length. SOCK_SEQPACKET Provides sequenced, reliable, bidirectional, connection-mode transmission paths for records. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers part of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag. So it seems that SCTP fits best into the SOCK_SEQPACKET category. Being that that is already in use, it is a choice between SOCK_DGRAM and SOCK_STREAM. Then I began trying to decide how I liked my words prepared(that way they tasted good when I ate them). I had seen on a few pages that ATM had the idea of adding SOCK_CONN_DGRAM to the sockets api. That seems like that would be a better match than both SOCK_DGRAM and SOCK_STREAM. Later, 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-4.cisco.com Fri Nov 1 15:23:43 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 PAA02807 for ; Fri, 1 Nov 2002 15:23:42 -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 gA1KMpot007466 for ; Fri, 1 Nov 2002 12:22:51 -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 gA1KMogK022324 for ; Fri, 1 Nov 2002 12:22:50 -0800 (PST) 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 gA1KMidv029035 for ; Fri, 1 Nov 2002 12:22:45 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA00352; Fri, 1 Nov 2002 13:17:49 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA07961; Fri, 1 Nov 2002 13:17:46 -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 gA1KHhf07648; Fri, 1 Nov 2002 14:17:44 -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 OAA06820; Fri, 1 Nov 2002 14:18:54 -0600 (CST) Message-ID: <3DC2E18B.D9484713@Motorola.com> Date: Fri, 01 Nov 2002 14:18:19 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) 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> <20021101135752.B9678@atl.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit .... > So it seems that SCTP fits best into the SOCK_SEQPACKET category. Being that that > is already in use, it is a choice between SOCK_DGRAM and SOCK_STREAM. Then I began > trying to decide how I liked my words prepared(that way they tasted good when I ate > them). I had seen on a few pages that ATM had the idea of adding SOCK_CONN_DGRAM to > the sockets api. That seems like that would be a better match than both SOCK_DGRAM > and SOCK_STREAM. Considering that SCTP provides a new type of service that did not exist in the traditional IP transport protocols, I'd expect that some new definitions in sockets will be created and people will pick them up gradually. I.e., we do not need to be constrained by what is there. -Qiaobing From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Nov 1 15:59:33 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 PAA04068 for ; Fri, 1 Nov 2002 15:59:32 -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 gA1KsTPP006804; Fri, 1 Nov 2002 12:54: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 AAN96631; Fri, 1 Nov 2002 12:54:27 -0800 (PST) Message-ID: <3DC2EA03.90001@cisco.com> Date: Fri, 01 Nov 2002 14:54:27 -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 Subject: Re: [Fwd: Re: [chuck.winters@lmco.com: [Tsvwg] SCTP Sockets API Question]] References: <3DC140E3.8060200@us.ibm.com> <20021101135752.B9678@atl.lmco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chuck: With the idea that we did NOT want to define a new type.. you can see our delima SOCK_SEQPACKET fits one of our styles no problem.. we elected to use it with UDP. But where do you place the tcp style? The concept behind it was definetly compatability with TCP... we wanted things to work seamlessly when you used this model with an existing TCP app.. change the one field in the socket() call and presto.. you are using SCTP.. So the SOCK_DGRAM did NOT seem like the right choice... i.e. connectionless... I will admit if we had really wanted to define a new type then probably moving the tcp style to sock_seqpacket would be ok to do... but I am still happy with our current choices... since SCTP CAN be used whereever TCP is used and so you have one tweak to do to the app socket() call.. and it fits with what the user expects. If one turns on autoclose() and does a listen() then this also makes things look very non-connection oriented in its own right.. aka. like a SOCK_DGRAM... R Chuck Winters wrote: >Hello All, > So, I decided to take lunch and think about my position a little more. I >looked at this page: > http://www.opengroup.org/onlinepubs/007904975/functions/socket.html >to get a little guidance on the subject, and this is what I found: > > The type argument specifies the socket type, which determines the > semantics of communication over the socket. The following socket > types are defined; implementations may specify additional socket types: > > SOCK_STREAM > Provides sequenced, reliable, bidirectional, connection-mode byte streams, > and may provide a transmission mechanism for out-of-band data. > SOCK_DGRAM > Provides datagrams, which are connectionless-mode, unreliable messages of > fixed maximum length. > SOCK_SEQPACKET > Provides sequenced, reliable, bidirectional, connection-mode transmission > paths for records. A record can be sent using one or more output operations > and received using one or more input operations, but a single operation never > transfers part of more than one record. Record boundaries are visible to the > receiver via the MSG_EOR flag. > > So it seems that SCTP fits best into the SOCK_SEQPACKET category. Being that that >is already in use, it is a choice between SOCK_DGRAM and SOCK_STREAM. Then I began >trying to decide how I liked my words prepared(that way they tasted good when I ate >them). I had seen on a few pages that ATM had the idea of adding SOCK_CONN_DGRAM to >the sockets api. That seems like that would be a better match than both SOCK_DGRAM >and SOCK_STREAM. > >Later, >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-2.cisco.com Sat Nov 2 07:21:42 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 HAA03209 for ; Sat, 2 Nov 2002 07:21:41 -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 gA2CHQgM015343 for ; Sat, 2 Nov 2002 04:17:26 -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 gA2CHSqj002437 for ; Sat, 2 Nov 2002 04:17:29 -0800 (PST) Received: from emztd105.com ([208.60.163.194]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id gA2CHOqj018964 for ; Sat, 2 Nov 2002 04:17:27 -0800 (PST) Message-Id: <200211021217.gA2CHOqj018964@proxy3.cisco.com> From: "FEMI JOHNSON" Reply-To: femijohnson1@caramail.com To: sctp-impl@external.cisco.com Date: Sat, 2 Nov 2002 12:19:19 +0100 Subject: awaiting your urgent response X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM 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 HAA03209 Dear Sir URGENT BUSINESS REQUEST I am a Solicitor resident and practicing in Lagos, Nigeria and I am using this correspondence to urgently seek and request your assistance and cooperation in a sensitive but highly beneficial financial arrangement. An important client of mine whose details I cannot release at this point has implored me to contact a reliable and trustworthy partner overseas to urgently receive and handle funds totaling TWENTY ONE MILLION US DOLLARS(US$21.M)in CASH presently lodged in a security/finance outfit in overseas. Due to my client inability to travel out of the country presently and the fact that we continue to accumulate huge debts daily as long as this consignment remains in the security company we need a friend and partner to proceed as soon as possible and handle it as might be instructed. We have agreed in principle to give twenty-percent (25%) of the total sum to whom ever shall handle this funds for us while the remaining sixty-five percent (65%)shall be for my client and ten-percent (10%) for me as the attorney as soon as you are ready to proceed and retrieve this cash on our behalf we shall furnish you with the details and nformation you will need. Please be rest assured that this arrangement is absolutely risk free and cannot implicate you in any way yet I implore you to handle this matter with urgency and utmost confidence even if you do not intend to execute the project for us. Whatever is the case please acknowledge receipt of this mail via the above Email address and if your response is positive we shall proceed immediately without any delay. Thank you in anticipation of your cooperation and hoping to hear from you soon. Yours sincerely, Barrister Femi Johnson (LLB). From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Nov 4 05:58:22 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 FAA08928 for ; Mon, 4 Nov 2002 05:58:21 -0500 (EST) 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 gA4Aroot002021 for ; Mon, 4 Nov 2002 02:53:50 -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 gA4Argm0000987 for ; Mon, 4 Nov 2002 02:53:42 -0800 (PST) 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 gA4Aq3S5015042 for ; Mon, 4 Nov 2002 02:52:05 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA23447 for ; Mon, 4 Nov 2002 11:37:12 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA29591 for ; Mon, 4 Nov 2002 11:37:14 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2656.59) id ; Mon, 4 Nov 2002 11:36:42 +0100 Message-ID: From: Schruefer Wolfgang To: sctp-impl@external.cisco.com Subject: AW: Preprocessor constants indicated SCTP is available? Date: Mon, 4 Nov 2002 11:36:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Hi, I am not so long in this business to know whether this suggestion is stupid or not, but can anybody tell me why the value of a #define is not used for additional information? My idea is to put the year of the standard or draft to which the implementation tries to comply to as value behind the symbol. This would enable us for the next centuries to add or change something without the usage of new #define symbols. E.g. if an application wants to use a future parameter it may use: #if _HAVE_SCTP_xxx > 2003 Thanks! Viele Gruesse Wolfgang From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Nov 5 09:15:09 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 JAA19605 for ; Tue, 5 Nov 2002 09:15:08 -0500 (EST) 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 gA5E7lot008763 for ; Tue, 5 Nov 2002 06:07:47 -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 gA5E7kU3002689 for ; Tue, 5 Nov 2002 06:07:46 -0800 (PST) Received: from out017.verizon.net (out017pub.verizon.net [206.46.170.94]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA5E7eiX016869 for ; Tue, 5 Nov 2002 06:07:41 -0800 (PST) Received: from cp134514-a ([138.88.22.135]) by out017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021105134852.NXHX2697.out017.verizon.net@cp134514-a> for ; Tue, 5 Nov 2002 07:48:52 -0600 Message-ID: <41147-22002112513491150@cp134514-a> X-Priority: 3 Reply-To: dave.dickson2@verizon.net X-MSMail-Priority: Normal From: "Dave Dickson" To: "SCTP-IMPL@EXTERNAL.CISCO.COM" Subject: Training Conference - Mobile and Wireless Solutions - November 13, 2002 Date: Tue, 5 Nov 2002 08:49:11 -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 JAA19605 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:00 AM Wrap-up: 5:00 PM Continental Breakfast, Refreshments, Lunch included. HOTLINE AVAILABLE - Call 703-807-2027 on instructions to view the most current AGENDA and to learn how you can register on-line. *** SPECIAL NOTE: We have three conferences planned in November and December 2002. These include: * Homeland Defense: Mobile and Wireless Solutions Nov 13, 2002, Arlington, Va. * Homeland Defense: Protecting America's Infrastructure - Cyber Defense Nov 19, 2002, Arlington, Va. * Homeland Defense: Information Sharing December 4, 2002, Arlington, Va. PLUS ... * Homeland Defense: Federal, Regional and State Strategies, Colorado Springs, Colo, Jan 14-16 * Global e-Government with Department of State, Washington, D.C. Nov 20-22, 2002 SPEAKERS CONFIRMED: * US SENATOR CONRAD BURNS (R-MT), advocate of emergency responder communications and member of the Senate Appropriations Committee * KATHLEEN HAMM, Deputy Chief, Wireles Telecommunications Bureau, FCC * ANDREW KREIG, President, Wireless Communications Association International (WCAI) [Industry Keynote Speaker] * MICHAEL D. DUFFY, Director, Telecommunications Services Staff and Wireless Management Office (Executive Director for the Justice/Treasury Integrated Wireless Network (IWN) Program), US Dept of Justice * CHRISTOPHER LEWIS, Telecommunications Specialist, Office of the CIO, Dept of Interior * GARY D. AMATO, Deputy Chief of Technology and Programs, National Communication System * SABRINA CRANE, Program Manager, GSA Federal Technology Services * TOM ABBATE, Communication Directorate, Advanced Technology Office, Communications Electronics Command, US Army * WAYNE JANSEN, Principal Scientist, Computer Security Division, NIST * CAROLYN JONDAHL, Senior Government Account Manager - DOD, Research In Motion, RIM/BlackBerry * CHRIS RANGLE, Assistant Vice President of Marketing, Alvarion, Inc. * GREG MEACHAM, Director, Federal Sector, Nextel Communications 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. Parrish Knight, 703/807-2748. **** 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 Parrish Knight (703) 807-2748 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 #20 - 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. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 5 13:31:09 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 NAA03895 for ; Tue, 5 Nov 2002 13:31:08 -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 gA5ITRPP013765 for ; Tue, 5 Nov 2002 10:29:27 -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 gA5ITRaZ015151 for ; Tue, 5 Nov 2002 10:29:27 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA5ITKiX010896 for ; Tue, 5 Nov 2002 10:29:21 -0800 (PST) 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 gA5IMpFT226638 for ; Tue, 5 Nov 2002 13:22:51 -0500 Received: from dyn9-47-18-86.beaverton.ibm.com (dyn9-47-18-86.beaverton.ibm.com [9.47.18.86]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA5IMlIN130838 for ; Tue, 5 Nov 2002 13:22:48 -0500 Date: Tue, 5 Nov 2002 10:25:19 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Subject: connect() on UDP-style sockets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a couple of questions on the behavior of connect() for udp-style sockets. 1. What should be the default behavior of a connect() on a udp-style sctp socket. Should it block until the association is established or return after sending an INIT with EINPROGRESS similar to a non-blocking socket? 2. What is the default behavior of an initial sendmsg() on a udp-style socket that was called without a prior connect() call causing an association to be setup implicitly. Should it block or return immediately? 3. Also i noticed that the sctp sockets api draft doesn't explicitly call for autobind on connect() for udp-style sockets if bind() was not called prior to connect(). Autobind is explicitly mentioned for sendmsg() on udp-style and connect() on tcp-style sockets. But there is no mention of autobind for connect() on udp-style sockets. Thanks Sridhar From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Nov 5 15:05:12 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 PAA09964 for ; Tue, 5 Nov 2002 15:05: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-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA5K3bgM017866 for ; Tue, 5 Nov 2002 12:03: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 gA5K3WmG021411 for ; Tue, 5 Nov 2002 12:03:32 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA5K1rS5021932 for ; Tue, 5 Nov 2002 12:01:54 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id CC6B74E8EC; Tue, 5 Nov 2002 11:51:48 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAAoxaavx; Tue Nov 5 11:51:41 2002 Subject: Same source ports for different associations To: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Tue, 5 Nov 2002 14:40:53 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 11/05/2002 11:57:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi List, Per RFC 2960 on Page 17, " Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs." Based on the above statement, if 2 associations of a SCTP endpoint use 1) same source port number & different destination port numbers; 2) same source & destination addresses, then the receiving SCTP endpoint will have problem to identify the association. Does it mean that same source port number is not allowed for different associations at a SCTP endpoint? Simon From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Nov 5 15:40:51 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 PAA12713 for ; Tue, 5 Nov 2002 15:40:50 -0500 (EST) 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 gA5Kd6ot006424 for ; Tue, 5 Nov 2002 12:39:06 -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 gA5Kd5kU013795 for ; Tue, 5 Nov 2002 12:39:05 -0800 (PST) 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 gA5KcuiX023064 for ; Tue, 5 Nov 2002 12:38:57 -0800 (PST) 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 gA5KKhB19343 for ; Tue, 5 Nov 2002 22:20:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 22:19:28 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 22:19:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 22:19:25 +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: Same source ports for different associations Date: Tue, 5 Nov 2002 22:19:24 +0200 Message-ID: Thread-Topic: Same source ports for different associations Thread-Index: AcKFB12MltmBHBe7QQ6cNO4TSPvcXQAAEEjw From: To: , X-OriginalArrivalTime: 05 Nov 2002 20:19:25.0529 (UTC) FILETIME=[A2AD3C90:01C28508] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12713 Hi Simon! > -----Original Message----- > From: ext Simon.Zhuang@radisys.com [mailto:Simon.Zhuang@radisys.com] > Sent: 05. November 2002 21:41 > To: sctp-impl@external.cisco.com > Subject: Same source ports for different associations > > > Hi List, > > Per RFC 2960 on Page 17, > > " Source Port Number: 16 bits (unsigned integer) > > This is the SCTP sender's port number. It can be used by the > receiver in combination with the source IP address, the SCTP > destination port and possibly the destination IP address to > identify the association to which this packet belongs." > > Based on the above statement, if 2 associations of a SCTP > endpoint use 1) > same source port number & different destination port numbers; 2) same > source & destination addresses, then the receiving SCTP > endpoint will have > problem to identify the association. I don't follow you... Why do you say that? Basically we are in the same situation than in TCP... As far as one of the four elements is different (either the source or the destination addresses, or ports) you identify the packet as belonging to one association or another... The only thing that I think could confuse you is that "... and possibly the...". If the peer is not multihomed, it doesn't have to look to the receiver address, since if it got the packet it means that it went to his address... This is why the receiver address is not always needed... I don't know if this is the reason why you have that doubt... > Does it mean that same source port number is not allowed for different > associations at a SCTP endpoint? This is not allowed only if the source port is the same, but also the destination port, source address and destination address... i.e., it is the same association... Otherwise, you don't have any problem to identify the association to which the packet belongs... I hope this helps! BR Iván Arias Rodríguez > Simon > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 5 15:48:01 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 PAA13289 for ; Tue, 5 Nov 2002 15:48:00 -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 gA5KkVPP018438 for ; Tue, 5 Nov 2002 12:46:31 -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 gA5KkUr8002427 for ; Tue, 5 Nov 2002 12:46:30 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA5KihS5023138 for ; Tue, 5 Nov 2002 12:44:44 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA5Ke5C3040030; Tue, 5 Nov 2002 15:40:05 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA5Ke4lI152672; Tue, 5 Nov 2002 13:40:05 -0700 Message-ID: <3DC82B8F.FE3683B4@us.ibm.com> Date: Tue, 05 Nov 2002 12:35:27 -0800 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon.Zhuang@radisys.com CC: sctp-impl@external.cisco.com Subject: Re: Same source ports for different associations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Simon.Zhuang@radisys.com wrote: > Per RFC 2960 on Page 17, > > " Source Port Number: 16 bits (unsigned integer) > > This is the SCTP sender's port number. It can be used by the > receiver in combination with the source IP address, the SCTP > destination port and possibly the destination IP address to > identify the association to which this packet belongs." > > Based on the above statement, if 2 associations of a SCTP endpoint use 1) > same source port number & different destination port numbers; 2) same > source & destination addresses, then the receiving SCTP endpoint will have > problem to identify the association. > > Does it mean that same source port number is not allowed for different > associations at a SCTP endpoint? I'm replying here to the list just to clarify my own very limited knowledge so far of SCTP. From what I understand, an association exists between 2 SCTP endpoints, and can span multiple addresses. So the src port # is the same, while multiple addresses (or a single wildcard address) can be specified for that association. i.e. A particular endpoint will use a particular port, and can have multiple transport addresses associated with it. You cannot have two different associations using the same port number. Can some SCTP person confirm that? thanks, Nivedita From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Nov 5 16:00:56 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 QAA14239 for ; Tue, 5 Nov 2002 16:00:55 -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 gA5Kw9xF018802 for ; Tue, 5 Nov 2002 12:58:09 -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 gA5Kw7ws006836 for ; Tue, 5 Nov 2002 12:58:08 -0800 (PST) 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 gA5Kw8iX003426 for ; Tue, 5 Nov 2002 12:58:09 -0800 (PST) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa04911; 5 Nov 2002 15:52 EST Date: Tue, 5 Nov 2002 15:52:38 -0500 (EST) From: Janardhan Iyengar To: Simon.Zhuang@radisys.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu cc: sctp-impl@external.cisco.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: Same source ports for different associations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Simon, > This is the SCTP sender's port number. It can be used by the > receiver in combination with the source IP address, the SCTP > destination port and possibly the destination IP address to > identify the association to which this packet belongs." > > Based on the above statement, if 2 associations of a SCTP endpoint use 1) > same source port number & different destination port numbers; 2) same > source & destination addresses, then the receiving SCTP endpoint will have > problem to identify the association. This is the standard 4-tuple {srcIP, srcPort, dstIP, dstPort} used to identify connections (in TCP) and associations (in SCTP). In the case you mention, the receiver can still identify the association to which the packet belongs due to the different destination port numbers. Hope that helps. cheers, jana ----------------------------------------------------------------------- Janardhan R. Iyengar iyengar@cis.udel.edu University of Delaware http://www.cis.udel.edu/~iyengar ----------------------------------------------------------------------- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 5 16:21: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 QAA15558 for ; Tue, 5 Nov 2002 16:21:44 -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 gA5LKoPP010866 for ; Tue, 5 Nov 2002 13:20: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 gA5LKo6P019989 for ; Tue, 5 Nov 2002 13:20:50 -0800 (PST) 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 gA5LKmL7007280 for ; Tue, 5 Nov 2002 13:20:49 -0800 (PST) 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 gA5LEKh36170; Tue, 5 Nov 2002 15:14:20 -0600 Sender: kavithab@tweets.austin.ibm.com Message-ID: <3DC834AC.5C52528E@austin.ibm.com> Date: Tue, 05 Nov 2002 15:14:20 -0600 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: Nivedita Singhvi , "sctp-impl@external.cisco.com" Subject: Re: Same source ports for different associations References: <3DC82B8F.FE3683B4@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Does it mean that same source port number is not allowed for different > > associations at a SCTP endpoint? > > I'm replying here to the list just to clarify my own very limited > knowledge so far of SCTP. From what I understand, an association > exists between 2 SCTP endpoints, and can span multiple addresses. > So the src port # is the same, while multiple addresses (or a single > wildcard address) can be specified for that association. > i.e. A particular endpoint will use a particular port, and can > have multiple transport addresses associated with it. You cannot > have two different associations using the same port number. > > Can some SCTP person confirm that? Multiple associations can use the same source IP address as well as port (as long as the 4-tuple is unique) In case of UDP-style assoc for example multiple associations use the same socket, which is bound to a specified port/ephemeral port (if not bound explicitly) . The incoming messages to the different associations using this socket can be identified based the foreign port and address combination (assuming that this is unique for two diff assocs) Thanks, Kavitha > thanks, > Nivedita -- 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 Tue Nov 5 16:41:04 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 QAA16749 for ; Tue, 5 Nov 2002 16:41:02 -0500 (EST) 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 gA5LdtgM010743 for ; Tue, 5 Nov 2002 13:39:55 -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 gA5Ldwo4006054 for ; Tue, 5 Nov 2002 13:39:58 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gA5LdvL7017682 for ; Tue, 5 Nov 2002 13:39:58 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id 4D47A4E90D; Tue, 5 Nov 2002 13:28:06 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAAfuaaS4; Tue Nov 5 13:28:00 2002 Subject: RE: Same source ports for different associations To: Cc: sctp-impl@external.cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Tue, 5 Nov 2002 16:17:12 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 11/05/2002 01:34:02 PM 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 QAA16749 Hi Ivan, Jana, Kavitha & Nivedita, Thanks for your quick replies. They are really helpful. Now it is clear to me that all 4 (src & dest ports and src & dest addresses) should/must be considered to indentify an association. Is it better to change "It can be used by ..." to a mandatory statement such as "it MUST be used by ..."? Simon To: , cc: 11/05/2002 03:19 PM Subject: RE: Same source ports for different associations Hi Simon! > -----Original Message----- > From: ext Simon.Zhuang@radisys.com [mailto:Simon.Zhuang@radisys.com] > Sent: 05. November 2002 21:41 > To: sctp-impl@external.cisco.com > Subject: Same source ports for different associations > > > Hi List, > > Per RFC 2960 on Page 17, > > " Source Port Number: 16 bits (unsigned integer) > > This is the SCTP sender's port number. It can be used by the > receiver in combination with the source IP address, the SCTP > destination port and possibly the destination IP address to > identify the association to which this packet belongs." > > Based on the above statement, if 2 associations of a SCTP > endpoint use 1) > same source port number & different destination port numbers; 2) same > source & destination addresses, then the receiving SCTP > endpoint will have > problem to identify the association. I don't follow you... Why do you say that? Basically we are in the same situation than in TCP... As far as one of the four elements is different (either the source or the destination addresses, or ports) you identify the packet as belonging to one association or another... The only thing that I think could confuse you is that "... and possibly the...". If the peer is not multihomed, it doesn't have to look to the receiver address, since if it got the packet it means that it went to his address... This is why the receiver address is not always needed... I don't know if this is the reason why you have that doubt... > Does it mean that same source port number is not allowed for different > associations at a SCTP endpoint? This is not allowed only if the source port is the same, but also the destination port, source address and destination address... i.e., it is the same association... Otherwise, you don't have any problem to identify the association to which the packet belongs... I hope this helps! BR Iván Arias Rodríguez > Simon > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 5 16:41:49 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 QAA16810 for ; Tue, 5 Nov 2002 16:41:48 -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 gA5LfUPP024099 for ; Tue, 5 Nov 2002 13:41:30 -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 gA5LfTkI019895 for ; Tue, 5 Nov 2002 13:41:29 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gA5LfSL7018385 for ; Tue, 5 Nov 2002 13:41:29 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA5LYvLI064578 for ; Tue, 5 Nov 2002 16:34:58 -0500 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA5LXZlI071152; Tue, 5 Nov 2002 14:33:35 -0700 Message-ID: <3DC8381A.240B08E7@us.ibm.com> Date: Tue, 05 Nov 2002 13:28:58 -0800 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sridhar Samudrala CC: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sridhar Samudrala wrote: > > I have a couple of questions on the behavior of connect() for udp-style sockets. > > 1. What should be the default behavior of a connect() on a udp-style sctp > socket. Should it block until the association is established or return after > sending an INIT with EINPROGRESS similar to a non-blocking socket? > > 2. What is the default behavior of an initial sendmsg() on a udp-style socket > that was called without a prior connect() call causing an association to be > setup implicitly. Should it block or return immediately? > > 3. Also i noticed that the sctp sockets api draft doesn't explicitly call for > autobind on connect() for udp-style sockets if bind() was not called prior to > connect(). Autobind is explicitly mentioned for sendmsg() on udp-style and > connect() on tcp-style sockets. But there is no mention of autobind for > connect() on udp-style sockets. For defining testcases for SCTP, I assumed that a connect on a udp socket that wasnt bound would autobind to an ephemeral port and wildcard address, similar to sendmsg() and other such situations, even though it wasnt mentioned in the SCTP API draft. If thats not the case, I'd also be interested in what error should be returned. thanks, Nivedita From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Nov 5 18:40:32 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 SAA25069 for ; Tue, 5 Nov 2002 18:40: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-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA5NdcgM015149 for ; Tue, 5 Nov 2002 15:39:38 -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 gA5NdX6S016837 for ; Tue, 5 Nov 2002 15:39:34 -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 gA5NbsS5017416 for ; Tue, 5 Nov 2002 15:37:55 -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 RAA28238 for ; Tue, 5 Nov 2002 17:24:58 -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 RAA50330 for ; Tue, 5 Nov 2002 17:33:09 -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 RAA24500 for ; Tue, 5 Nov 2002 17:33:08 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC84D31.7BD62BBB@us.ibm.com> Date: Tue, 05 Nov 2002 16:58:57 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: "sctp-impl@external.cisco.com" Subject: v4-mapped-v6 addresses with SCTP Sockets API. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Might as well dump out another I-D issue, so we can get them into the next I-D if needed: Concerning "v4-mapped-v6" addresses and SCTP Sockets Extensions: The latest drafts for the SCTP sockets extensions do not say anything to v4-mapped-v6 addresses. Previous drafts had said very little, except in the socket(PF_INET6) having some words of : "The syntax is, sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP); or, sd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP); Here, SOCK_SEQPACKET indicates the creation of a UDP-style socket. The first form creates an endpoint which can use only IPv4 addresses, while, the second form creates an endpoint which can use both IPv6 and IPv4 mapped addresses. " (Yes, I had to dig back a ways to find it, but I knew the words were there at one point in time). The words were changed from "IPV4 mapped addresses" to "IPv4 addresses". The IPV4-mapped address words have been changed (for some time), but I don't have the context for the change. Are v4-mapped-v6 address just an implied part of the API? Or does this imply the opposite, that they should not be supported for SCTP PF_INET6 applications? Note: I realize v4-mapped-v6 are completely disallowed within the SCTP protocol; my question is specifically on how to handle PF_INET6 clients at the API layer. As it is currently, stands my interpretation is: PF_INET sockets, AF_INET addresses: v4 addresses PF_INET6 sockets, AF_INET6 addresses: v6 or v4-mapped addresses My view is such as it preserves the presently expected behavior for PF_INET6 applications needing to interact with a v4 peers. This would include msg_name for recvmsg/sendmsg calls. However, there are new API issues with the SCTP extensions: For example, bindx() and various events use "struct sockaddr_storage". Should a PF_INET6 socket use AF_INET6 addresses exclusively, or should we allow either? Its easy enough to allow either as input to sockets, but how about for output (e.g. events)? Should we specify AF_INET6 only, or make the application expect either (AF_INET v4 address or AF_INET6 v4-mapped-v6 address). Yes, this is probably a very minor issue, but I'd like to get this nailed down for expectations by PF_INET6 application writers, so they don't tie themselves in early to any certain implementaion choice. Some options: 1) No v4-mapped-v6 addresses allowed! 2) PF_INET6 addresses exclusively use AF_INET6 address format (v4 addresses come in/out as v4-mapped-v6 only) 3) Specify some hybrid behavior in the I-D. Minimally, I'd expect to see what the application can expect on output. 3) Anything goes! Application is required to expect addressing format for V4 addresses in either format. Opinions? Best Regards, Jon Grimm From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Nov 5 18:41:57 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 SAA25131 for ; Tue, 5 Nov 2002 18:41:56 -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 gA5Nf0ot008121; Tue, 5 Nov 2002 15:41:00 -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 AAO81646; Tue, 5 Nov 2002 15:40:20 -0800 (PST) Message-ID: <3DC856E3.2090809@cisco.com> Date: Tue, 05 Nov 2002 17:40:19 -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: Nivedita Singhvi CC: Sridhar Samudrala , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC8381A.240B08E7@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nivedita Singhvi wrote: >Sridhar Samudrala wrote: > > >>I have a couple of questions on the behavior of connect() for udp-style sockets. >> >>1. What should be the default behavior of a connect() on a udp-style sctp >>socket. Should it block until the association is established or return after >>sending an INIT with EINPROGRESS similar to a non-blocking socket? >> I don't see why it would have to... but I would like to hear what others would say.. >> >> >>2. What is the default behavior of an initial sendmsg() on a udp-style socket >>that was called without a prior connect() call causing an association to be >>setup implicitly. Should it block or return immediately? >> Since udp style.. 1 to many if you will .. represent many assoc's it might be best not to block and start the setup with the data in queue... Same thing that would happen when you write to a socket() and there is space in the socket buffer.. you return with a number of bytes written.. even though it does not necessarily complete the write until after the data that may be ahead gets across.. >> >> >>3. Also i noticed that the sctp sockets api draft doesn't explicitly call for >>autobind on connect() for udp-style sockets if bind() was not called prior to >>connect(). Autobind is explicitly mentioned for sendmsg() on udp-style and >>connect() on tcp-style sockets. But there is no mention of autobind for >>connect() on udp-style sockets. >> >> > >For defining testcases for SCTP, I assumed that a connect on a udp socket >that wasnt bound would autobind to an ephemeral port and wildcard address, >similar to sendmsg() and other such situations, even though it wasnt >mentioned in the SCTP API draft. If thats not the case, I'd also be >interested in what error should be returned. > > Yes.. we missed adding the text on autobind.. this is what should happen.. >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 Nov 5 18:45:39 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 SAA25300 for ; Tue, 5 Nov 2002 18:45:37 -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 gA5NjFPP012432; Tue, 5 Nov 2002 15:45:15 -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 AAO81845; Tue, 5 Nov 2002 15:45:14 -0800 (PST) Message-ID: <3DC857FF.70407@cisco.com> Date: Tue, 05 Nov 2002 17:45:03 -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: Simon.Zhuang@radisys.com CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Same source ports for different associations References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit No I don't think any change is needed.. Consider the recevier that is bound to all addresses... and has port 2222 bound. When a packet arrives all it need to do is see port 2222 to establish that it was destined to this endpoint.. it does not need to look at the to address. It WILL need to look at the from address and from port.. to find the correct association. It is important not to put MUST's in unless we have a compatibility issue involved. We want to stay away from dictating how to implement things.. R Simon.Zhuang@radisys.com wrote: >Hi Ivan, Jana, Kavitha & Nivedita, > >Thanks for your quick replies. They are really helpful. > >Now it is clear to me that all 4 (src & dest ports and src & dest >addresses) should/must be considered to indentify an association. Is it >better to change "It can be used by ..." to a mandatory statement such as >"it MUST be used by ..."? > >Simon > > > > > @nokia.com> To: , > cc: > 11/05/2002 03:19 PM Subject: RE: Same source ports for different associations > > > > > > > Hi Simon! > > > >>-----Original Message----- >>From: ext Simon.Zhuang@radisys.com [mailto:Simon.Zhuang@radisys.com] >>Sent: 05. November 2002 21:41 >>To: sctp-impl@external.cisco.com >>Subject: Same source ports for different associations >> >> >>Hi List, >> >>Per RFC 2960 on Page 17, >> >> " Source Port Number: 16 bits (unsigned integer) >> >> This is the SCTP sender's port number. It can be used by the >> receiver in combination with the source IP address, the SCTP >> destination port and possibly the destination IP address to >> identify the association to which this packet belongs." >> >>Based on the above statement, if 2 associations of a SCTP >>endpoint use 1) >>same source port number & different destination port numbers; 2) same >>source & destination addresses, then the receiving SCTP >>endpoint will have >>problem to identify the association. >> >> > > I don't follow you... Why do you say that? Basically we are in >the same situation than in TCP... As far as one of the four elements is >different (either the source or the destination addresses, or ports) you >identify the packet as belonging to one association or another... > > The only thing that I think could confuse you is that "... and >possibly the...". If the peer is not multihomed, it doesn't have to look to >the receiver address, since if it got the packet it means that it went to >his address... This is why the receiver address is not always needed... I >don't know if this is the reason why you have that doubt... > > > >>Does it mean that same source port number is not allowed for different >>associations at a SCTP endpoint? >> >> > > This is not allowed only if the source port is the same, but >also the destination port, source address and destination address... i.e., >it is the same association... > > Otherwise, you don't have any problem to identify the >association to which the packet belongs... > > I hope this helps! > > BR Iván Arias Rodríguez > > > >>Simon >> >> >> >> > > > > > > > -- 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 Nov 5 20:00:27 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 UAA28749 for ; Tue, 5 Nov 2002 20:00:26 -0500 (EST) 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 gA60njot019221 for ; Tue, 5 Nov 2002 16:49:45 -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 gA60naBq005317 for ; Tue, 5 Nov 2002 16:49:36 -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 gA60lvS5022767 for ; Tue, 5 Nov 2002 16:47:57 -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 SAA05960; Tue, 5 Nov 2002 18:34: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 SAA52080; Tue, 5 Nov 2002 18:43:07 -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 SAA05098; Tue, 5 Nov 2002 18:43:06 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC85D94.8B9DEA12@us.ibm.com> Date: Tue, 05 Nov 2002 18:08:52 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Nivedita Singhvi , Sridhar Samudrala , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC8381A.240B08E7@us.ibm.com> <3DC856E3.2090809@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Randall Stewart (cisco)" wrote: > > Nivedita Singhvi wrote: > > >Sridhar Samudrala wrote: > > > > > >>I have a couple of questions on the behavior of connect() for udp-style sockets. > >> > >>1. What should be the default behavior of a connect() on a udp-style sctp > >>socket. Should it block until the association is established or return after > >>sending an INIT with EINPROGRESS similar to a non-blocking socket? > >> > I don't see why it would have to... but I would like to hear what others > would say.. > Per discussions of late, I'd expect non-blocking, but with no EINPROGRESS for UDP-style connect(). Events already provide association change information that is needed anyway. For this choice, one should also suppress EALREADY/EISCONN too As a second choice, I'd go with a blocking connect(), as I can see some application requirement towards blocking on connect. With this second choice, I guess its stil possible to convert into a non-blocking socket that returns EINPROGRESS/EALREADY/EISCONN or whatever flavor your OS of choice propogates up as an error code. OTOH, if you want this behavior, its likely that the TCP-style would have likely been a better choice of model anyway. Best Regards, Jon Grimm From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Nov 5 20:25:18 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 UAA29509 for ; Tue, 5 Nov 2002 20:25:17 -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 gA61OOxF018120 for ; Tue, 5 Nov 2002 17:24:24 -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 gA61ON5J027798 for ; Tue, 5 Nov 2002 17:24:23 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA61OOiX026352 for ; Tue, 5 Nov 2002 17:24:25 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA61I2C3022740; Tue, 5 Nov 2002 20:18:02 -0500 Received: from dyn9-47-18-86.beaverton.ibm.com (dyn9-47-18-86.beaverton.ibm.com [9.47.18.86]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA61I1lJ124364; Tue, 5 Nov 2002 18:18:01 -0700 Date: Tue, 5 Nov 2002 17:20:30 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Jon Grimm cc: "Randall Stewart (cisco)" , Nivedita Singhvi , Sridhar Samudrala , Subject: Re: connect() on UDP-style sockets In-Reply-To: <3DC85D94.8B9DEA12@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 5 Nov 2002, Jon Grimm wrote: > "Randall Stewart (cisco)" wrote: > > > > Nivedita Singhvi wrote: > > > > >Sridhar Samudrala wrote: > > > > > > > > >>I have a couple of questions on the behavior of connect() for udp-style sockets. > > >> > > >>1. What should be the default behavior of a connect() on a udp-style sctp > > >>socket. Should it block until the association is established or return after > > >>sending an INIT with EINPROGRESS similar to a non-blocking socket? > > >> > > I don't see why it would have to... but I would like to hear what others > > would say.. > > > > > Per discussions of late, I'd expect non-blocking, but with no > EINPROGRESS for UDP-style connect(). Events already provide association > change information that is needed anyway. For this choice, one should > also suppress EALREADY/EISCONN too Going by Randy's argument that a udp-style socket may represent multiple association's and it is best not to block, i too feel that non-blocking may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ EISCONN return values. These are not really error values in this situation, but do provide the application some information about the current status of the socket/association. For example, this information will be useful for an application that disables notifications. Regards Sridhar > > As a second choice, I'd go with a blocking connect(), as I can see some > application requirement towards blocking on connect. With this second > choice, I guess its stil possible to convert into a non-blocking socket > that returns EINPROGRESS/EALREADY/EISCONN or whatever flavor your OS of > choice propogates up as an error code. OTOH, if you want this behavior, > its likely that the TCP-style would have likely been a better choice of > model anyway. > > > Best Regards, > Jon Grimm > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Nov 5 20:48:38 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 UAA01308 for ; Tue, 5 Nov 2002 20:48:36 -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 gA61lQgM015335 for ; Tue, 5 Nov 2002 17:47:26 -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 gA61lMH7011467 for ; Tue, 5 Nov 2002 17:47:22 -0800 (PST) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gA61lTL7017093 for ; Tue, 5 Nov 2002 17:47:30 -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 TAA31548; Tue, 5 Nov 2002 19:32:46 -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 TAA41378; Tue, 5 Nov 2002 19:40:58 -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 TAA22290; Tue, 5 Nov 2002 19:40:57 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC86B1B.7287EC69@us.ibm.com> Date: Tue, 05 Nov 2002 19:06:35 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sridhar Samudrala CC: "Randall Stewart (cisco)" , Nivedita Singhvi , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sridhar Samudrala wrote: > > On Tue, 5 Nov 2002, Jon Grimm wrote: > > > "Randall Stewart (cisco)" wrote: > > > > > > Nivedita Singhvi wrote: > > > > > > >Sridhar Samudrala wrote: > > > > > > > > > > > >>I have a couple of questions on the behavior of connect() for udp-style sockets. > > > >> > > > >>1. What should be the default behavior of a connect() on a udp-style sctp > > > >>socket. Should it block until the association is established or return after > > > >>sending an INIT with EINPROGRESS similar to a non-blocking socket? > > > >> > > > I don't see why it would have to... but I would like to hear what others > > > would say.. > > > > > > > > > Per discussions of late, I'd expect non-blocking, but with no > > EINPROGRESS for UDP-style connect(). Events already provide association > > change information that is needed anyway. For this choice, one should > > also suppress EALREADY/EISCONN too > > Going by Randy's argument that a udp-style socket may represent multiple > association's and it is best not to block, i too feel that non-blocking > may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ > EISCONN return values. These are not really error values in this situation, > but do provide the application some information about the current status of > the socket/association. For example, this information will be useful for an > application that disables notifications. > Hi Sridhar, Well, I considered them for suppression since I could look at UDP-style on my typically strange reasoning process: 1) If I look at UDP-style as its the closest thing to my SOCK_DGRAM application. Consequently, I wouldn't expect any of those error codes nor blocking behavior 2) Instead, if I instead look at UDP-style as being an entirely new model, events are the real way of getting this type of association change information. If you are using UDP-style you really should (I'm using 'should' but in reality tell app writers 'must') use events/notifications. 3) Otherwise, just plain go use TCP-style. If you are doing connect(), its not likely you have multiple associations anyway. I don't consider it that hideous to have such behavior (non-block EINPROGRESS, etc..). I just couldn't figure out why one should need it on the above, and it didn't fit in with the feel of the rest ofthe UDP-style changes). Best Regards, jon > Regards > Sridhar > > > > > As a second choice, I'd go with a blocking connect(), as I can see some > > application requirement towards blocking on connect. With this second > > choice, I guess its stil possible to convert into a non-blocking socket > > that returns EINPROGRESS/EALREADY/EISCONN or whatever flavor your OS of > > choice propogates up as an error code. OTOH, if you want this behavior, > > its likely that the TCP-style would have likely been a better choice of > > model anyway. > > > > > > Best Regards, > > Jon Grimm > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 5 20:50:53 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 UAA01594 for ; Tue, 5 Nov 2002 20:50:52 -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 gA61oWPP018481 for ; Tue, 5 Nov 2002 17:50:32 -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 gA61oVIB029530 for ; Tue, 5 Nov 2002 17:50:31 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gA61oVL7018485 for ; Tue, 5 Nov 2002 17:50:32 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA61i1LI029316 for ; Tue, 5 Nov 2002 20:44:01 -0500 Received: from us.ibm.com (sig-9-65-3-50.mts.ibm.com [9.65.3.50]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA61hwlI162188; Tue, 5 Nov 2002 18:43:59 -0700 Message-ID: <3DC872C9.BA06A876@us.ibm.com> Date: Tue, 05 Nov 2002 17:39:21 -0800 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sridhar Samudrala CC: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sridhar Samudrala wrote: > > Per discussions of late, I'd expect non-blocking, but with no > > EINPROGRESS for UDP-style connect(). Events already provide association > > change information that is needed anyway. For this choice, one should > > also suppress EALREADY/EISCONN too > > Going by Randy's argument that a udp-style socket may represent multiple > association's and it is best not to block, i too feel that non-blocking > may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ > EISCONN return values. These are not really error values in this situation, > but do provide the application some information about the current status of > the socket/association. For example, this information will be useful for an > application that disables notifications. This may be a dumb question, but... If the connect() system call is going to fail [ return a -1 ], then I believe we must return the proper error value. i.e. tell the application EINPROGRESS or whatever. However, we dont want the application to attempt the connect() system call again or consider it a failure, isnt that correct? If we return success [0] (even if the connect hasnt completed), then how does the application learn the status of the connect? thanks, Nivedita From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Nov 5 21:47:34 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 VAA06269 for ; Tue, 5 Nov 2002 21:47:33 -0500 (EST) 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 gA62kMgM011678 for ; Tue, 5 Nov 2002 18:46:22 -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 gA62kQZI020290 for ; Tue, 5 Nov 2002 18:46:26 -0800 (PST) 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 gA62kJiX003050 for ; Tue, 5 Nov 2002 18:46:20 -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 UAA14364 for ; Tue, 5 Nov 2002 20:31:44 -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 UAA45872; Tue, 5 Nov 2002 20:39:56 -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 UAA21822; Tue, 5 Nov 2002 20:39:55 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC878ED.FB4F3DE8@us.ibm.com> Date: Tue, 05 Nov 2002 20:05:33 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nivedita Singhvi CC: Sridhar Samudrala , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC872C9.BA06A876@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nivedita Singhvi wrote: > > Sridhar Samudrala wrote: > > > > Per discussions of late, I'd expect non-blocking, but with no > > > EINPROGRESS for UDP-style connect(). Events already provide association > > > change information that is needed anyway. For this choice, one should > > > also suppress EALREADY/EISCONN too > > > > Going by Randy's argument that a udp-style socket may represent multiple > > association's and it is best not to block, i too feel that non-blocking > > may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ > > EISCONN return values. These are not really error values in this situation, > > but do provide the application some information about the current status of > > the socket/association. For example, this information will be useful for an > > application that disables notifications. > > This may be a dumb question, but... > > If the connect() system call is going to fail [ return a -1 ], then > I believe we must return the proper error value. i.e. tell the application > EINPROGRESS or whatever. However, we dont want the application to attempt the > connect() system call again or consider it a failure, isnt that correct? > Depends. UDP-style sockets already have a way to get this information.. connect() as an API was relatively recent add to the I-D. This information is already part of API. > If we return success [0] (even if the connect hasnt completed), then > how does the application learn the status of the connect? > UDP-style sockets have an alternative mechanism for reporting such information. ASSOC_CHANGE notifications report this an much more up through recvmsg(). So if I put on my UDP-style hat, which says its a new model, this is what I come up with.. Now... the connect() status may very well be interesting to app, but if so.. its also likely that a blocking connect was interesting too. Or that TCP-style is more appropriate anyway. However, I'm not fond of a blocking connect() anyway, since this defeat the ability to bundle data with the last part of the association setup, so you lose that as an SCTP feature. :-( Best Regards, jon > thanks, > Nivedita From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Nov 6 08:08:20 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 IAA16210 for ; Wed, 6 Nov 2002 08:08:18 -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 gA6D2ExF011548 for ; Wed, 6 Nov 2002 05:02:14 -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 gA6D2C1G005692 for ; Wed, 6 Nov 2002 05:02:12 -0800 (PST) Received: from enterprise.atl.lmco.com (mail.atl.external.lmco.com [192.35.37.50]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA6D29dQ002868 for ; Wed, 6 Nov 2002 05:02:13 -0800 (PST) Received: from misty.atl.lmco.com (misty [166.17.242.243]) by enterprise.atl.lmco.com (Postfix) with ESMTP id 658CEC1D04 for ; Wed, 6 Nov 2002 07:42:55 -0500 (EST) Received: (from cwinters@localhost) by misty.atl.lmco.com (8.11.2/8.11.2) id gA6Cgtc21363 for sctp-impl@external.cisco.com; Wed, 6 Nov 2002 07:42:55 -0500 Date: Wed, 6 Nov 2002 07:42:55 -0500 From: Chuck Winters To: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets Message-ID: <20021106074255.A21246@atl.lmco.com> Mail-Followup-To: sctp-impl@external.cisco.com References: <3DC86B1B.7287EC69@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: <3DC86B1B.7287EC69@us.ibm.com>; from jgrimm2@us.ibm.com on Tue, Nov 05, 2002 at 07:06:35PM -0600 On Tue, Nov 05, 2002 at 07:06:35PM -0600, Jon Grimm wrote: > Sridhar Samudrala wrote: > > > > On Tue, 5 Nov 2002, Jon Grimm wrote: > > > > > "Randall Stewart (cisco)" wrote: > > > > > > > > Nivedita Singhvi wrote: > > > > > > > > >Sridhar Samudrala wrote: > > > > > > > > > > > > > > >>I have a couple of questions on the behavior of connect() for udp-style sockets. > > > > >> > > > > >>1. What should be the default behavior of a connect() on a udp-style sctp > > > > >>socket. Should it block until the association is established or return after > > > > >>sending an INIT with EINPROGRESS similar to a non-blocking socket? > > > > >> > > > > I don't see why it would have to... but I would like to hear what others > > > > would say.. > > > > > > > > > > > > > Per discussions of late, I'd expect non-blocking, but with no > > > EINPROGRESS for UDP-style connect(). Events already provide association > > > change information that is needed anyway. For this choice, one should > > > also suppress EALREADY/EISCONN too > > > > Going by Randy's argument that a udp-style socket may represent multiple > > association's and it is best not to block, i too feel that non-blocking > > may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ > > EISCONN return values. These are not really error values in this situation, > > but do provide the application some information about the current status of > > the socket/association. For example, this information will be useful for an > > application that disables notifications. > > Stupid question, but is the default for the UDP style socket to be non-blocking, or do you have to set it to non-blocking after creation? I think you can preserve the semantics of connect() which I believe is that only when the socket is in non-blocking mode are these errors are returned. > > Hi Sridhar, > > Well, I considered them for suppression since I could look at UDP-style > on my typically strange reasoning process: > 1) If I look at UDP-style as its the closest thing to my SOCK_DGRAM > application. Consequently, I wouldn't expect any of those error codes > nor blocking behavior Now, if SCTP were not a connection oriented protocol, I would agree with the above statement. > 2) Instead, if I instead look at UDP-style as being an entirely new > model, events are the real way of getting this type of association > change information. If you are using UDP-style you really should (I'm > using 'should' but in reality tell app writers 'must') use > events/notifications. If the errors are not suppressed, then they give some information to the app. If you wanted more info, use the events produced by the stack. > 3) Otherwise, just plain go use TCP-style. If you are doing connect(), > its not likely you have multiple associations anyway. > > > I don't consider it that hideous to have such behavior (non-block > EINPROGRESS, etc..). I just couldn't figure out why one should need it > on the above, and it didn't fit in with the feel of the rest ofthe > UDP-style changes). > > Best Regards, > jon > > > Regards > > Sridhar > > > > > > > > As a second choice, I'd go with a blocking connect(), as I can see some > > > application requirement towards blocking on connect. With this second > > > choice, I guess its stil possible to convert into a non-blocking socket > > > that returns EINPROGRESS/EALREADY/EISCONN or whatever flavor your OS of > > > choice propogates up as an error code. OTOH, if you want this behavior, > > > its likely that the TCP-style would have likely been a better choice of > > > model anyway. > > > > > > > > > Best Regards, > > > Jon Grimm > > > Later, 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 Wed Nov 6 10:31:14 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 KAA26813 for ; Wed, 6 Nov 2002 10:31:13 -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 gA6FMuPP017770 for ; Wed, 6 Nov 2002 07:22:57 -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 gA6FMtnD021874 for ; Wed, 6 Nov 2002 07:22:56 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA6FL7S5023678 for ; Wed, 6 Nov 2002 07:21:08 -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 JAA28402; Wed, 6 Nov 2002 09:13:42 -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 JAA37850; Wed, 6 Nov 2002 09:11:13 -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 JAA28026; Wed, 6 Nov 2002 09:10:49 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DC928D6.9E9712CB@us.ibm.com> Date: Wed, 06 Nov 2002 08:36:06 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.45 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Winters CC: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC86B1B.7287EC69@us.ibm.com> <20021106074255.A21246@atl.lmco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Chuck, I'm clipping a bit since the response trail is getting a little long. I'll summarize by saying that I don't feel very strongly on this issue at all, though I do want the application writer to know what to expect by reading the I-D. As a secondary goal, the application writer should have a good chance of assuming semantics based on their previous experience with BSD Sockets. Chuck Winters wrote: > > > > > Stupid question, but is the default for the UDP style socket to be non-blocking, > or do you have to set it to non-blocking after creation? > I believe the are blocking. See section 3.3 of the I-D: excerpt: "Once all bind() calls are complete on a UDP-style socket, the application must set the non-blocking option by a fcntl() (such as O_NONBLOCK)." This at least implies blocking by default. > I think you can preserve the semantics of connect() which I believe is that only > when the socket is in non-blocking mode are these errors are returned. Ah... well this is more akin to my choice #2. Preserve the semantics of connect() entirely. > > As a second choice, I'd go with a blocking connect(), as I can see some > > > > application requirement towards blocking on connect. With this second > > > > choice, I guess its stil possible to convert into a non-blocking socket > > > > that returns EINPROGRESS/EALREADY/EISCONN or whatever flavor your OS of > > > > choice propogates up as an error code. OTOH, if you want this behavior, > > > > its likely that the TCP-style would have likely been a better choice of > > > > model anyway. > > 1) If I look at UDP-style as its the closest thing to my SOCK_DGRAM > > application. Consequently, I wouldn't expect any of those error codes > > nor blocking behavior > Now, if SCTP were not a connection oriented protocol, I would agree with the > above statement. Which is why I move on... ;-) Well, its probably also fair for me to respond that the whole "auto-connect" behavior of sendmsg hides the connection-oriented nature of the underlying protocol. IIRC, 'connect' has only been in the tsvwg sockets I-D since draft 3 or 4??? for UDP-style. I don't remember if it was in the sigtran drafts. > > 2) Instead, if I instead look at UDP-style as being an entirely new > > model, events are the real way of getting this type of association > > change information. If you are using UDP-style you really should (I'm > > using 'should' but in reality tell app writers 'must') use > > events/notifications. > If the errors are not suppressed, then they give some information to the app. > If you wanted more info, use the events produced by the stack. Yes, I think I'm convinced that this doesn't take away anything, though it is redundant information. You can get this same redundant information on TCP-style by enabling events.. so its there anyway. > > 3) Otherwise, just plain go use TCP-style. If you are doing connect(), > > its not likely you have multiple associations anyway. > > Hmmm... no one responses to this point. Thats no fun. Thats enough for me... I don't feel very strongly on any of these, except to have in the end rationale choice documented in the I-D. Best Regards and thanks, Jon Grimm | From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 6 11:00:45 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 LAA28929 for ; Wed, 6 Nov 2002 11:00:44 -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 gA6Fv5gM027534 for ; Wed, 6 Nov 2002 07:57: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 gA6Fv0LO024328 for ; Wed, 6 Nov 2002 07:57:01 -0800 (PST) Received: from irmgard.exp-math.uni-essen.de (irmgard.exp-math.uni-essen.de [132.252.150.18]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA6Fv1dQ002712 for ; Wed, 6 Nov 2002 07:57:03 -0800 (PST) Received: from biene.exp-math.uni-essen.de (biene.exp-math.uni-essen.de [132.252.150.215]) by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with ESMTP id gA6FoC5D040406 for ; Wed, 6 Nov 2002 16:50:12 +0100 Content-Type: text/plain; charset="us-ascii" From: Andreas Jungmaier Organization: University of Essen To: SCTP Discussion List Subject: RFC and Implementors Guide Date: Wed, 6 Nov 2002 17:50:26 +0100 User-Agent: KMail/1.4.2 MIME-Version: 1.0 Message-Id: <200211061750.28182.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA28929 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, is there any version/modification (be it text, nroff or whatever) of the original RFC 2960 document out there that contains the changes of the Implementors Guide inline ? Reading both documents at the same time makes me sort of sick, and I am sure that someone has already spent time merging these too documents....(Randy or Ivan maybe ?). Any help is greatly appreciated, Andreas - -- - --------------------------------------------------------------------------- Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! Computer Networking Technology Group | Send E-MAILS -- Use PGP ! University of Essen | http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net - --------------------------------------------------------------------------- My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9yUhSXAsLBNOCSsARAjXbAJ9k5UH4i3N0gFc8E6KYs6VuXflJaQCeISM9 nMFUmpWn4ZsbsfKIJe1lTT8= =bvwh -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 6 13:29:50 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 NAA05734 for ; Wed, 6 Nov 2002 13:29:49 -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 gA6IQbgM017194 for ; Wed, 6 Nov 2002 10:26: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 gA6IQWOm002151 for ; Wed, 6 Nov 2002 10:26:33 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA6IOqS5019124 for ; Wed, 6 Nov 2002 10:24:53 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA6IKAbM220684 for ; Wed, 6 Nov 2002 13:20:10 -0500 Received: from dyn9-47-18-86.beaverton.ibm.com (dyn9-47-18-86.beaverton.ibm.com [9.47.18.86]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA6IK85H178998; Wed, 6 Nov 2002 13:20:08 -0500 Date: Wed, 6 Nov 2002 10:22:38 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Jon Grimm cc: Subject: Re: connect() on UDP-style sockets In-Reply-To: <3DC928D6.9E9712CB@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Nov 2002, Jon Grimm wrote: > Hi Chuck, > I'm clipping a bit since the response trail is getting a little long. > I'll summarize by saying that I don't feel very strongly on this issue > at all, though I do want the application writer to know what to expect > by reading the I-D. As a secondary goal, the application writer should > have a good chance of assuming semantics based on their previous > experience with BSD Sockets. Jon, I agree entirely with your summary. We need to clearly define the behavior of udp-style connect() as either non-blocking or blocking. If we define the behavior as non-blocking, i feel that we should go with the semantics of a BSD socket that is explicitly set to non-blocking. But if we want to deviate from this semantics, we need to make that clear in the draft. > > > 3) Otherwise, just plain go use TCP-style. If you are doing connect(), > > > its not likely you have multiple associations anyway. > > > > > Hmmm... no one responses to this point. Thats no fun. OK. Let me respond. I don't think it is that unlikely to have multiple associations on a socket that does connect. For example, Richard Stevens Unix network programming Vol 1, in sec 15.5 talks of a web browser that can use multiple non-blocking connects to multiple web servers that are referenced on the same web page. In this scenario, SCTP can be used with a single socket having multiple shortlived associations that are initiated using connect(). If the default behavior of udp-style connect() is defined as non-blocking, the user need not even explicitly set the socket as non-blocking. Regards Sridhar > > > Thats enough for me... I don't feel very strongly on any of these, > except to have in the end rationale choice documented in the I-D. > > > Best Regards and thanks, > Jon Grimm > | > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Nov 6 13:47: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 NAA06480 for ; Wed, 6 Nov 2002 13:47:17 -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 gA6IaTPP020519 for ; Wed, 6 Nov 2002 10:36:29 -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 gA6IaR4Z026541 for ; Wed, 6 Nov 2002 10:36:27 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA6IYZS5026232 for ; Wed, 6 Nov 2002 10:34:35 -0800 (PST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA6IHd2S012783; Wed, 6 Nov 2002 11:17:39 -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 LAA20514; Wed, 6 Nov 2002 11:13:40 -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 gA6IDof26657; Wed, 6 Nov 2002 12:13:51 -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 MAA12988; Wed, 6 Nov 2002 12:15:04 -0600 (CST) Message-ID: <3DC95C22.D52B061F@Motorola.com> Date: Wed, 06 Nov 2002 12:14:58 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jungmaier CC: SCTP Discussion List Subject: Re: RFC and Implementors Guide References: <200211061750.28182.ajung@exp-math.uni-essen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andreas, The official merging of the two documents will not happy until SCTP is moved to Draft Standards by IESG. But this shouldn't prevent someone creating an unofficial merged doc. I'd like to know if there is such a doc. -Qiaobing Andreas Jungmaier wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > is there any version/modification (be it text, nroff or whatever) of the > original RFC 2960 document out there that contains the changes > of the Implementors Guide inline ? > > Reading both documents at the same time makes me sort of > sick, and I am sure that someone has already spent time > merging these too documents....(Randy or Ivan maybe ?). > > Any help is greatly appreciated, > > Andreas > - -- > - --------------------------------------------------------------------------- > Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! > Computer Networking Technology Group | Send E-MAILS -- Use PGP ! > University of Essen | > http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org > My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net > - --------------------------------------------------------------------------- > My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > - --------------------------------------------------------------------------- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9yUhSXAsLBNOCSsARAjXbAJ9k5UH4i3N0gFc8E6KYs6VuXflJaQCeISM9 > nMFUmpWn4ZsbsfKIJe1lTT8= > =bvwh > -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 6 14:04:14 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 OAA07223 for ; Wed, 6 Nov 2002 14:04:13 -0500 (EST) 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 gA6J1tgM007613 for ; Wed, 6 Nov 2002 11:01:55 -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 gA6J1wY2020696 for ; Wed, 6 Nov 2002 11:01:58 -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 gA6J09S5017200 for ; Wed, 6 Nov 2002 11:00:09 -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 MAA08008 for ; Wed, 6 Nov 2002 12:47:19 -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 MAA34046; Wed, 6 Nov 2002 12:55:31 -0600 Received: from us.ibm.com (grimm.austin.ibm.com [9.53.216.106]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id MAA27960; Wed, 6 Nov 2002 12:55:31 -0600 Message-ID: <3DC96426.3000103@us.ibm.com> Date: Wed, 06 Nov 2002 12:49:10 -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: Sridhar Samudrala CC: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sridhar Samudrala wrote: > On Wed, 6 Nov 2002, Jon Grimm wrote: > > >>Hi Chuck, >> I'm clipping a bit since the response trail is getting a little long. >>I'll summarize by saying that I don't feel very strongly on this issue >>at all, though I do want the application writer to know what to expect >>by reading the I-D. As a secondary goal, the application writer should >>have a good chance of assuming semantics based on their previous >>experience with BSD Sockets. > > > Jon, > > I agree entirely with your summary. We need to clearly define the behavior of > udp-style connect() as either non-blocking or blocking. If we define the > behavior as non-blocking, i feel that we should go with the semantics of > a BSD socket that is explicitly set to non-blocking. But if we want to > deviate from this semantics, we need to make that clear in the draft. > > >>>>3) Otherwise, just plain go use TCP-style. If you are doing connect(), >>>>its not likely you have multiple associations anyway. >>>> >>> >>Hmmm... no one responses to this point. Thats no fun. > > > OK. Let me respond. I don't think it is that unlikely to have multiple > associations on a socket that does connect. For example, Richard Stevens Unix > network programming Vol 1, in sec 15.5 talks of a web browser that can use > multiple non-blocking connects to multiple web servers that are referenced on > the same web page. In this scenario, SCTP can be used with a single socket > having multiple shortlived associations that are initiated using connect(). > If the default behavior of udp-style connect() is defined as non-blocking, > the user need not even explicitly set the socket as non-blocking. > > Regards > Sridhar > > >> >>Thats enough for me... I don't feel very strongly on any of these, >>except to have in the end rationale choice documented in the I-D. >> >> >>Best Regards and thanks, >>Jon Grimm >>| >> > > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Nov 6 14:25: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 OAA08153 for ; Wed, 6 Nov 2002 14:25:54 -0500 (EST) 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 gA6JOGot020690 for ; Wed, 6 Nov 2002 11:24:17 -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 gA6JOEWh012445 for ; Wed, 6 Nov 2002 11:24:15 -0800 (PST) Received: from irmgard.exp-math.uni-essen.de (irmgard.exp-math.uni-essen.de [132.252.150.18]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA6JO6dQ025389 for ; Wed, 6 Nov 2002 11:24:07 -0800 (PST) Received: from biene.exp-math.uni-essen.de (biene.exp-math.uni-essen.de [132.252.150.215]) by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with ESMTP id gA6JHn5D052110; Wed, 6 Nov 2002 20:17:49 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Andreas Jungmaier Organization: University of Essen To: Qiaobing Xie Subject: Re: RFC and Implementors Guide Date: Wed, 6 Nov 2002 22:17:48 +0100 User-Agent: KMail/1.4.2 Cc: SCTP Discussion List References: <200211061750.28182.ajung@exp-math.uni-essen.de> <3DC95C22.D52B061F@Motorola.com> In-Reply-To: <3DC95C22.D52B061F@Motorola.com> MIME-Version: 1.0 Message-Id: <200211062218.05278.ajung@exp-math.uni-essen.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08153 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Qiaobing, actually I was completely aware of that. I was just interested to know if there is someone out there that has a, let's call it, "working merger" of these documents. Problem is that you need the sources (nroff or xml) of both docs to create a sensible IETF style "merger" document. And I did not want to spend to much time reverse engineering these sources, if someone has already done it. Andreas On Wednesday 06 November 2002 19:14, Qiaobing Xie wrote: > Andreas, > > The official merging of the two documents will not happen until SCTP is > moved to Draft Standards by IESG. But this shouldn't prevent someone > creating an unofficial merged doc. I'd like to know if there is such a > doc. > > -Qiaobing - -- - --------------------------------------------------------------------------- Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! Computer Networking Technology Group | Send E-MAILS -- Use PGP ! University of Essen | http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net - --------------------------------------------------------------------------- My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 - --------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9yYcLXAsLBNOCSsARAr0xAKCJG+imPdBlwVyqEYYhxJ1SSFmJAACgocqQ /Zo9DqRz9BefCoYbumHfdbg= =9586 -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Nov 6 14:28: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 OAA08238 for ; Wed, 6 Nov 2002 14:28:32 -0500 (EST) 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 gA6JRWot022641 for ; Wed, 6 Nov 2002 11:27:32 -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 gA6JRVTO015529 for ; Wed, 6 Nov 2002 11:27:31 -0800 (PST) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gA6JRNdQ027234 for ; Wed, 6 Nov 2002 11:27:24 -0800 (PST) Received: by pop3.ss8.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 14:23:30 -0500 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69020A69CF@pop3.ss8.com> From: Serkan Cil To: "'Qiaobing Xie'" , Andreas Jungmaier Cc: SCTP Discussion List Subject: RE: RFC and Implementors Guide Date: Wed, 6 Nov 2002 14:23:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" I maintain a merged doc (2960 + imp guide 06) in MS Word format. Can forward to anybody who is interested. Serkan -----Original Message----- From: Qiaobing Xie [mailto:Qiaobing.Xie@Motorola.com] Sent: Wednesday, November 06, 2002 1:15 PM To: Andreas Jungmaier Cc: SCTP Discussion List Subject: Re: RFC and Implementors Guide Andreas, The official merging of the two documents will not happy until SCTP is moved to Draft Standards by IESG. But this shouldn't prevent someone creating an unofficial merged doc. I'd like to know if there is such a doc. -Qiaobing Andreas Jungmaier wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > is there any version/modification (be it text, nroff or whatever) of the > original RFC 2960 document out there that contains the changes > of the Implementors Guide inline ? > > Reading both documents at the same time makes me sort of > sick, and I am sure that someone has already spent time > merging these too documents....(Randy or Ivan maybe ?). > > Any help is greatly appreciated, > > Andreas > - -- > - --------------------------------------------------------------------------- > Dipl.-Ing. Andreas Jungmaier | Stop sending E-POSTCARDS ! > Computer Networking Technology Group | Send E-MAILS -- Use PGP ! > University of Essen | > http://www.exp-math.uni-essen.de/~ajung | http://www.gnupg.org > My PGP Key-ID: D3824AC0 | http://wwwkeys.pgp.net > - --------------------------------------------------------------------------- > My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4 9998 2812 5C0B 0B04 D382 4AC0 > - --------------------------------------------------------------------------- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE9yUhSXAsLBNOCSsARAjXbAJ9k5UH4i3N0gFc8E6KYs6VuXflJaQCeISM9 > nMFUmpWn4ZsbsfKIJe1lTT8= > =bvwh > -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 6 14:32: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 OAA08481 for ; Wed, 6 Nov 2002 14:32:45 -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 gA6JV3gM024272 for ; Wed, 6 Nov 2002 11:31:03 -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 gA6JUwZh000123 for ; Wed, 6 Nov 2002 11:30:58 -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 gA6JV2p1018353 for ; Wed, 6 Nov 2002 11:31:03 -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 NAA43038 for ; Wed, 6 Nov 2002 13:27:01 -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 NAA49324; Wed, 6 Nov 2002 13:24:35 -0600 Received: from us.ibm.com (grimm.austin.ibm.com [9.53.216.106]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id NAA05448; Wed, 6 Nov 2002 13:24:35 -0600 Message-ID: <3DC96AF6.2060104@us.ibm.com> Date: Wed, 06 Nov 2002 13:18:14 -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: Sridhar Samudrala CC: sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sridhar, Sorry for the previous accidental send. Sridhar Samudrala wrote: > On Wed, 6 Nov 2002, Jon Grimm wrote: > >>>>3) Otherwise, just plain go use TCP-style. If you are doing connect(), >>>>its not likely you have multiple associations anyway. > > OK. Let me respond. I don't think it is that unlikely to have multiple > associations on a socket that does connect. For example, Richard Stevens Unix > network programming Vol 1, in sec 15.5 talks of a web browser that can use > multiple non-blocking connects to multiple web servers that are referenced on > the same web page. In this scenario, SCTP can be used with a single socket > having multiple shortlived associations that are initiated using connect(). Good point! (though if I were 'exploiting' the UDP-style API I'd probably rewrite the example without connect at all using auto-connect.) > If the default behavior of udp-style connect() is defined as non-blocking, > the user need not even explicitly set the socket as non-blocking. > Agreed.. but if so, I'd like to see the entirety of the socket be in this state, as there is not a method to independantly change the state of connect vs I/O blocking behavior. If one is non-blocking the other should be too. The I-D today implies that the UDP-style socket is blocking by default. See section 3.3. of the I-D. IMO, if we change connect to non-blocking, this too should change. Thanks, jon > Regards > Sridhar From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Nov 6 19:03:17 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 TAA17678 for ; Wed, 6 Nov 2002 19:03:15 -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 gA6NrxxF011917; Wed, 6 Nov 2002 15:53: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 AAP17462; Wed, 6 Nov 2002 15:54:06 -0800 (PST) Message-ID: <3DC9AB9E.7060900@cisco.com> Date: Wed, 06 Nov 2002 17:54: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: Jon Grimm CC: Nivedita Singhvi , Sridhar Samudrala , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC872C9.BA06A876@us.ibm.com> <3DC878ED.FB4F3DE8@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon: I wonder if it would not be better to change the udp default to be NON-BLOCKING. And then leave the connect symantics to be strictly BSD like... This way you get a non-blocking connect (and everything else too) by default. Then if you really want a blocking connect you can do the fctl() thing (or whatever sets the flag in your socket) and change it to blocking and get the wonderus blocking behaviour... R Jon Grimm wrote: >Nivedita Singhvi wrote: > > >>Sridhar Samudrala wrote: >> >> >> >>>>Per discussions of late, I'd expect non-blocking, but with no >>>>EINPROGRESS for UDP-style connect(). Events already provide association >>>>change information that is needed anyway. For this choice, one should >>>>also suppress EALREADY/EISCONN too >>>> >>>> >>>Going by Randy's argument that a udp-style socket may represent multiple >>>association's and it is best not to block, i too feel that non-blocking >>>may be better. But i don't see why we need to supress EINPROGRESS/EALREADY/ >>>EISCONN return values. These are not really error values in this situation, >>>but do provide the application some information about the current status of >>>the socket/association. For example, this information will be useful for an >>>application that disables notifications. >>> >>> >>This may be a dumb question, but... >> >>If the connect() system call is going to fail [ return a -1 ], then >>I believe we must return the proper error value. i.e. tell the application >>EINPROGRESS or whatever. However, we dont want the application to attempt the >>connect() system call again or consider it a failure, isnt that correct? >> >> >> > >Depends. UDP-style sockets already have a way to get this information.. >connect() as an API was relatively recent add to the I-D. This >information is already part of API. > > > >>If we return success [0] (even if the connect hasnt completed), then >>how does the application learn the status of the connect? >> >> >> > >UDP-style sockets have an alternative mechanism for reporting such >information. ASSOC_CHANGE notifications report this an much more up >through recvmsg(). So if I put on my UDP-style hat, which says its a >new model, this is what I come up with.. > >Now... the connect() status may very well be interesting to app, but if >so.. its also likely that a blocking connect was interesting too. Or >that TCP-style is more appropriate anyway. However, I'm not fond of a >blocking connect() anyway, since this defeat the ability to bundle data >with the last part of the association setup, so you lose that as an SCTP >feature. :-( > > >Best Regards, >jon > > > >>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 Wed Nov 6 22:55: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 WAA22650 for ; Wed, 6 Nov 2002 22:55: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 gA73lcPP004028 for ; Wed, 6 Nov 2002 19:47:38 -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 gA73lbGX014781 for ; Wed, 6 Nov 2002 19:47:37 -0800 (PST) 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 gA73jlS5018728 for ; Wed, 6 Nov 2002 19:45:47 -0800 (PST) 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 gA73TJB04146 for ; Thu, 7 Nov 2002 05:29:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 7 Nov 2002 05:28:48 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 05:28:47 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 7 Nov 2002 11:28:41 +0800 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: subscribe Date: Thu, 7 Nov 2002 11:28:41 +0800 Message-ID: <8AE4923BB4DAF3448FBAA1F3261EF2B08CC688@beebe001.china.nokia.com> Thread-Topic: mailing list Thread-Index: AcKGDYO2aoM8rSRUT2qBvGBd1u1tcwAADkaw From: To: X-OriginalArrivalTime: 07 Nov 2002 03:28:41.0793 (UTC) FILETIME=[C504FB10:01C2860D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22650 subscribe From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Nov 7 09:23: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 JAA25499 for ; Thu, 7 Nov 2002 09:23:15 -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 gA7ELExF005788 for ; Thu, 7 Nov 2002 06:21:14 -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 gA7ELDnh027974 for ; Thu, 7 Nov 2002 06:21:13 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gA7EJWS5008509 for ; Thu, 7 Nov 2002 06:19:33 -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 IAA16680; Thu, 7 Nov 2002 08:17:18 -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 IAA64118; Thu, 7 Nov 2002 08:14:51 -0600 Received: from us.ibm.com (grimm.austin.ibm.com [9.53.216.106]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA29742; Thu, 7 Nov 2002 08:14:51 -0600 Message-ID: <3DCA73DD.3040608@us.ibm.com> Date: Thu, 07 Nov 2002 08:08:29 -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: "Randall Stewart (cisco)" CC: Nivedita Singhvi , Sridhar Samudrala , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <3DC872C9.BA06A876@us.ibm.com> <3DC878ED.FB4F3DE8@us.ibm.com> <3DC9AB9E.7060900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Works for me. Sridhar, how is that for you? I think we agreed that the below solution is what we'd implement in lksctp in the face of silence, anyway. ;-) Its easy enough for us to switch to a different default socket behavior. Best Regards, jon Randall Stewart (cisco) wrote: > Jon: > > I wonder if it would not be better to change the udp default > to be NON-BLOCKING. And then leave the connect > symantics to be strictly BSD like... This way you get > a non-blocking connect (and everything else too) by default. > > Then if you really want a blocking connect you can do the fctl() thing > (or whatever > sets the flag in your socket) and change it to blocking and get the > wonderus > blocking behaviour... > > R > > Jon Grimm wrote: > >> Nivedita Singhvi wrote: >> >> >>> Sridhar Samudrala wrote: >>> >>> >>> >>>>> Per discussions of late, I'd expect non-blocking, but with no >>>>> EINPROGRESS for UDP-style connect(). Events already provide >>>>> association >>>>> change information that is needed anyway. For this choice, one >>>>> should >>>>> also suppress EALREADY/EISCONN too >>>>> >>>> >>>> Going by Randy's argument that a udp-style socket may represent >>>> multiple >>>> association's and it is best not to block, i too feel that non-blocking >>>> may be better. But i don't see why we need to supress >>>> EINPROGRESS/EALREADY/ >>>> EISCONN return values. These are not really error values in this >>>> situation, >>>> but do provide the application some information about the current >>>> status of >>>> the socket/association. For example, this information will be useful >>>> for an >>>> application that disables notifications. >>>> >>> >>> This may be a dumb question, but... >>> >>> If the connect() system call is going to fail [ return a -1 ], then >>> I believe we must return the proper error value. i.e. tell the >>> application >>> EINPROGRESS or whatever. However, we dont want the application to >>> attempt the >>> connect() system call again or consider it a failure, isnt that correct? >>> >>> >> >> >> Depends. UDP-style sockets already have a way to get this information.. >> connect() as an API was relatively recent add to the I-D. This >> information is already part of API. >> >> >>> If we return success [0] (even if the connect hasnt completed), then >>> how does the application learn the status of the connect? >>> >>> >> >> >> UDP-style sockets have an alternative mechanism for reporting such >> information. ASSOC_CHANGE notifications report this an much more up >> through recvmsg(). So if I put on my UDP-style hat, which says its a >> new model, this is what I come up with.. >> Now... the connect() status may very well be interesting to app, but if >> so.. its also likely that a blocking connect was interesting too. Or >> that TCP-style is more appropriate anyway. However, I'm not fond of a >> blocking connect() anyway, since this defeat the ability to bundle data >> with the last part of the association setup, so you lose that as an SCTP >> feature. :-( >> >> Best Regards, >> jon >> >> >>> thanks, >>> Nivedita >>> >> >> >> >> > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Nov 7 13:03:42 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 NAA04536 for ; Thu, 7 Nov 2002 13:03:41 -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 gA7HwDgM016735 for ; Thu, 7 Nov 2002 09:58:16 -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 gA7Hw8wB004694 for ; Thu, 7 Nov 2002 09:58:08 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gA7Hvsp1013168 for ; Thu, 7 Nov 2002 09:58:01 -0800 (PST) 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 gA7Hp5sL306394; Thu, 7 Nov 2002 12:51:05 -0500 Received: from dyn9-47-18-86.beaverton.ibm.com (dyn9-47-18-86.beaverton.ibm.com [9.47.18.86]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA7Hp12d236584; Thu, 7 Nov 2002 12:51:02 -0500 Date: Thu, 7 Nov 2002 09:53:31 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: Jon Grimm cc: "Randall Stewart (cisco)" , Nivedita Singhvi , Sridhar Samudrala , Subject: Re: connect() on UDP-style sockets In-Reply-To: <3DCA73DD.3040608@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Nov 2002, Jon Grimm wrote: > Works for me. Sridhar, how is that for you? I think we agreed that > the below solution is what we'd implement in lksctp in the face of > silence, anyway. ;-) Its easy enough for us to switch to a different > default socket behavior. I think there is going to be an issue with implementation. By default, all the operations on a file/socket are supposed to be blocking. Using fcntl() we can change this behavior to be non-blocking by setting O_NONBLOCK. But i am not sure if there is a mechanism to change the behavior to blocking when by default we are doing non-blocking. If O_NONBLOCK is not set, we don't know if the user wants default behavior or blocking behavior? Do we really need to support blocking connect for udp-style sockets? If not, may be Jon's suggestion of returning success on connect() by default should work out. Default: ------- connect() return success after initiating the connection. Non-blocking enabled: -------------------- connect() returns -1 with EINPROGRESS after initiating the connection. I think we either need to go with the above behavior or by default do blocking connect. Thanks Sridhar > > Best Regards, > jon > > Randall Stewart (cisco) wrote: > > Jon: > > > > I wonder if it would not be better to change the udp default > > to be NON-BLOCKING. And then leave the connect > > symantics to be strictly BSD like... This way you get > > a non-blocking connect (and everything else too) by default. > > > > Then if you really want a blocking connect you can do the fctl() thing > > (or whatever > > sets the flag in your socket) and change it to blocking and get the > > wonderus > > blocking behaviour... > > > > R > > > > Jon Grimm wrote: > > > >> Nivedita Singhvi wrote: > >> > >> > >>> Sridhar Samudrala wrote: > >>> > >>> > >>> > >>>>> Per discussions of late, I'd expect non-blocking, but with no > >>>>> EINPROGRESS for UDP-style connect(). Events already provide > >>>>> association > >>>>> change information that is needed anyway. For this choice, one > >>>>> should > >>>>> also suppress EALREADY/EISCONN too > >>>>> > >>>> > >>>> Going by Randy's argument that a udp-style socket may represent > >>>> multiple > >>>> association's and it is best not to block, i too feel that non-blocking > >>>> may be better. But i don't see why we need to supress > >>>> EINPROGRESS/EALREADY/ > >>>> EISCONN return values. These are not really error values in this > >>>> situation, > >>>> but do provide the application some information about the current > >>>> status of > >>>> the socket/association. For example, this information will be useful > >>>> for an > >>>> application that disables notifications. > >>>> > >>> > >>> This may be a dumb question, but... > >>> > >>> If the connect() system call is going to fail [ return a -1 ], then > >>> I believe we must return the proper error value. i.e. tell the > >>> application > >>> EINPROGRESS or whatever. However, we dont want the application to > >>> attempt the > >>> connect() system call again or consider it a failure, isnt that correct? > >>> > >>> > >> > >> > >> Depends. UDP-style sockets already have a way to get this information.. > >> connect() as an API was relatively recent add to the I-D. This > >> information is already part of API. > >> > >> > >>> If we return success [0] (even if the connect hasnt completed), then > >>> how does the application learn the status of the connect? > >>> > >>> > >> > >> > >> UDP-style sockets have an alternative mechanism for reporting such > >> information. ASSOC_CHANGE notifications report this an much more up > >> through recvmsg(). So if I put on my UDP-style hat, which says its a > >> new model, this is what I come up with.. > >> Now... the connect() status may very well be interesting to app, but if > >> so.. its also likely that a blocking connect was interesting too. Or > >> that TCP-style is more appropriate anyway. However, I'm not fond of a > >> blocking connect() anyway, since this defeat the ability to bundle data > >> with the last part of the association setup, so you lose that as an SCTP > >> feature. :-( > >> > >> Best Regards, > >> jon > >> > >> > >>> thanks, > >>> Nivedita > >>> > >> > >> > >> > >> > > > > > > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Nov 7 17:15:21 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 RAA15471 for ; Thu, 7 Nov 2002 17:15:20 -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 gA7M8sgM008465 for ; Thu, 7 Nov 2002 14:08:54 -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 gA7M8w5k015784 for ; Thu, 7 Nov 2002 14:08:58 -0800 (PST) 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 gA7M8o80000570 for ; Thu, 7 Nov 2002 14:08:51 -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 PAA13946; Thu, 7 Nov 2002 15:54:08 -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 QAA37286; Thu, 7 Nov 2002 16:02:21 -0600 Received: from us.ibm.com (grimm.austin.ibm.com [9.53.216.106]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id QAA31466; Thu, 7 Nov 2002 16:02:21 -0600 Message-ID: <3DCAE16F.9010701@us.ibm.com> Date: Thu, 07 Nov 2002 15:55:59 -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: Sridhar Samudrala CC: "Randall Stewart (cisco)" , Nivedita Singhvi , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well this is certainly going around in circles. Yes, I see the layering issue that is there. We can't even get to those file flags at socket initialization to go whack them to NONBLOCK. :-( Yes, I could go for either of these. Though I think just sticking to blocking semantics throughout will cause the least application or implementation issues for all. 'connect' on a connection-oriented protocol has always had blocking semantics. Best Regards, Jon Sridhar Samudrala wrote: > On Thu, 7 Nov 2002, Jon Grimm wrote: > > > Do we really need to support blocking connect for udp-style sockets? If not, > may be Jon's suggestion of returning success on connect() by default should > work out. > > Default: > ------- > connect() return success after initiating the connection. > > Non-blocking enabled: > -------------------- > connect() returns -1 with EINPROGRESS after initiating the connection. > > > I think we either need to go with the above behavior or by default do blocking > connect. > > Thanks > Sridhar > > >>Best Regards, >>jon >> >>Randall Stewart (cisco) wrote: >> >>>Jon: >>> >>>I wonder if it would not be better to change the udp default >>>to be NON-BLOCKING. And then leave the connect >>>symantics to be strictly BSD like... This way you get >>>a non-blocking connect (and everything else too) by default. >>> >>>Then if you really want a blocking connect you can do the fctl() thing >>>(or whatever >>>sets the flag in your socket) and change it to blocking and get the >>>wonderus >>>blocking behaviour... >>> >>>R >>> >>>Jon Grimm wrote: >>> >>> >>>>Nivedita Singhvi wrote: >>>> >>>> >>>> >>>>>Sridhar Samudrala wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>>Per discussions of late, I'd expect non-blocking, but with no >>>>>>>EINPROGRESS for UDP-style connect(). Events already provide >>>>>>>association >>>>>>>change information that is needed anyway. For this choice, one >>>>>>>should >>>>>>>also suppress EALREADY/EISCONN too >>>>>>> >>>>>> >>>>>>Going by Randy's argument that a udp-style socket may represent >>>>>>multiple >>>>>>association's and it is best not to block, i too feel that non-blocking >>>>>>may be better. But i don't see why we need to supress >>>>>>EINPROGRESS/EALREADY/ >>>>>>EISCONN return values. These are not really error values in this >>>>>>situation, >>>>>>but do provide the application some information about the current >>>>>>status of >>>>>>the socket/association. For example, this information will be useful >>>>>>for an >>>>>>application that disables notifications. >>>>>> >>>>> >>>>>This may be a dumb question, but... >>>>> >>>>>If the connect() system call is going to fail [ return a -1 ], then >>>>>I believe we must return the proper error value. i.e. tell the >>>>>application >>>>>EINPROGRESS or whatever. However, we dont want the application to >>>>>attempt the >>>>>connect() system call again or consider it a failure, isnt that correct? >>>>> >>>>> >>>> >>>> >>>>Depends. UDP-style sockets already have a way to get this information.. >>>>connect() as an API was relatively recent add to the I-D. This >>>>information is already part of API. >>>> >>>> >>>> >>>>>If we return success [0] (even if the connect hasnt completed), then >>>>>how does the application learn the status of the connect? >>>>> >>>>> >>>> >>>> >>>>UDP-style sockets have an alternative mechanism for reporting such >>>>information. ASSOC_CHANGE notifications report this an much more up >>>>through recvmsg(). So if I put on my UDP-style hat, which says its a >>>>new model, this is what I come up with.. >>>>Now... the connect() status may very well be interesting to app, but if >>>>so.. its also likely that a blocking connect was interesting too. Or >>>>that TCP-style is more appropriate anyway. However, I'm not fond of a >>>>blocking connect() anyway, since this defeat the ability to bundle data >>>>with the last part of the association setup, so you lose that as an SCTP >>>>feature. :-( >>>> >>>>Best Regards, >>>>jon >>>> >>>> >>>> >>>>>thanks, >>>>>Nivedita >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Fri Nov 8 07:59: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 HAA17385 for ; Fri, 8 Nov 2002 07:59:45 -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 gA8CtSgM013426 for ; Fri, 8 Nov 2002 04:55:28 -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 gA8CtW5K025178 for ; Fri, 8 Nov 2002 04:55:32 -0800 (PST) Received: from webmail6.rediffmail.com (webmail6.rediffmail.com [202.54.124.151] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id gA8CrfS5002546 for ; Fri, 8 Nov 2002 04:53:42 -0800 (PST) Received: (qmail 2429 invoked by uid 510); 8 Nov 2002 12:52:30 -0000 Date: 8 Nov 2002 12:52:30 -0000 Message-ID: <20021108125230.2428.qmail@webmail6.rediffmail.com> Received: from unknown (202.141.70.200) by rediffmail.com via HTTP; 08 Nov 2002 12:52:30 -0000 MIME-Version: 1.0 From: "Garima gupta" Reply-To: "Garima gupta" To: sctp-impl@external.cisco.com Subject: multihoming Content-type: text/plain; format=flowed Content-Disposition: inline hi all, I was wondering if there is any codes that implemented multihoming. With best regards. Garima __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sun Nov 10 04:57:57 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 EAA13897 for ; Sun, 10 Nov 2002 04:57:56 -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 gAA9tmaE011913 for ; Sun, 10 Nov 2002 01:55:48 -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 gAA9tlU4001221 for ; Sun, 10 Nov 2002 01:55:47 -0800 (PST) Received: from web41003.mail.yahoo.com (web41003.mail.yahoo.com [66.218.93.2]) by proxy3.cisco.com (8.12.2/8.11.2) with SMTP id gAA9tvp1005758 for ; Sun, 10 Nov 2002 01:55:57 -0800 (PST) Message-ID: <20021110095237.89453.qmail@web41003.mail.yahoo.com> Received: from [67.98.234.234] by web41003.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 01:52:37 PST Date: Sun, 10 Nov 2002 01:52:37 -0800 (PST) From: "K. Poon" Subject: Re: connect() on UDP-style sockets To: Jon Grimm , Sridhar Samudrala Cc: "Randall Stewart \(cisco\)" , Nivedita Singhvi , sctp-impl@external.cisco.com In-Reply-To: <3DC86B1B.7287EC69@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Jon Grimm wrote: > Well, I considered them for suppression since I could look at > UDP-style > on my typically strange reasoning process: > 1) If I look at UDP-style as its the closest thing to my SOCK_DGRAM > application. Consequently, I wouldn't expect any of those error > codes > nor blocking behavior I don't think people should treat SCTP UDP-style socket mapping as modeling after real UDP socket. It is more like a new style of socket programming. But it has its root in real UDP socket. I believe this has been brought up before. So I think it is OK to return an error if the socket is set to non-blocking, as it should be blocking by default. > 2) Instead, if I instead look at UDP-style as being an entirely new > model, events are the real way of getting this type of association > change information. If you are using UDP-style you really should > (I'm > using 'should' but in reality tell app writers 'must') use > events/notifications. If I remember correctly, the reason why connect() was added to the UDP-style socket mapping was simply that it works for real UDP socket, so it should also work for SCTP UDP-style socket. There is actually a very interesting consequence if an app chooses to use this with SCTP UDP-style socket. For real UDP socket, the semantics of connect() is to set the remote address (IP addr + port) so that send() will work. It is used to simplify app programming if the app knows that the UDP socket will only be used to talk to a fixed peer for a period of time. Now when this semantics is applied to SCTP UDP-style socket, it means that ALL accociations controlled by this socket will go to the same remote address (IP addr + port). This effectively changes the UDP-style socket to a TCP-style socket, as it does not make sense to have more than one association going to the same remote address, from the same local address. So the effect of connect() is more than just initiating an association. But from a porting (real UDP socket to SCTP UDP-style socket) point of view, this makes sense as this is how app uses connect() on a real UDP socket. I believe this should be clarified in the draft. And the behavior on subsequent connect() should be specified. It should be somethinkg like shutting down the previous association and initiating a new association to a different remote address. I think the authors should discuss this and update the draft accordingly. > 3) Otherwise, just plain go use TCP-style. If you are doing > connect(), > its not likely you have multiple associations anyway. Yes. > I don't consider it that hideous to have such behavior (non-block > EINPROGRESS, etc..). I just couldn't figure out why one should need > it > on the above, and it didn't fit in with the feel of the rest ofthe > UDP-style changes). I believe connect() on UDP-style socket should be blocking by default. And it should probably be used only for "straight" porting of apps. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Sun Nov 10 05:07: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 FAA13970 for ; Sun, 10 Nov 2002 05:07: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-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAAA62Ni003631 for ; Sun, 10 Nov 2002 02:06:02 -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 gAAA5qbY003708 for ; Sun, 10 Nov 2002 02:05:53 -0800 (PST) Received: from web41008.mail.yahoo.com (web41008.mail.yahoo.com [66.218.93.7]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id gAAA4AS5009908 for ; Sun, 10 Nov 2002 02:04:10 -0800 (PST) Message-ID: <20021110100154.95173.qmail@web41008.mail.yahoo.com> Received: from [67.98.234.234] by web41008.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 02:01:54 PST Date: Sun, 10 Nov 2002 02:01:54 -0800 (PST) From: "K. Poon" Subject: Re: connect() on UDP-style sockets To: Sridhar Samudrala , Jon Grimm Cc: sctp-impl@external.cisco.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Sridhar Samudrala wrote: > OK. Let me respond. I don't think it is that unlikely to have > multiple > associations on a socket that does connect. For example, Richard > Stevens Unix > network programming Vol 1, in sec 15.5 talks of a web browser that > can use > multiple non-blocking connects to multiple web servers that are > referenced on > the same web page. In this scenario, SCTP can be used with a single > socket > having multiple shortlived associations that are initiated using > connect(). > If the default behavior of udp-style connect() is defined as > non-blocking, > the user need not even explicitly set the socket as non-blocking. I don't have that book handy, so I am inferring the following here... I believe the "correct" porting of the book's example using both UDP-style socket and connect() is to setup one association with several streams, instead of setting up multiple associations. And this will work with the connect() behavior I mentioned in an earlier mail. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sun Nov 10 05:23: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 FAA14086 for ; Sun, 10 Nov 2002 05:23:16 -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 gAAAMMIX021080 for ; Sun, 10 Nov 2002 02:22:22 -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 gAAAMHci014901 for ; Sun, 10 Nov 2002 02:22:17 -0800 (PST) Received: from web41002.mail.yahoo.com (web41002.mail.yahoo.com [66.218.93.1]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id gAAAKPS5013176 for ; Sun, 10 Nov 2002 02:20:26 -0800 (PST) Message-ID: <20021110101740.14477.qmail@web41002.mail.yahoo.com> Received: from [67.98.234.234] by web41002.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 02:17:40 PST Date: Sun, 10 Nov 2002 02:17:40 -0800 (PST) From: "K. Poon" Subject: Re: Preprocessor constants indicated SCTP is available? To: La Monte Henry Piggy Yarroll , Tuexen Michael Cc: "'Randall Stewart \(cisco\)'" , Craig Rodrigues , sctp-impl@external.cisco.com In-Reply-To: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- 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. I believe using a name with POSIX is a bad idea. This is IETF, I suggest we stay away from using names "belonging" to other organization. I believe going thru committees on names is the last thing people want to here. And I see no technical reason why this is a good choice at all. > 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), I think the decision on which constants to put in the draft should be based on whether it is really necessary. For example, I don't see why an app needs to know about whether a particular stack's SCTP implementation supports ECN or not. It seems to me that most of the above constant suggestions should not be defined based on this criterion. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Nov 11 12:57:55 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 MAA26050 for ; Mon, 11 Nov 2002 12:57:54 -0500 (EST) 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 gABHmWep018688 for ; Mon, 11 Nov 2002 09:48:32 -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 gABHmaJX014364 for ; Mon, 11 Nov 2002 09:48:37 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gABHmTUJ001415 for ; Mon, 11 Nov 2002 09:48:30 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABHg6Mr035220; Mon, 11 Nov 2002 12:42:06 -0500 Received: from dyn9-47-18-86.beaverton.ibm.com (dyn9-47-18-86.beaverton.ibm.com [9.47.18.86]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABHemMT190294; Mon, 11 Nov 2002 10:40:49 -0700 Date: Mon, 11 Nov 2002 09:43:11 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: "K. Poon" cc: Jon Grimm , Subject: Re: connect() on UDP-style sockets In-Reply-To: <20021110100154.95173.qmail@web41008.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Nov 2002, K. Poon wrote: > > --- Sridhar Samudrala wrote: > > OK. Let me respond. I don't think it is that unlikely to have > > multiple > > associations on a socket that does connect. For example, Richard > > Stevens Unix > > network programming Vol 1, in sec 15.5 talks of a web browser that > > can use > > multiple non-blocking connects to multiple web servers that are > > referenced on > > the same web page. In this scenario, SCTP can be used with a single > > socket > > having multiple shortlived associations that are initiated using > > connect(). > > If the default behavior of udp-style connect() is defined as > > non-blocking, > > the user need not even explicitly set the socket as non-blocking. > > I don't have that book handy, so I am inferring the following > here... I believe the "correct" porting of the book's example > using both UDP-style socket and connect() is to setup one > association with several streams, instead of setting up > multiple associations. And this will work with the connect() > behavior I mentioned in an earlier mail. Maybe the above description was not clear. The example in the book refers to a webpage containing links to multiple webservers(for ex. the images on the same page may be located at different websites). So i guess a single association with several streams will not work out. There needs to be multiple associations for this case. Although if we are using udp-style sockets in this scenario, as Jon mentioned, using sendmsg() with auto connect behavior may be a better choice. Thanks Sridhar From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Nov 11 13:12: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 NAA26487 for ; Mon, 11 Nov 2002 13:12:49 -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 gABI9nIX015066 for ; Mon, 11 Nov 2002 10:09:49 -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 gABI9nLi007625 for ; Mon, 11 Nov 2002 10:09:49 -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 gABI7rS5015623 for ; Mon, 11 Nov 2002 10:07:54 -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 LAA33648; Mon, 11 Nov 2002 11:55:02 -0600 Received: from austin.ibm.com (chintu.austin.ibm.com [9.41.86.45]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA49894; Mon, 11 Nov 2002 12:03:18 -0600 Sender: venkats@austin.ibm.com Message-ID: <3DCFF0E5.51E564EF@austin.ibm.com> Date: Mon, 11 Nov 2002 12:03:17 -0600 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: "K. Poon" CC: Jon Grimm , Sridhar Samudrala , "Randall Stewart (cisco)" , Nivedita Singhvi , sctp-impl@external.cisco.com Subject: Re: connect() on UDP-style sockets References: <20021110095237.89453.qmail@web41003.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "K. Poon" wrote: > I believe connect() on UDP-style socket should be blocking by > default. And it should probably be used only for "straight" > porting of apps. I also feel the default should be blocking. It was much simpler to code a typical client application not having to handle connect() error return codes (since the protocol is connection oriented). > > > ===== > K. Poon. kcpoon@yahoo.com > > __________________________________________________ > Do you Yahoo!? > U2 on LAUNCH - Exclusive greatest hits videos > http://launch.yahoo.com/u2 Venkat From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Nov 11 15:39:27 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 PAA00722 for ; Mon, 11 Nov 2002 15:39:26 -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 gABKaiNi022175 for ; Mon, 11 Nov 2002 12:36:44 -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 gABKahC0020250 for ; Mon, 11 Nov 2002 12:36:43 -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 gABKaWj5028271 for ; Mon, 11 Nov 2002 12:36:43 -0800 (PST) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id gABKWYj32660; Mon, 11 Nov 2002 15:32:34 -0500 Date: Mon, 11 Nov 2002 15:32:34 -0500 From: Craig Rodrigues To: "K. Poon" Cc: sctp-impl@external.cisco.com Subject: Re: Preprocessor constants indicated SCTP is available? Message-ID: <20021111153234.A32655@bbn.com> References: <200210311425.g9VEPbv05584@baqaqi.chi.il.us> <20021110101740.14477.qmail@web41002.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021110101740.14477.qmail@web41002.mail.yahoo.com>; from kcpoon@yahoo.com on Sun, Nov 10, 2002 at 02:17:40AM -0800 On Sun, Nov 10, 2002 at 02:17:40AM -0800, K. Poon wrote: > > --- 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. > > I believe using a name with POSIX is a bad idea. This is I agree. I recommend using just _SCTP_? Standardizing a few key macros would be very useful for app developers, and make it easier to add SCTP to existing codebases. Here is some advice I received from the Andrew Josey at the Open Group. On Mon, Nov 04, 2002 at 12:20:03PM +0000, Andrew Josey wrote: > Craig > Thanks for your mail. > > We would recommend that you use SCTP_* names in whatever headers > you want to use and require that applications define a feature test macro > (something like SCTP_C_SOURCE=200ymmL) similar to our use of > _POSIX_C_SOURCE to make any extensions to C and POSIX visible when > using any headers specified by POSIX. If at some later date a revision > of POSIX incorporates the SCTP stuff, POSIX can at that point adopt the > SCTP names into the namespace made visible in that POSIX revision. > > > best regards > Andrew > > > ----- > Andrew Josey The Open Group > Austin Group Chair Apex Plaza,Forbury Road, > Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England > Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 -- 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 Tue Nov 12 04:18: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 EAA25834 for ; Tue, 12 Nov 2002 04:18:23 -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 gAC937aE024251 for ; Tue, 12 Nov 2002 01:03:07 -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 gAC937BD020367 for ; Tue, 12 Nov 2002 01:03:07 -0800 (PST) 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 gAC93Fj5004427 for ; Tue, 12 Nov 2002 01:03:16 -0800 (PST) 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 gAC8huO03729 for ; Tue, 12 Nov 2002 10:43:56 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Nov 2002 10:44:25 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 10:44:24 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 12 Nov 2002 16:41:07 +0800 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: domain name query in kernel Date: Tue, 12 Nov 2002 16:41:07 +0800 Message-ID: <8AE4923BB4DAF3448FBAA1F3261EF2B005C935@beebe001.china.nokia.com> Thread-Topic: domain name query in kernel Thread-Index: AcKKJ0FImd4uIeWFQi6WoNF3s5errw== From: To: X-OriginalArrivalTime: 12 Nov 2002 08:41:07.0440 (UTC) FILETIME=[3E5C7700:01C28A27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA25834 hi, is there any function call which can get host+domain name from IPv4 / IPv6 address? from kernel level. thanks. zhao kai From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 12 08:25: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 IAA29853 for ; Tue, 12 Nov 2002 08:25:37 -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 gACDHtIX003232 for ; Tue, 12 Nov 2002 05:17:56 -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 gACDHjaX017502 for ; Tue, 12 Nov 2002 05:17:45 -0800 (PST) Received: from hotmail.com (oe25.law10.hotmail.com [64.4.14.82]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gACDHlWL004579 for ; Tue, 12 Nov 2002 05:17:48 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Nov 2002 05:15:51 -0800 X-Originating-IP: [202.134.200.4] From: "Manish Rajpal" To: Date: Tue, 12 Nov 2002 18:40:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 12 Nov 2002 13:15:51.0481 (UTC) FILETIME=[9F9D8290:01C28A4D] Content-Transfer-Encoding: 7bit subscribe sctp-impl From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Nov 13 11: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 LAA07348 for ; Wed, 13 Nov 2002 11:33:15 -0500 (EST) 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 gADGNuNi018322 for ; Wed, 13 Nov 2002 08:23:56 -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 gADGNtY8010518 for ; Wed, 13 Nov 2002 08:23:55 -0800 (PST) Received: from chinapolyglot.com ([202.106.155.97]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gADGNfWL021855 for ; Wed, 13 Nov 2002 08:23:45 -0800 (PST) Received: from DellXP [210.21.107.131] by chinapolyglot.com with ESMTP (SMTPD32-7.06) id ABB6BA8015C; Thu, 14 Nov 2002 00:20:09 +0800 Message-ID: <418-2200211313162249758@DellXP> Organization: Polyglot Ltd From: "Polyglot" To: sctp-impl@external.cisco.com Subject: Polyglot Translation Date: Thu, 14 Nov 2002 00:22:49 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=utf-7 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07348 Polyglot Translation Polyglot is a professional multilingual solutions provider. Our rich experience and professional team established us as a leader in the field of multilingual solutions. Polyglot can provide fast and accurate translations of financial, legal and technical documents on over 30 languages, such as English, German, Spanish, French, Italian, Chinese, Japanese, Korean, etc. We also provide software localization, website localization, simultaneous and consecutive interpretation for international meetings. For further information, please visit our website: http://www.polyglot.com.cn Contact us at: E-mail: info+AEA-polyglot.com.cn Tel: +-86 20 8657-3608 Fax: +-86 20 8657-3965 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: +T916y0/hf/uL0VFsU/g- +T916y0/hf/uL0VFsU/hmL04AW7Zj0E+bWRp5zYvtigCJ41GzZbloSHaEThNOGmc6Z4QwAk4wW8x2hH7PmoxTyg- +ThNOGnaElh9PDXhuestOhmIRTuxXKFkaec2L7YoAieNRs2W5aEiYhlffdoSYhlFIVzBPTTAC- +YhFO7ID9Y9BPmw-30+WRp5zYvtigB2hFHGeG4wAV/rY3d2hH/7i9FnDVKh/wx/+4vRmIZX322JU8qR0YeNZYdO9jAB- +bNVfi2WHTvZTymKAZy9lh072/wx/+4vRi+15zVMFYuz/GoLxMAFftzABiX8wAWzVMAFhDzABTi0wAWXlMAGX6XtJe0kwAg- +a2RZFv8MYhFO7I/YY9BPm49vTvZnLFcwUxYwAX9RetlnLFcwUxYwAVb9lkVPGouudoRUDFjwTyCL0VSMTqRm/08gi9EwAg- +UXNOjovmYMX/DIv3i7+V7mIRTux2hH9RV0D/Gg- http://www.polyglot.com.cn +gFR8+2W5Xw//Gg- +dTWQrg-: info+AEA-polyglot.com.cn +dTWL3Q-: (86-20) 8657 3608 +TyB3Hw-: (86-20) 8657 3965 +VzBXQP8aTi1W/V5/Xd5nOlc6je8-33+U/c- +Ti1ZLpFSXpdRmVtXaXw-968 +kK5/Fv8a-510403 From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Nov 13 15:03:18 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 PAA15389 for ; Wed, 13 Nov 2002 15:03:17 -0500 (EST) 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 gADJx9Ni002289 for ; Wed, 13 Nov 2002 11:59:09 -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 gADJwxSA016276 for ; Wed, 13 Nov 2002 11:58:59 -0800 (PST) Received: from webmail30.rediffmail.com (webmail30.rediffmail.com [202.54.124.145] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id gADJx5vg011578 for ; Wed, 13 Nov 2002 11:59:06 -0800 (PST) Received: (qmail 10151 invoked by uid 510); 13 Nov 2002 19:47:39 -0000 Date: 13 Nov 2002 19:47:39 -0000 Message-ID: <20021113194739.10150.qmail@webmail30.rediffmail.com> Received: from unknown (202.141.69.185) by rediffmail.com via HTTP; 13 nov 2002 19:47:39 -0000 MIME-Version: 1.0 From: "Abha Singh Bais" Reply-To: "Abha Singh Bais" To: sctp-impl@external.cisco.com Subject: FTP over SCTP Content-type: text/plain; format=flowed Content-Disposition: inline hi During our simulations for ftp over sctp in ns. We tried using "ftp produce n" but it was not working whereas normal case of "ftp start" was working well. Can anyone tell us how to control the no of packets being sent and set the packet size for the above application. Thanks Abha and Nitin From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Nov 14 04:09: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 EAA13654 for ; Thu, 14 Nov 2002 04:09:14 -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 gAE95iu4021232 for ; Thu, 14 Nov 2002 01:05:45 -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 gAE95nEO018310 for ; Thu, 14 Nov 2002 01:05:50 -0800 (PST) Received: from irmgard.exp-math.uni-essen.de (irmgard.exp-math.uni-essen.de [132.252.150.18]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAE95kn7019120 for ; Thu, 14 Nov 2002 01:05:47 -0800 (PST) Received: from there (kappes.exp-math.uni-essen.de [132.252.150.151]) by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with SMTP id gAE8xUln033362 for ; Thu, 14 Nov 2002 09:59:30 +0100 Message-Id: <200211140859.gAE8xUln033362@irmgard.exp-math.uni-essen.de> Content-Type: text/plain; charset="iso-8859-15" From: Thomas Dreibholz Organization: University of Essen, Institute for Experimental Mathematics To: sctp-impl@external.cisco.com Subject: Write permission on this list Date: Thu, 14 Nov 2002 09:59:29 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Please disable write permission for unsubscribed users. I regularly receive spam from this list! Best regards - -- ======================================================================= Dipl.-Inform. Thomas Dreibholz University of Essen, Room ES210 Inst. for Experimental Mathematics Ellernstraße 29 Computer Networking Technology Group D-45326 Essen/Germany - ----------------------------------------------------------------------- E-Mail: dreibh@exp-math.uni-essen.de Homepage: 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 iD8DBQE902X032BbsHYPLWURArh8AJ0RcmnEnXIJd1HPBGTpfPLxMbXi1ACfQUjT pkp8FBjBti5aGd2XkxBVucc= =bBPL -----END PGP SIGNATURE----- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Nov 14 15:27:01 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 PAA29680 for ; Thu, 14 Nov 2002 15:27:00 -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 gAEKKiNf017775 for ; Thu, 14 Nov 2002 12:20:44 -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 gAEKKhfV013824 for ; Thu, 14 Nov 2002 12:20:44 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gAEKKdY3000078 for ; Thu, 14 Nov 2002 12:20:40 -0800 (PST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id PAA08280 for ; Thu, 14 Nov 2002 15:01:52 -0500 (EST) Message-ID: <3DD4012F.7000108@ulticom.com> Date: Thu, 14 Nov 2002 15:01:51 -0500 From: David Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sctp-impl Subject: Implementor's Guide, section 2.27.2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In Implementor's Guide, section 2.27.2, it states: If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to section 3.2.1 it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. However, if the parameter type begins with '01', no INIT-ACK will be sent back to the peer. In this case, should we sent an ERROR chunk? If so, the text should be made clearer. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Thu Nov 14 18:07:03 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 SAA07590 for ; Thu, 14 Nov 2002 18:07:02 -0500 (EST) 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 gAEN5Yu4005567 for ; Thu, 14 Nov 2002 15:05:34 -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 gAEN5d8v013275 for ; Thu, 14 Nov 2002 15:05:39 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gAEN5YsG020530 for ; Thu, 14 Nov 2002 15:05:34 -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 gAEMkJO01240 for ; Fri, 15 Nov 2002 00:46:19 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Nov 2002 00:46:49 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 00:46:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 00:46:49 +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: Implementor's Guide, section 2.27.2 Date: Fri, 15 Nov 2002 00:46:48 +0200 Message-ID: Thread-Topic: Implementor's Guide, section 2.27.2 Thread-Index: AcKMHSev8gTqyqtJQW6fILJuKSYSpwAERAqw From: To: , X-OriginalArrivalTime: 14 Nov 2002 22:46:49.0349 (UTC) FILETIME=[B7B8D350:01C28C2F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07590 Hi David! > -----Original Message----- > From: ext David Lehmann [mailto:lehmann@ulticom.com] > Sent: 14 November, 2002 22:02 > To: sctp-impl > Subject: Implementor's Guide, section 2.27.2 > > > In Implementor's Guide, section 2.27.2, it states: > If the receiver of an INIT chunk detects unrecognized > parameters > and has to report them according to section 3.2.1 it MUST put > the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk > sent in response to the INIT-chunk. > > However, if the parameter type begins with '01', no INIT-ACK will be > sent back to the peer. In this case, should we sent an ERROR chunk? > If so, the text should be made clearer. Yeah, I think you are right. If the peer has to discard the INIT but still report the error, it should send an ERROR chunk back... The problem is that some implementations where sending always the ERROR chunk, in a separate chunk (and the INIT ACK didn't carry the 'Unrecognized Parameter' parameter). This way there is a possibility that the ERROR chunk gets first to the destination and then, and there is no association yet, the ERROR receiver should send back and ABORT that would abort the association... Later on the INIT ACK would be received and accepted, but probably the INIT sender won't accept the COOKIE ECHO because it will have already aborted the association... I thinks this should be made more clear. BR Iván Arias Rodríguez From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Nov 15 07:51:43 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 HAA07037 for ; Fri, 15 Nov 2002 07:51:42 -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 gAFCnuNf025488; Fri, 15 Nov 2002 04:49: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 AAT12275; Fri, 15 Nov 2002 04:49:56 -0800 (PST) Message-ID: <3DD4ED73.1040506@cisco.com> Date: Fri, 15 Nov 2002 06:49:55 -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: Thomas Dreibholz CC: sctp-impl@external.cisco.com Subject: Re: Write permission on this list References: <200211140859.gAE8xUln033362@irmgard.exp-math.uni-essen.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thomas: ... I wish I could.. I asked Cisco ITS if they could please disable posting from unsubscribed folks.. there answer was that if you wanted to cut down on spam make the list internal only (i.e. so that only internal cisco folks could post) :-0 They just did not get it... I may try again when I have some cycles but fighting the IT dept is a tough thing.. and takes far more cycles than I currently have.. So far we have not gotten a LOT of spam.. but it WILL come I know :-0 Maybe before it gets to bad I can find the cycles to fight the IT battle... R Thomas Dreibholz wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi! > >Please disable write permission for unsubscribed users. I regularly receive >spam from this list! > > >Best regards >- -- >======================================================================= > Dipl.-Inform. Thomas Dreibholz > > University of Essen, Room ES210 > Inst. for Experimental Mathematics Ellernstraße 29 > Computer Networking Technology Group D-45326 Essen/Germany >- ----------------------------------------------------------------------- > E-Mail: dreibh@exp-math.uni-essen.de > Homepage: 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 > >iD8DBQE902X032BbsHYPLWURArh8AJ0RcmnEnXIJd1HPBGTpfPLxMbXi1ACfQUjT >pkp8FBjBti5aGd2XkxBVucc= >=bBPL >-----END PGP SIGNATURE----- > > > -- 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 Nov 15 08:05: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 IAA07350 for ; Fri, 15 Nov 2002 08:05:08 -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 gAFCvlsA024970; Fri, 15 Nov 2002 04:57:47 -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 AAT12358; Fri, 15 Nov 2002 04:57:57 -0800 (PST) Message-ID: <3DD4EF55.5000104@cisco.com> Date: Fri, 15 Nov 2002 06:57:57 -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: kai.zhao@nokia.com CC: sctp-impl@external.cisco.com Subject: Re: domain name query in kernel References: <8AE4923BB4DAF3448FBAA1F3261EF2B005C935@beebe001.china.nokia.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit kai.zhao@nokia.com wrote: >hi, >is there any function call which can get host+domain name from IPv4 / IPv6 address? >from kernel level. >thanks. >zhao kai > > > This is the basic problem with that feature. The only way you can do this is to create a process that listens to the kernel for queries.. then the kernel would need to send it a request and block that kernel thread... waiting for the process to read the request and then make the DNS query and then write back down the response.. Now taking a step backwards and looking at the feature: Why did we add it to SCTP? - The reason was to help SCTP pass through NAT's better. Now I think this is where I blew it in not seeing the right argument to get it removed from the RFC... The basic problem with the above is it DOES NOT work.. Think about it: If I send a INIT(no-addresses)--------------> This will pass through a NAT ok.. no problem The idea of the host name address was to INIT(host-name-address)---------> and then on the other side lookup(hostname) and come up with a list of IP-a/IP-b/IP-c In other words to support multi-homing through NATs.. But I did not think in detail on this (as I have now)... If you did do this it WOULD NOT help you get through a NAT. Two of the nats in the above example would NOT know ANYTHING about the state (except of course the one that came through). The two NAT's would not be aware of any translation choice the single NAT the INIT went through would make... so really the host-name address is broken!! It won't do what it was supposed to do... when in fact the INIT with no address will at least let SCTP and NAT's co-exist. My STRONGEST recomendation to any SCTP implementor is to NOT NOT NOT implement this feature!! Spend your time doing something far more worth while like PR-SCTP and ADD-IP. I think we have a solution for NAT's and we can then kill this feature when we go to draft- standard.. 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 Nov 15 08:29: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 IAA07807 for ; Fri, 15 Nov 2002 08:29:38 -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 gAFDMCsA005154 for ; Fri, 15 Nov 2002 05:22:12 -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 gAFDMMFj008814 for ; Fri, 15 Nov 2002 05:22:22 -0800 (PST) Received: from smtp.x263.net ([211.150.96.24]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gAFDMGVm012124 for ; Fri, 15 Nov 2002 05:22:17 -0800 (PST) Received: by smtp.x263.net (Postfix, from userid 500) id 6C21F1BB54; Fri, 15 Nov 2002 21:02:29 +0800 (CST) From: =?gb2312?B?SmlueWFuZ1NISQ==?= To: sctp-impl@external.cisco.com Subject: source-address selection problem Date: Fri, 15 Nov 2002 21:07:22 +0800 X-Priority: 1 X-MSMail-Priority: High MIME-Version: 1.0 X-Mailer: XMail-1.0 Content-Type: text/plain; charset="gb2312" Message-Id: <20021115130229.6C21F1BB54@smtp.x263.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA07807 hi, dear all: the following is a thread in [tsvwg maillist] from Lev: ----------------------------------------------------------- >I have to find a solution of the problem with multihoming. >The case is referenced in draft-coene-sctp-multihome-03.txt. Our configuration is as shown on Figure 2.1.3. +------------+ *~~~~~~~~~* +------------+ | Endpoint A | * Cloud * | Endpoint B | | 1.2 +---------+ 1.1<--+ | | | | | | |->3.1|----------+ 3.2 | | 2.2 +---------+ 2.1<--+ | | | | | * * | | +------------+ *~~~~~~~~~* +------------+ >We are unable currently to apply another IP address to the Endpoint B. Endpoint A may only choose interface based on destination IP. >The problem is following: >The Endpoint A sends all the packages with 1.2 as IP source. If 1.2-1.1 broken it uses 2.2-2.1. (OS changes its routing table). Such behavior required in the draft. >The Endpoint B verifies two paths and defines that path 3.2-1.2 failed. It starts to send data using 3.2-2.2. But it still must response on all HEARTBEAT and DATA chunks to the IP from arrived packets, i.e 1.2. Those packages will not pass to the Endpoint A without special arrangement in the network. >I do not think that such special arrangement are always possible. Or if they possible why to have the multihoming? Or the conclusion is the singlehomed host do not allow to use multihoming at all? >Best regards, >Lev ----------------------------------------------------------- The following is from me: I think it is a problem of source-address selection. We maybe have two strategies to select a source address for a packet: one is just to look up in the routing table according to the destination; but sometimes the route-table maintained by the OS can't recognize the destination and will thus make some mistakes, so in such cases, we need to select the source address by ourselves, that is, to select the network interface by ourselves. I think Lev's problem is under the second strategy: If the destination is 3.2, we will always select 1.2 as the source addesss by ourselves. In such case, even the the IP packet sent via 2.2 interface, the IP source address will still be 1.2. As a result, endpoint A go on sending patkets via 2.2 interface, these packet reach endpoint B, B send SACK back to 1.1, and all the SACK can't not reach A, transfering fail. However the HeartBeat and HeartBeat-Ack between 2.2-3.2 can still communicate as normal, the association is always on, but we we can't transfer data from A->B. But i think if we use the second strategy and select 1.1 as the source address, we should let the packet sent via the same interface. -------------------- I had done a similar experiment before, based on Linux environment. I take the first strategy and just let the OS select the source IP address by itself. +------------+ *~~~~~~~~~* +------------+ | Endpoint A | * Cloud * | Endpoint B | | 10.4.0.1 +---------+ x.x<--+ | | | | | | |->x.x|----------+ 10.2.0.1 | | 10.3.0.1 +---------+ x.x<--+ | | | | | * * | | +------------+ *~~~~~~~~~* +------------+ The following is the ethereal trace: [01] INIT chunk from 10.4.0.1 to 10.2.0.1; [02] INIT-ACK chunk from 10.2.0.1 to 10.4.0.1. In the INIT chunk, we can find two IPv4 addresses: 10.3.0.1 and 10.4.0.1. Then send a message : [03] DATA chunk from 10.4.0.1 to 10.2.0.1, [04] SACK chunk from 10.2.0.1 to 10.4.0.1, [05] HEARTBEAT chunk from 10.4.0.1 to 10.2.0.1, [06] HEARTBEAT-ACK chunk from 10.2.0.1 to 10.4.0.1, [07] HEARTBEAT chunk from 10.2.0.1 to 10.3.0.1, [08] HEARTBEAT-ACK chunk from 10.4.0.1 to 10.2.0.1. [09] HEARTBEAT chunk from 10.2.0.1 to 10.4.0.1, [10] HEARTBEAT-ACK chunk from 10.4.0.1 to 10.2.0.1. The association is established between A and B, and data is passing through. We can find that the active interface on endpoint A now is eth1(10.4.0.1). Then we disable the currently active interface (eth 1: 10.4.0.1 ): [11] DATA chunk from 10.3.0.1 to 10.2.0.1, [12] SACK chunk from 10.2.0.1 to 10.3.0.1, We look into the HEARTBEAT : [13] HEARTBEAT chunk from 10.3.0.1 to 10.2.0.1, [14] HEARTBEAT ACK chunk from 10.2.0.1 to 10.3.0.1, [15] HEARTBEAT chunk from 10.2.0.1 to 10.4.0.1, [16] No HEARTBEAT ACK [17] HEARTBEAT chunk from 10.2.0.1 to 10.3.0.1, [18] HEARTBEAT ACK chunk from 10.3.0.1 to 10.2.0.1. The association is still established between A and B, and data is passing through. We can find that the active interface on endpoint A now is eth0(10.3.0.1). -------------------- From the ethereal trace, we can have two conclusions: One, From [11], we can see that Lev's problem never happen, because we use fisrt strategy. Two, From [08]. When endponit A receive HEARTBEAT[07] from 10.2.0.1 to 10.3.0.1, then it HEARTBEAT ACK[08] back to 10.0.2.1, and with source address 10.4.0.1 selected by route table, other than 10.3.0.1. I think this isn't reasonable, in other experiments we have find it will result in mistakes, therefore in some case so we need the second strategy, that is, to selece source address by ourselves. Randy had mentioned source-address-selection in their book, but he assumes that we will always know the route table, i think it seems that in most time we may not alawys konw it. So we try to study two problems: in whick case we need to use the second strategy, and how we select the source address? Especially we maybe nerver know how the OS maintains the route table. I am not sure if i express myself clearly, and wish for more guidance and discussion -:) Best regards Yang 11/15 --------------------------------- Jinyang SHI Mail: sctp@263.net Office:(86-10) 65392828-2759 Nokia(China) R&D Center Lab: (86-10) 62283757 Broadband Network Research Center, National Lab of Switching Tech. and Telecom Networks, Beijing University of Posts and Telecommunications(BUPT), P.R.China From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Nov 15 15:49:03 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 PAA18672 for ; Fri, 15 Nov 2002 15:49:02 -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 gAFKdM5V014798; Fri, 15 Nov 2002 12:39:22 -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 gAFKdMpk013027; Fri, 15 Nov 2002 12:39:22 -0800 (PST) Received: from Localhost (80-235-101-162-dsl.plus.estpak.ee [80.235.101.162]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id gAFKdH1P025991; Fri, 15 Nov 2002 12:39:18 -0800 (PST) Message-Id: <200211152039.gAFKdH1P025991@proxy1.cisco.com> From: Union Subject: Steam... Organization: Home Reply-To: Gs-Union@inbox.ru X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Fri, 15 Nov 2002 22:39:01 +0200 Çäđŕâńňâóéňĺ! ß çíŕţ, âŕě ęŕćäűé äĺíü ďđčőîä˙ň ďčńüěŕ, ďîäîáíî ýňîěó, ń ďđĺäëîćĺíč˙ěč î đŕáîňĺ. Íî íĺ óďóńňčňĺ řŕíń, ďîęŕ ýňî âîçěîćíî. Âî âń˙ęîě ńëó÷ŕĺ âű íč÷ĺăî íĺ ňĺđ˙ĺňĺ!!! Âîçěîćíîńňü çŕđŕáŕňűâŕňü äĺíüăč â ęŕ÷ĺńňâĺ îńíîâíîăî čëč äîďîëíčňĺëüíîăî äîőîäŕ. Âű ěîćĺňĺ ëĺăęî ďîëó÷ŕňü 500 äîëëŕđîâ â ěĺń˙ö, çŕňđŕ÷čâŕ˙ âńĺăî 10 ÷ŕńîâ â íĺäĺëţ Âŕřĺăî âđĺěĺíč! Âű äŕćĺ ńěîćĺňĺ çŕđŕáŕňűâŕňü č áîëĺĺ 2000 äîëëŕđîâ, ĺńëč ăîňîâű óäĺë˙ňü ýňîěó äîńňŕňî÷íî âđĺěĺíč. Âń˙ đŕáîňŕ ěîćĺň âűďîëí˙ňüń˙ íŕ äîěó. Âŕě íóćĺí ňîëüęî ęîěďüţňĺđ ń ďîäęëţ÷ĺíčĺě ę číňĺđíĺňó, ŕ âńĺěó îńňŕëüíîěó ěű Âŕń íŕó÷čě. Íŕ÷číŕéňĺ çŕđŕáŕňűâŕňü ńĺăîäí˙! Îáđŕůŕéňĺńü ďî alexunion121@hotmail.com ( gs-union1@yandex.ru ) ń ďîěĺňęîé îáđŕáîňęŕ ýëĺęňđîííîé ďî÷ňű. ____ __ ____ Óäŕ÷č âŕě!!! Č čçâĺíčňĺ, ĺńëč äŕííŕ˙ đŕńńűëęŕ ďđčíĺńëŕ âŕě íĺóäîáńňâŕ!!! From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Nov 15 18:07:42 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 SAA23042 for ; Fri, 15 Nov 2002 18:07:41 -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 gAFN65sA026177 for ; Fri, 15 Nov 2002 15:06: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 gAFN65hp025408 for ; Fri, 15 Nov 2002 15:06:05 -0800 (PST) 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 gAFN681O012985 for ; Fri, 15 Nov 2002 15:06:13 -0800 (PST) Received: from stimpy.eecis.udel.edu by mail.eecis.udel.edu id aa11718; 15 Nov 2002 18:00 EST Date: Fri, 15 Nov 2002 18:00:07 -0500 (EST) From: "Armando L. Caro Jr." Reply-To: "Armando L. Caro Jr." To: Abha Singh Bais cc: sctp-impl@external.cisco.com, ns2sctp list MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: Re: FTP over SCTP In-Reply-To: <20021113194739.10150.qmail@webmail30.rediffmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Abha, You are posting to the wrong list for ns-2 questions. We have a separate mailing list that you can subscribe to for such questions. If you aren't on the list already, I can add you (just let me know). To answer your question: 1. You can send a file with x number of bytes with "ftp send x". 2. You can set the packet size with sctp's mtu_ variable. If you have an sctp agent called sctp0, you can do "$sctp0 set mtu_ y", where y is the packet size you want. By default, the mtu is 1500 bytes. ~armando 0-- --0 | Armando L. Caro Jr. | acaro@cis.udel.edu | | University of Delaware | www.cis.udel.edu/~acaro | 0-- --0 On 13 Nov 2002, Abha Singh Bais wrote: > During our simulations for ftp over sctp in ns. > We tried using "ftp produce n" but it was not working whereas > normal case of "ftp start" was working well. Can anyone tell us > how to control the no of packets being sent and set the packet > size for the above application. From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Nov 15 18:28: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 SAA23393 for ; Fri, 15 Nov 2002 18:28:15 -0500 (EST) 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 gAFNHe5V010700 for ; Fri, 15 Nov 2002 15:17:40 -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 gAFNHS7V001007 for ; Fri, 15 Nov 2002 15:17:28 -0800 (PST) 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 gAFNHa1O016160 for ; Fri, 15 Nov 2002 15:17:37 -0800 (PST) Received: from stimpy.eecis.udel.edu by mail.eecis.udel.edu id aa15238; 15 Nov 2002 18:11 EST Date: Fri, 15 Nov 2002 18:11:43 -0500 (EST) From: "Armando L. Caro Jr." Reply-To: "Armando L. Caro Jr." To: wang.ht2002@163.com MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu cc: SCTP mailist , ns2sctp list Subject: Re: reliable messages in PRSCTP In-Reply-To: <20021029072730.1BA801C640753@sm205.163.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry for the delayed response, but just catching up on this list... On Tue, 29 Oct 2002 wang.ht2002@163.com wrote: > I am working on the prsctp module for ns-2. Are you working with our (PEL's) existing ns-2 module? If so, we should discuss what you are working on, because I have already implemented the version when it was called u-sctp. The only change that need to go in is the reliability specification change. Our code supports the k-rtx specification and not the timed-reliablity specification. As far as everything else goes, I _believe_ most everything else has stayed the same. ~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 Mon Nov 18 12:53:34 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 MAA28094 for ; Mon, 18 Nov 2002 12:53:33 -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 gAIHi2Nf012228 for ; Mon, 18 Nov 2002 09:44:02 -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 gAIHhonX022207 for ; Mon, 18 Nov 2002 09:43:50 -0800 (PST) Received: from mail-gw.radisys.com (mail-gw.radisys.com [206.102.10.35]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAIHi00n013326 for ; Mon, 18 Nov 2002 09:44:00 -0800 (PST) Received: by mail-gw.radisys.com (Postfix, from userid 5) id 638244E6FE; Mon, 18 Nov 2002 09:31:27 -0800 (PST) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAAanaOMZ; Mon Nov 18 09:31:20 2002 Subject: When is the heartbeat resumed after data sending is stopped? To: sctp-impl@external.cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Simon.Zhuang@radisys.com Date: Mon, 18 Nov 2002 12:20:33 -0500 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.9a |January 7, 2002) at 11/18/2002 09:37:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi List, On P93 in RFC 2960, A destination transport address is considered "idle" if no new chunk which can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to both active and inactive destination addresses. Based on the RFC, the heartbeat will be resumed when the dest is declared as "idle" destination. It means that a heartbeat will be sent within the current heartbeat period of that address after the last data is sent. Is it right? Thanks in advance. Simon RadiSys Corporation From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Nov 19 10:18: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 KAA07162 for ; Tue, 19 Nov 2002 10:18:23 -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 gAJF7DsA015775; Tue, 19 Nov 2002 07:07:13 -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 AAT96430; Tue, 19 Nov 2002 07:07:25 -0800 (PST) Message-ID: <3DDA53AC.10601@cisco.com> Date: Tue, 19 Nov 2002 09:07:24 -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: Simon.Zhuang@radisys.com CC: sctp-impl@external.cisco.com Subject: Re: When is the heartbeat resumed after data sending is stopped? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Simon: What you basically do is keep track of the last time you sent to any address of your peer. Periodically you wake up (the HB interval) and see if you have not sent anything (data) within the last RTO).. if not you go ahead and send a HB .. otherwise you restart your HB timer and try again... next interval. There is also one modification you can do to this algorithm (which I know I did).. which is have ONLY one HB timer (not one for each link)... in this case when you wake up it is not just one destination you look at.. but all destinations.. and you take the one that has the most ammount of time past since it was sent to... This then means on a completly idle association you would round robin your HB every HB interval (plus the jitter and RTO) to the destinations... R Simon.Zhuang@radisys.com wrote: >Hi List, > >On P93 in RFC 2960, > > A destination transport address is considered "idle" if no new chunk > which can be used for updating path RTT (usually including first > transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no > HEARTBEAT has been sent to it within the current heartbeat period of > that address. This applies to both active and inactive destination > addresses. > > >Based on the RFC, the heartbeat will be resumed when the dest is declared >as "idle" destination. It means that a heartbeat will be sent within the >current heartbeat period of that address after the last data is sent. Is it >right? > >Thanks in advance. > >Simon >RadiSys Corporation > > > > -- 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 Nov 19 10:40:14 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 KAA07772 for ; Tue, 19 Nov 2002 10:40:13 -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 gAJFP85V022454; Tue, 19 Nov 2002 07:25: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 AAT96771; Tue, 19 Nov 2002 07:25:03 -0800 (PST) Message-ID: <3DDA57CE.6030809@cisco.com> Date: Tue, 19 Nov 2002 09:25:02 -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: "sctp-impl@external.cisco.com" Subject: Re: v4-mapped-v6 addresses with SCTP Sockets API. References: <3DC84D31.7BD62BBB@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon: Some comments from a boring bof :-> Jon Grimm wrote: >Might as well dump out another I-D issue, so we can get them into the >next I-D if needed: > >Concerning "v4-mapped-v6" addresses and SCTP Sockets Extensions: > >The latest drafts for the SCTP sockets extensions do not say anything to >v4-mapped-v6 addresses. Previous drafts had said very little, except >in the socket(PF_INET6) having some words of : > >"The syntax is, > > sd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP); > > or, > > sd = socket(PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP); > > Here, SOCK_SEQPACKET indicates the creation of a UDP-style socket. > > The first form creates an endpoint which can use only IPv4 > addresses, while, the second form creates an endpoint which can use > both IPv6 and IPv4 mapped addresses. >" > >(Yes, I had to dig back a ways to find it, but I knew the words were >there at one point in time). The words were changed from "IPV4 mapped >addresses" to "IPv4 addresses". > >The IPV4-mapped address words have been changed (for some time), but I >don't have the context for the change. Are v4-mapped-v6 address just >an implied part of the API? Or does this imply the opposite, that they >should not be supported for SCTP PF_INET6 applications? > > I don't think that it is NOT supported... but implied as to the way you want to do it.. In our implementation: - A IPv4 address can be sent to a IPv6 address (assuming you have not set the V6_ONLY flag on the socket). Or if you prefer you can send to a mapped V4 address and the stack will convert it to V4... - In reading an address... if someone sends to you from an IPv4 address you will read from your IPv6 socket one of two things... either a true IPv4 address OR a IPv4 mapped address. This is dependant on a flag that we put in the API. The default is you get IPv4 addresses as IPv4 addresses...even though this does not coorespond to the v6 api spec... (if you want that you turn on the flag). My personel opinion as always been that it made no sense to have a V6 socket that you the app had to (on send): 1) Convert V4 address to mapped V6 2) pass to kernel 3) kernel convert V6 address to V4 4) then process. And on rcv 1) Kernel does processing 2) Kernel converts to mapped v6 address sends to user 3) User reads 4) User converts to V4 address. This just all seemed like an extra waste of cycles... so Peter and I decided to a) make the above work for the pureist and b) allow a user to send v4 and v6 addresses down and based on our api flag rcv either a mapped or pure v4 address. I felt this was a good approach and I did not want the sockets draft to force one to do it a specific way but leave it open... this is why I changed the wording of the only place (amongst several others that it was not specified) to the wording you note.. this a) keeps it consistent in the document and b) leaves the implementation wiggle room to do either method or both :> >Note: I realize v4-mapped-v6 are completely disallowed within the SCTP >protocol; my question is specifically on how to handle PF_INET6 clients >at the API layer. > >As it is currently, stands my interpretation is: > PF_INET sockets, AF_INET addresses: v4 addresses > PF_INET6 sockets, AF_INET6 addresses: v6 or v4-mapped addresses > > And the wording of the document completely allows the above but it also allows PF_INET6 sockets, AF_INET6 addresses v6 or v4-mapped PLUS v4 addresses... >My view is such as it preserves the presently expected behavior for >PF_INET6 applications needing to interact with a v4 peers. This would >include msg_name for recvmsg/sendmsg calls. > > Yes this was our point.. preserve the apps view but in reality what most apps do (I know from my recent ports of some of the v6 capable apps) a) read in to a sock_storage (or equivialant) b) look at the type... if it is v4 process it as that c) if it is v6 see if it is mapped... if so change it to v4 and process d) else process as v6. That way the same code can deal with v6 or v4 sockets... I like our solution.. you can have it either way you want it.. restrict reads to only mappedv4 or get real v4... application choice... >However, there are new API issues with the SCTP extensions: For >example, >bindx() and various events use "struct sockaddr_storage". Should a >PF_INET6 socket use AF_INET6 addresses exclusively, or should we allow >either? > I think you must allow a mapped v4 address in the bindx.. unless you have turned on a V6_ONLY flag (if your O/S has this). In our implementation unless the V6_ONLY flag is set we will accept (on a PF_INET6 socket) a) v6 address b) v6 mapped v4 or c) v4 addresses in ALL cases.. > Its easy enough to allow either as input to sockets, but how >about for output (e.g. events)? Should we specify AF_INET6 only, or >make the application expect either (AF_INET v4 address or AF_INET6 >v4-mapped-v6 address). > >Yes, this is probably a very minor issue, but I'd like to get this >nailed down for expectations by PF_INET6 application writers, so they >don't tie themselves in early to any certain implementaion choice. > > I would like to leave it as it is.. aka unspecified.. The documetn as I have said allows wiggle room.. >Some options: >1) No v4-mapped-v6 addresses allowed > >2) PF_INET6 addresses exclusively use AF_INET6 address format (v4 >addresses come in/out as v4-mapped-v6 only) >3) Specify some hybrid behavior in the I-D. Minimally, I'd expect to >see what the application can expect on output. >3) Anything goes! Application is required to expect addressing format >for V4 addresses in either format. > >Opinions? > > Right now the document leaves it open.. but we may want to put some minor text in that specifies that a applicaiton should always have the ability to assure all v4 addresses are mapped if we have a v6 socket... That way an app COULD be written to deal with v6 only address styles ** a poor design in my mind ** but we can allow bad designs too :-) R >Best Regards, >Jon Grimm > > > -- 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 Tue Nov 19 12:35:24 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 MAA10704 for ; Tue, 19 Nov 2002 12:35:23 -0500 (EST) 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 gAJHU2u4027644 for ; Tue, 19 Nov 2002 09:30:02 -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 gAJHU58Q011675 for ; Tue, 19 Nov 2002 09:30:06 -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 gAJHTtpN025776 for ; Tue, 19 Nov 2002 09:29:55 -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 LAA73832; Tue, 19 Nov 2002 11:21:12 -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 LAA29996; Tue, 19 Nov 2002 11:23:30 -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 LAA33260; Tue, 19 Nov 2002 11:23:29 -0600 Sender: root@popmail.austin.ibm.com Message-ID: <3DDA6AC4.830BA901@us.ibm.com> Date: Tue, 19 Nov 2002 10:45:56 -0600 From: Jon Grimm X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.47 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: "sctp-impl@external.cisco.com" Subject: Re: v4-mapped-v6 addresses with SCTP Sockets API. References: <3DC84D31.7BD62BBB@us.ibm.com> <3DDA57CE.6030809@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy, Spec'ing a mechanism to set/get behavior seems reasonable, though the choice of default is arguable given RFC 2553 expectations. OTOH, from your porting experiences it doesn't sound like application are really taking advantage of v4-mapped-v6 addresses in a way to consolidate their code. Is this likely due to the application still needing to support PF_INET only systems? That darn reality just keeps creeping in, don't it? I'll watch for a mechanism (I'm assuming sockopt here.) forthcoming. A recvmsg flag seems overkill as an application would surely just want one addressing format. Best Regards, Jon "Randall Stewart (cisco)" wrote: > > Jon: > > Some comments from a boring bof :-> > > Jon Grimm wrote: > > > > I don't think that it is NOT supported... but implied as to the way you > want to do it.. > > In our implementation: > > - A IPv4 address can be sent to a IPv6 address (assuming you have not > set the V6_ONLY flag on the socket). Or if you prefer you can send to > a mapped V4 address and the stack will convert it to V4... > > - In reading an address... if someone sends to you from an IPv4 address > you will read from your IPv6 socket one of two things... either a true > IPv4 address OR a IPv4 mapped address. This is dependant on a flag > that we put in the API. The default is you get IPv4 addresses as IPv4 > addresses...even > > > Right now the document leaves it open.. but we may want to put > some minor text in that specifies that a applicaiton should > always have the ability to assure all v4 addresses are mapped if > we have a v6 socket... > > That way an app COULD be written to deal with v6 only address styles ** > a poor > design in my mind ** but we can allow bad designs too :-) > > R > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 20 10:20:45 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 KAA21490 for ; Wed, 20 Nov 2002 10:20:44 -0500 (EST) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAKFEfu4025606 for ; Wed, 20 Nov 2002 07:14:42 -0800 (PST) Received: from www.example.org (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA14509 for ; Wed, 20 Nov 2002 16:14:45 +0100 (MET) Received: (qmail 73837 invoked by uid 1000); 20 Nov 2002 15:14:39 -0000 Message-ID: <20021120151439.73836.qmail@cobweb.example.org> Date: Wed, 20 Nov 2002 16:14:39 +0100 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: partial reliability SCTP and MPEG streaming X-Mailer: Sylpheed version 0.8.6 (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 Hi, hope this is not OT. I presented a paper at the 2nd BSDCon Europe on "Using Partial Reliability SCTP for MPEG-4 multimedia streaming". We modified the Apple Darwin Streaming Server and the Cisco MPEG4IP mp4player to use PR-SCTP instead of RTP/UDP. paper http://www.gufi.org/~molter/papers/mpeg4sctp-molteni-villari-2002-10-24.pdf slides http://www.gufi.org/~molter/papers/mpeg4sctp-slides-molteni-villari/index.html thanks marco From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Nov 21 05:26: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 FAA27319 for ; Thu, 21 Nov 2002 05:26: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-1.cisco.com (8.12.2/8.12.2) with ESMTP id gALAC7Nf018102 for ; Thu, 21 Nov 2002 02:12: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 gALABspD008972 for ; Thu, 21 Nov 2002 02:11:54 -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 gALABqpN020996 for ; Thu, 21 Nov 2002 02:11:53 -0800 (PST) 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 gAL9qf902971 for ; Thu, 21 Nov 2002 11:52:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 11:53:14 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 11:53:13 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Nov 2002 17:52:27 +0800 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" Date: Thu, 21 Nov 2002 17:52:26 +0800 Message-ID: Thread-Index: AcKRQ46vscpIkT63T7WGhPc2lNJ66g== From: To: Cc: X-OriginalArrivalTime: 21 Nov 2002 09:52:27.0384 (UTC) FILETIME=[B31FD780:01C29143] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA27319 hi, I have several questions about implementing add ip. 1) what's the benefit of using Success Indicatyion(0xC005)? It seems its usage is to explicitly report a success for a requested TLV if some requests success and the others fail. Is it possible to treat it as the default value of a response and not using it at all? 2)If the sender requests to delete a address not in its address list by mistake, what shall the receiver do? Reply a success or tell error to the sender? If the receiver choose to tell the error to the sender, what's the cause code? 3) In Section 4.2,C3,X1, if the request was refused because of resource shortage in previous process but there is resource available now, shall the receiver still send ERROR the sender? Thanks! Dajiang Zhang From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Thu Nov 21 09:13:49 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 JAA02560 for ; Thu, 21 Nov 2002 09:13:48 -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 gALE2vsA027382; Thu, 21 Nov 2002 06:02:57 -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 AAU70497; Thu, 21 Nov 2002 06:03:04 -0800 (PST) Message-ID: <3DDCE798.2030609@cisco.com> Date: Thu, 21 Nov 2002 08:03: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: dajiang.zhang@nokia.com CC: sctp-impl@external.cisco.com, lksctp-developers@lists.sourceforge.net Subject: Re: References: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit dajiang.zhang@nokia.com wrote: >hi, > >I have several questions about implementing add ip. > >1) what's the benefit of using Success Indicatyion(0xC005)? > It seems its usage is to explicitly report a success for a requested TLV if some requests success and the others fail. > Is it possible to treat it as the default value of a response and not using it at all? > > The success is not the default case once you deny one.. so if i process a Add-ip (ipa) Del-IP (ipz) add-ip (ipq)>> failed lack of resources setprimary (ipa) del-ip (ipq) >> failed due to add-ip rules Then if you decided to do the setprimary and you want to tell the peer hyou would need the success indication to tel them failed (lack of resources on the ipq) sucess (setprimary) Which should tell them the state... I personelly would report everything from the failed onward... (even though the last failed is implied)aka failed success failed. The earlier successes are implied ... >2)If the sender requests to delete a address not in its address list by mistake, what shall the receiver do? > Reply a success or tell error to the sender? If the receiver choose to tell the error to the sender, what's the cause code? > > I just send a ok.. since it wanted it out and it is out... Otherwise the peer may think it can source packets from that address and you would send an abort if it did (we are talking about a buggy sender anyway so this is an extreme corner but I think attempting to protect oneself from such a buggy peer is good)... >3) In Section 4.2,C3,X1, if the request was refused because of resource shortage in previous process but there is resource available now, shall the receiver still send ERROR the sender? > > I am not sure of this question... Once you get a request (add X) then you respond.. You do not hang on to the request and try it again later... once you tell the peer.. I failed that is the end of it as far as you are concerned Now if the peer then later sends the request again... (add X) then you would respond at THAT time as to your resources... i.e. if you have them you would add it.. Hope that helps... R >Thanks! > >Dajiang Zhang > > > > > -- 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 Nov 21 11:22:15 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 LAA08877 for ; Thu, 21 Nov 2002 11:22:14 -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 gALGH25V027541 for ; Thu, 21 Nov 2002 08:17:02 -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 gALGH1nC002359 for ; Thu, 21 Nov 2002 08:17:01 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gALGGwxJ024848 for ; Thu, 21 Nov 2002 08:16:59 -0800 (PST) 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 gALGAJ620291 for ; Thu, 21 Nov 2002 18:10:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 18:09:27 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 18:09:27 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 18:09:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 18:09:26 +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: Date: Thu, 21 Nov 2002 18:09:23 +0200 Message-ID: Thread-Index: AcKRQ46vscpIkT63T7WGhPc2lNJ66gAJwvmA From: To: , Cc: X-OriginalArrivalTime: 21 Nov 2002 16:09:26.0360 (UTC) FILETIME=[5D15AD80:01C29178] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08877 Hi Dajiang! See my comments inline... > hi, > > I have several questions about implementing add ip. > > 1) what's the benefit of using Success Indicatyion(0xC005)? > It seems its usage is to explicitly report a success for > a requested TLV if some requests success and the others fail. You are right... The default is that all the requests for which you didn't include any cause code in the ASCONF ACK, are supposed to be successful... This cause code is just to make it more explicit... > Is it possible to treat it as the default value of a > response and not using it at all? This is what I do in fact... I don't send them, but you always have to understand them if you get any... > 2)If the sender requests to delete a address not in its > address list by mistake, what shall the receiver do? > Reply a success or tell error to the sender? If the > receiver choose to tell the error to the sender, what's the > cause code? Since the address is not in use (and that's exactly what the requester wanted), what I do is simply sending a successful reply... > 3) In Section 4.2,C3,X1, if the request was refused because > of resource shortage in previous process but there is > resource available now, shall the receiver still send ERROR > the sender? The reply must be exactly the same one... Otherwise there is the possibility that the receiver still gets the first ASCONF ACK and then the state at the sender and receiver is different... So, just to avoid this, you should do exactly the same that you did... Probably the best option is keeping always a copy of the last ASCONF ACK chunk sent, but this is just an implementation option... I hope this helps! BR Iv¨˘n Arias Rodr¨Şguez > Thanks! > > Dajiang Zhang > > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Nov 22 04:56: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 EAA21729 for ; Fri, 22 Nov 2002 04:56: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-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAM9oT5V012244 for ; Fri, 22 Nov 2002 01:50:29 -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 gAM9oSSl025810 for ; Fri, 22 Nov 2002 01:50:29 -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 gAM9oDpN025519 for ; Fri, 22 Nov 2002 01:50:14 -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 gAM9V8925467 for ; Fri, 22 Nov 2002 11:31:08 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Nov 2002 11:31:40 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 11:31:40 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 17:01:05 +0800 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: another question about implementing add ip Date: Fri, 22 Nov 2002 17:00:36 +0800 Message-ID: Thread-Topic: [Lksctp-developers] (no subject) Thread-Index: AcKRQ46vscpIkT63T7WGhPc2lNJ66gAwZhZA From: To: Cc: X-OriginalArrivalTime: 22 Nov 2002 09:01:05.0692 (UTC) FILETIME=[B0B4B5C0:01C29205] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA21729 hi, Here is another question about implementing add ip. If the sender requests to set primary path to an address not in its address list by mistake, what shall the receiver do? Which error cause should be used? Thanks! Dajiang Zhang From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Nov 22 07:19:13 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 HAA23577 for ; Fri, 22 Nov 2002 07:18: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-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAMCHSNf002073 for ; Fri, 22 Nov 2002 04:17:28 -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 gAMCHEBs019572 for ; Fri, 22 Nov 2002 04:17:15 -0800 (PST) Received: from hotmail.com (oe21.law10.hotmail.com [64.4.14.125]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAMCHPxJ018123 for ; Fri, 22 Nov 2002 04:17:26 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 04:15:24 -0800 X-Originating-IP: [202.134.200.4] From: "Manish Rajpal" To: Cc: References: Subject: Re: another question about implementing add ip Date: Fri, 22 Nov 2002 17:40:12 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 22 Nov 2002 12:15:24.0745 (UTC) FILETIME=[D60B0390:01C29220] Content-Transfer-Encoding: 7bit hi As told in the draft, its an option that receiver SHOULD perform. If the request can not be honored for whatsoever reasons, it can be ignored. And no response will be taken as success by the peer. newayz, any message from the peer with such an address that does not exist will be responded back by an abort. regards manish ----- Original Message ----- From: To: Cc: Sent: Friday, November 22, 2002 2:30 PM Subject: another question about implementing add ip hi, Here is another question about implementing add ip. If the sender requests to set primary path to an address not in its address list by mistake, what shall the receiver do? Which error cause should be used? Thanks! Dajiang Zhang From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Fri Nov 22 11:02:13 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 LAA28152 for ; Fri, 22 Nov 2002 11:02:13 -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 gAMG0ZNf026047; Fri, 22 Nov 2002 08:00:35 -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 AAV08829; Fri, 22 Nov 2002 08:00:34 -0800 (PST) Message-ID: <3DDE54A0.3060706@cisco.com> Date: Fri, 22 Nov 2002 10:00:32 -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: Manish Rajpal CC: dajiang.zhang@nokia.com, sctp-impl@external.cisco.com Subject: Re: another question about implementing add ip References: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Manish Rajpal wrote: >hi > >As told in the draft, its an option that receiver SHOULD perform. If the >request can not be honored for whatsoever reasons, it can be ignored. And no >response will be taken as success by the peer. > Yes.. I agree with the above.. you ignore the set-primary that sets to an address that does not exist. >newayz, any message from the peer with such an address that does not exist >will be responded back by an abort. > > Hmm.. what does "newayz" mean? You never would send an abort to a peer that said set-primary(x) when (x) is not in the association. R >regards >manish >----- Original Message ----- >From: >To: >Cc: >Sent: Friday, November 22, 2002 2:30 PM >Subject: another question about implementing add ip > > > >hi, > >Here is another question about implementing add ip. > >If the sender requests to set primary path to an address not in its address >list by mistake, what shall the receiver do? >Which error cause should be used? > >Thanks! > >Dajiang Zhang > > > > -- 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 Sun Nov 24 12:37:46 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 MAA29845 for ; Sun, 24 Nov 2002 12:37:40 -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 gAOHZ4sA027087 for ; Sun, 24 Nov 2002 09:35:04 -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 gAOHZIi6013692 for ; Sun, 24 Nov 2002 09:35:19 -0800 (PST) Received: from web14507.mail.yahoo.com (web14507.mail.yahoo.com [216.136.224.70]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id gAOHZHUV006096 for ; Sun, 24 Nov 2002 09:35:17 -0800 (PST) Message-ID: <20021124173018.25557.qmail@web14507.mail.yahoo.com> Received: from [213.154.69.76] by web14507.mail.yahoo.com via HTTP; Sun, 24 Nov 2002 17:30:18 GMT Date: Sun, 24 Nov 2002 17:30:18 +0000 (GMT) From: =?iso-8859-1?q?tony=20maxwell?= Subject: A CRY FOR HELP. To: sctp-impl@external.cisco.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-900980559-1038159018=:24724" Content-Transfer-Encoding: 8bit --0-900980559-1038159018=:24724 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit DEAR THIS LETTER MIGHT COME TO YOU AS A SURPRISED SINCE WE HAVE NOT HADANY PREVIOUS CORESPONDENCE.THIS IS AS A RESULT OF THE HELPLESS SITUATION I FOUND MYSELF INTO. I GOT YOUR CONTACT DURING MY SEARCH FOR A RELIABLE, CAPABLE AND TRUSTWORTHY PERSON THAT CAN ASSIST ME IN THIS DARKEST MOMENT OF MYLIFE.I LOST MY FATHER, MOTHER AND TWO SISTERS,TWO BROTHERS WITH OUR FAMILYHOUSE DURING THE BOMB EXPLOSION WHICH TOOK PLACE ON THE 27TH OF JANUARY,2002 AT THE ARMY CANTONMENT (BARRACKS). I AM ALIVE WRITING YOU BECAUSE I WAS FORTUNATE TO BE OUTSIDE HOME AT THE TIME OF THE EXPLOSIONS. I AM WRITING YOU NOW FROM CAMP WHERE THE VICTIMS OF THE EXPLOSION ARE KEPT INCLUDING MYSELF. NO HOUSE, NO GOOD FOOD ,NO GOOD HEALTH. BEFORE MY FATHER'S SUDDEN DEATH, HE KEPT THE SUM OF US$17,000,000.00 (SEVENTEEN MILLION US DOLLARS) IN CASH WITH A PRIVATE SECURITY VAULT.NOW THAT HE IS LATE AND I AM THE ONLY ONE LEFT BEHIND. I AM WRITING YOU TO ASSIST ME RECEIVE THIS MONEY IN YOUR COUNTRY, INVEST IT IN A PROFITABLE BUSINESS AND RELOCATE ME TO JOIN YOU IMMEDIATELY. AS A RESULT OF INSECURITY OF LIFE AND PROPERTY HERE, I DO NOT WANT TO STAY HERE ANY LONGER.PLEASE INDICATE YOUR READYNESS TO ASSIST ME, SO THAT ALL THE INFORMATION ABOUT THIS FUNDS WILL BE PASSED TO YOU IMMEDIATELY. SEND TO ME YOUR TEL/FAX NUMBERS FOR EASY COMMUNICATION.AND ALSO ASSURE ME YOU WILL NOT BETRAY ME AT THE END. KEEP THISTRANSACTION TO YOUR SELF ONLY. IF THIS TRANSACTION IS PROPERLY EXECUTED, I AM PREPARED TO GIVE YOU 20% OF THE TOTAL SUM FOR YOUR KIND ASSISTANCE. REGARDS, TONY MAXWELL.. --------------------------------- With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs --0-900980559-1038159018=:24724 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
DEAR


THIS LETTER MIGHT COME TO YOU AS A SURPRISED SINCE WE HAVE NOT HADANY PREVIOUS CORESPONDENCE.THIS IS AS A RESULT OF THE HELPLESS  SITUATION  I FOUND  MYSELF  INTO. I  GOT YOUR  CONTACT DURING MY SEARCH FOR A RELIABLE, CAPABLE AND TRUSTWORTHY PERSON THAT CAN ASSIST ME IN THIS DARKEST MOMENT OF MYLIFE.I LOST MY FATHER, MOTHER AND TWO SISTERS,TWO BROTHERS WITH OUR FAMILYHOUSE DURING THE BOMB EXPLOSION WHICH TOOK PLACE ON THE 27TH OF JANUARY,2002 AT THE ARMY CANTONMENT (BARRACKS). I AM ALIVE WRITING YOU BECAUSE I WAS FORTUNATE TO BE OUTSIDE HOME AT THE TIME OF THE EXPLOSIONS. I AM WRITING YOU NOW FROM
CAMP WHERE THE VICTIMS OF THE EXPLOSION  ARE KEPT INCLUDING MYSELF. NO HOUSE, NO GOOD FOOD ,NO GOOD HEALTH.
BEFORE MY FATHER'S SUDDEN DEATH, HE KEPT THE SUM OF US$17,000,000.00
(SEVENTEEN MILLION US DOLLARS) IN CASH WITH A PRIVATE SECURITY VAULT.NOW THAT HE IS LATE AND I AM THE ONLY ONE LEFT BEHIND. I AM WRITING YOU T! O ASSIST ME RECEIVE THIS MONEY IN YOUR COUNTRY, INVEST IT IN A PROFITABLE BUSINESS AND RELOCATE ME TO JOIN YOU IMMEDIATELY. AS A RESULT OF INSECURITY OF LIFE AND PROPERTY HERE, I DO NOT WANT TO STAY HERE ANY LONGER.PLEASE INDICATE YOUR READYNESS TO ASSIST ME, SO THAT ALL THE INFORMATION ABOUT THIS FUNDS WILL BE PASSED TO YOU IMMEDIATELY. SEND TO ME YOUR TEL/FAX NUMBERS  FOR EASY COMMUNICATION.AND ALSO ASSURE ME YOU WILL NOT BETRAY ME AT THE END. KEEP THISTRANSACTION TO YOUR SELF ONLY. IF THIS TRANSACTION IS PROPERLY EXECUTED,  I AM PREPARED TO GIVE YOU 20% OF THE TOTAL SUM FOR YOUR KIND ASSISTANCE.

REGARDS,


TONY MAXWELL..




 


With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
--0-900980559-1038159018=:24724-- From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Nov 25 01:19:51 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 BAA10953 for ; Mon, 25 Nov 2002 01:19:30 -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 gAP6Flu4007252 for ; Sun, 24 Nov 2002 22:15:48 -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 gAP6FpeS020910 for ; Sun, 24 Nov 2002 22:15:51 -0800 (PST) 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 gAP6FWpN003140 for ; Sun, 24 Nov 2002 22:15:33 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAP5w0621295 for ; Mon, 25 Nov 2002 07:58:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Nov 2002 07:56:48 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 07:56:48 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 13:56:11 +0800 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="x-user-defined" Subject: question regarding the implementation of PMTU discovery Date: Mon, 25 Nov 2002 13:55:42 +0800 Message-ID: Thread-Topic: question regarding the implementation of PMTU discovery Thread-Index: AcKURzN+BqfPiABVEdeLyADQWRD0hg== From: To: , , X-OriginalArrivalTime: 25 Nov 2002 05:56:11.0287 (UTC) FILETIME=[5B2A1A70:01C29447] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA10953 Hi, I have a question regarding the implementation of PMTU discovery in SCTP layer. In RFC 1191, it said that in IP layer, PMTU works by using the Donot fragment (DF) bit in the IP header, when the sender receive an ICMP Destination Unreachable messages with a code meaning "fragementation needed and DF set". RFC 1981 mentioned that, for TCP, a simple implementation could ask the IP layer for the value of PMTU each time it created a new segment, but this seems inefficient. While I remember La Monte had told me that may use heartbeat to realize PMTU discovery, does that mean sending heartbeat with DF bit set in IP header to discover the size of PMTU? Thanks! Hui Huang From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Nov 25 09:06: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 JAA28606 for ; Mon, 25 Nov 2002 09:06:34 -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 gAPE07sA015114 for ; Mon, 25 Nov 2002 06:00: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 gAPE08An024417 for ; Mon, 25 Nov 2002 06:00:08 -0800 (PST) Received: from hotmail.com (oe66.law10.hotmail.com [64.4.14.201]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gAPE04pN023127 for ; Mon, 25 Nov 2002 06:00:04 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Nov 2002 05:58:19 -0800 X-Originating-IP: [202.134.200.4] From: "Manish Rajpal" To: "Randall Stewart \(cisco\)" Cc: , References: <3DDE54A0.3060706@cisco.com> Subject: Re: another question about implementing add ip Date: Mon, 25 Nov 2002 19:23:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 25 Nov 2002 13:58:19.0403 (UTC) FILETIME=[B5AA4DB0:01C2948A] Content-Transfer-Encoding: 7bit well, what I meant to say was if the peer considers x to be a part of associations and uses this address as source address in any further messages , it will be responded back with an abort. ----- Original Message ----- From: "Randall Stewart (cisco)" To: "Manish Rajpal" Cc: ; Sent: Friday, November 22, 2002 9:30 PM Subject: Re: another question about implementing add ip > Manish Rajpal wrote: > > >hi > > > >As told in the draft, its an option that receiver SHOULD perform. If the > >request can not be honored for whatsoever reasons, it can be ignored. And no > >response will be taken as success by the peer. > > > > Yes.. I agree with the above.. you ignore the set-primary that sets to > an address that does > not exist. > > >newayz, any message from the peer with such an address that does not exist > >will be responded back by an abort. > > > > > > Hmm.. what does "newayz" mean? You never would send an abort to a peer > that said > set-primary(x) when (x) is not in the association. > > R > > >regards > >manish > >----- Original Message ----- > >From: > >To: > >Cc: > >Sent: Friday, November 22, 2002 2:30 PM > >Subject: another question about implementing add ip > > > > > > > >hi, > > > >Here is another question about implementing add ip. > > > >If the sender requests to set primary path to an address not in its address > >list by mistake, what shall the receiver do? > >Which error cause should be used? > > > >Thanks! > > > >Dajiang Zhang > > > > > > > > > > > -- > 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 Nov 25 09:07:42 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 JAA28642 for ; Mon, 25 Nov 2002 09:07:41 -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 gAPE2ZsA016743 for ; Mon, 25 Nov 2002 06:02:35 -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 gAPE2o8x003133 for ; Mon, 25 Nov 2002 06:02:50 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gAPE2QpN023873 for ; Mon, 25 Nov 2002 06:02:28 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAPDOSr24690 for ; Mon, 25 Nov 2002 18:54:28 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAPDOR824686 for ; Mon, 25 Nov 2002 18:54:27 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAPDQ9a05894 for ; Mon, 25 Nov 2002 18:56:09 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C7C.00491DF8 ; Mon, 25 Nov 2002 18:48:38 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: sctp-impl@external.cisco.com Message-ID: <65256C7C.00491DAE.00@sandesh.hss.hns.com> Date: Mon, 25 Nov 2002 18:53:04 +0530 Subject: MSG_ABORT flag in sendmsg call Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi The socket draft - 04 says: "whenever sendmsg() or sendto is called and the sctp stack at the sender finds that there are no associations between the sender and intended receiver, the stack will automatically setup an association to the intended receiver." Now my question is what if user has called sendmsg with MSG_ABORT flag set . should an implementation right away reject the request or should it establish an asociation just to abort the association. regards Manish DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Nov 25 10:25:07 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 KAA03217 for ; Mon, 25 Nov 2002 10:25:06 -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 gAPFCqu4017230 for ; Mon, 25 Nov 2002 07:12:52 -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 gAPFCtH0006680 for ; Mon, 25 Nov 2002 07:12:55 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAPFCprY028120 for ; Mon, 25 Nov 2002 07:12:53 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAPEYZr02662 for ; Mon, 25 Nov 2002 20:04:36 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAPEYZ802655 for ; Mon, 25 Nov 2002 20:04:35 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAPEaH708956 for ; Mon, 25 Nov 2002 20:06:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C7C.004F8ACC ; Mon, 25 Nov 2002 19:58:48 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: sctp-impl@external.cisco.com Message-ID: <65256C7C.004F88D0.00@sandesh.hss.hns.com> Date: Mon, 25 Nov 2002 20:03:10 +0530 Subject: Multihoming with NAT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi The socket draft - 04 no-where specifies an option for user to provide a hostname for an address. This creates a problem when a multi-homed endpoint is behind a NAT. As discussed in sctp applicabilty statement, this requires a hostname to be sent in INIT/INIT ack. My question is how to get a hostname for the address provided in sctp-socket interface. regards manish www.hssworld.com DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Nov 25 10:26:58 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 KAA03283 for ; Mon, 25 Nov 2002 10:26:57 -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 gAPF6PKc015919 for ; Mon, 25 Nov 2002 07:06:25 -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 gAPF6L5E003124 for ; Mon, 25 Nov 2002 07:06:21 -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 gAPF62pN013740 for ; Mon, 25 Nov 2002 07:06:03 -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 gAPEkx908096 for ; Mon, 25 Nov 2002 16:46:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Nov 2002 16:47:33 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 16:47:32 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 16:47:32 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 16:47:28 +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="x-user-defined" Subject: RE: question regarding the implementation of PMTU discovery Date: Mon, 25 Nov 2002 16:47:24 +0200 Message-ID: Thread-Topic: question regarding the implementation of PMTU discovery Thread-Index: AcKURzN+BqfPiABVEdeLyADQWRD0hgAR1Raw From: To: , , , X-OriginalArrivalTime: 25 Nov 2002 14:47:28.0160 (UTC) FILETIME=[9342EA00:01C29491] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03283 Hi all! See my comments inline... > -----Original Message----- > From: ext [mailto:hui.huang@nokia.com] > Sent: 25. November 2002 7:56 > To: sctp-impl@external.cisco.com; > lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us > Subject: question regarding the implementation of PMTU discovery > > > Hi, > > I have a question regarding the implementation of PMTU > discovery in SCTP layer. > > In RFC 1191, it said that in IP layer, PMTU works by using > the Donot fragment (DF) bit in the IP header, when the sender > receive an ICMP Destination Unreachable messages with a code > meaning "fragementation needed and DF set". > > RFC 1981 mentioned that, for TCP, a simple implementation > could ask the IP layer for the value of PMTU each time it > created a new segment, but this seems inefficient. > > While I remember La Monte had told me that may use heartbeat > to realize PMTU discovery, does that mean sending > heartbeat with DF bit set in IP header to discover the size of PMTU? This is something I have done mostly since the beginning of SCTP... When I want to test one specific PMTU, what I do is just sending a HB to that address. As the HB doesn't have any structure, you can just fill it with 0s up to the MTU you want to test (taking into account all the headers). Of course, I sent that HEARTBEAT in a single packet and set the DF bit (if I'm using IPv4)... Then, you have three options: a) You receive the HEARTBEAT ACK: That means that the MTU is at least the one tested, and at the same time you also know that the address is working. b) You receive an ICMP packet: The MTU tested is too big. The address might or might not be working. c) You don't receive anything: Either the packet was lost at some point of the network, or the MTU was so big and a router in between simply discarded it (or the ICMP packet was lost), or the address is down (or something else?). In any case, I find the use of HB very helpful because: a) It is really simply to do it. b) At the same time you test the MTU you can test the RTO and stuff (however, the b case would be the normal one, I think). c) You can test exactly the size you want. In TCP it might be easy to do it using the "traditional" way, as it doesn't have any message boundaries. However, in SCTP, this is a little bit more difficult, and you might fragment user messages so the whole packet has the right shape... d) And which is more important, you don't increase the MTU beforehand, so it is not likely that you will lose packets. With the "traditional" way of PMTU discovery, you will normally lose some packets, and then you have to code some mechanism that realizes that those loses are due to a big MTU rather than because the peer is down (matching ICMPs and sent SCTP packets or something else). As far as I know, many of us use this way of measuring the PMTU. So many, that I think it might be a good idea to even write an Internet Draft relating this. If somebody is interested about this, I would like to take part in it... BR Iván Arias Rodríguez > Thanks! > > Hui Huang > > > From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Mon Nov 25 13:16:13 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 NAA14889 for ; Mon, 25 Nov 2002 13:16:12 -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 gAPIDgu4005920 for ; Mon, 25 Nov 2002 10:13:42 -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 gAPIDjhk006881 for ; Mon, 25 Nov 2002 10:13:45 -0800 (PST) Received: from www.highspeedhost.de ([62.140.16.7]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gAPIDgUV004852 for ; Mon, 25 Nov 2002 10:13:43 -0800 (PST) Received: from unknown ([200.77.203.201]) by www.highspeedhost.de (8.11.6/8.11.6) with SMTP id gAPI9h323573 for ; Mon, 25 Nov 2002 19:09:44 +0100 Message-Id: <200211251809.gAPI9h323573@www.highspeedhost.de> Date: Mon, 25 Nov 2002 18:09:41 GMT From: werken_bij_delotto@37.com X-Priority: 3 To: sctp-impl@external.cisco.com Subject: Award Notification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit WERKEN BIJ DE LOTTO, 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: AYT774521DA ATTN: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 21th November. 2002, of winners of the WERKEN BIJ DE LOTTO/ INTERNATIONAL PROGRAMS held on 1ST OCTOBER 2002. You / your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$2,500,000.00 in cash credited to file REF NO. REF: AYT774521DA. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To begin your claim, please contact your claims officer immediately: FRANK UBU FOREIGN SERVICE MANAGER, EURO CROSSING BV, TEL:31-619310573 FAX: 31 619310573 EMAIL:eurocrossingbv@rediffmail.com For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than December 5th, 2002. After this date, all funds will be returned as unclaimed. All correspondences to Mr. Frank Ubu,either by fax or email, should have this email sent along with it and also, your email address to which this email is sent, should be clearly and boldly written in your response. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WERKEN BIJ DE LOTTO. www.werken-bij-delotto.net N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply this mail. This message is been sent to you on your confidential email address [!TO!] for confidentiality purposes. From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Nov 25 21:04: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 VAA05860 for ; Mon, 25 Nov 2002 21:04:15 -0500 (EST) 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 gAQ21tKc021569 for ; Mon, 25 Nov 2002 18:01:55 -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 gAQ21fL4001892 for ; Mon, 25 Nov 2002 18:01:41 -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 gAQ21ZpN028415 for ; Mon, 25 Nov 2002 18:01:36 -0800 (PST) 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 gAQ1gW902469 for ; Tue, 26 Nov 2002 03:42:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Nov 2002 03:43:05 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Nov 2002 03:43:05 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Nov 2002 09:42:34 +0800 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="x-user-defined" Subject: RE: question regarding the implementation of PMTU discovery Date: Tue, 26 Nov 2002 09:42:33 +0800 Message-ID: Thread-Topic: question regarding the implementation of PMTU discovery Thread-Index: AcKURzN+BqfPiABVEdeLyADQWRD0hgAR1RawABcfhqA= From: To: , , , X-OriginalArrivalTime: 26 Nov 2002 01:42:34.0669 (UTC) FILETIME=[17C435D0:01C294ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA05860 Hi, Ivan, Thanks, several more questions: 1. We should send the different sized HBs within one HB interval, is that right? 2. Currently HB can be used to test the reachability of the path of association, if suppose an HB ack for a large sized HB is not received, that may due to the too big MTU size, so we should not increase the error count of the path. Best regards, Hui Huang >-----Original Message----- >From: Arias-Rodriguez Ivan (NRC/Helsinki) >Sent: 25 November, 2002 22:47 >To: Huang Hui (Nokia-RD/Beijing); sctp-impl@external.cisco.com; >lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us >Subject: RE: question regarding the implementation of PMTU discovery > > > Hi all! > > See my comments inline... > >> -----Original Message----- >> From: ext [mailto:hui.huang@nokia.com] >> Sent: 25. November 2002 7:56 >> To: sctp-impl@external.cisco.com; >> lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us >> Subject: question regarding the implementation of PMTU discovery >> >> >> Hi, >> >> I have a question regarding the implementation of PMTU >> discovery in SCTP layer. >> >> In RFC 1191, it said that in IP layer, PMTU works by using >> the Donot fragment (DF) bit in the IP header, when the sender >> receive an ICMP Destination Unreachable messages with a code >> meaning "fragementation needed and DF set". >> >> RFC 1981 mentioned that, for TCP, a simple implementation >> could ask the IP layer for the value of PMTU each time it >> created a new segment, but this seems inefficient. >> >> While I remember La Monte had told me that may use heartbeat >> to realize PMTU discovery, does that mean sending >> heartbeat with DF bit set in IP header to discover the size of PMTU? > > This is something I have done mostly since the >beginning of SCTP... When I want to test one specific PMTU, >what I do is just sending a HB to that address. As the HB >doesn't have any structure, you can just fill it with 0s up to >the MTU you want to test (taking into account all the >headers). Of course, I sent that HEARTBEAT in a single packet >and set the DF bit (if I'm using IPv4)... > > Then, you have three options: > > a) You receive the HEARTBEAT ACK: That means that the >MTU is at least the one tested, and at the same time you also >know that the address is working. > b) You receive an ICMP packet: The MTU tested is too >big. The address might or might not be working. > c) You don't receive anything: Either the packet was >lost at some point of the network, or the MTU was so big and a >router in between simply discarded it (or the ICMP packet was >lost), or the address is down (or something else?). > > In any case, I find the use of HB very helpful because: > > a) It is really simply to do it. > b) At the same time you test the MTU you can test the >RTO and stuff (however, the b case would be the normal one, I think). > c) You can test exactly the size you want. In TCP it >might be easy to do it using the "traditional" way, as it >doesn't have any message boundaries. However, in SCTP, this is >a little bit more difficult, and you might fragment user >messages so the whole packet has the right shape... > d) And which is more important, you don't increase the >MTU beforehand, so it is not likely that you will lose >packets. With the "traditional" way of PMTU discovery, you >will normally lose some packets, and then you have to code >some mechanism that realizes that those loses are due to a big >MTU rather than because the peer is down (matching ICMPs and >sent SCTP packets or something else). > > As far as I know, many of us use this way of measuring >the PMTU. So many, that I think it might be a good idea to >even write an Internet Draft relating this. If somebody is >interested about this, I would like to take part in it... > > BR Iván Arias Rodríguez > >> Thanks! >> >> Hui Huang >> >> >> > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Nov 25 22:36:34 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 WAA07920 for ; Mon, 25 Nov 2002 22:36:32 -0500 (EST) 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 gAQ3a5Kc027880 for ; Mon, 25 Nov 2002 19:36:05 -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 gAQ3a4nu003113 for ; Mon, 25 Nov 2002 19:36:04 -0800 (PST) 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 gAQ3a0UV029848 for ; Mon, 25 Nov 2002 19:36:01 -0800 (PST) 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 gAQ3IE625933 for ; Tue, 26 Nov 2002 05:18:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Nov 2002 05:17:15 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Nov 2002 05:17:15 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Nov 2002 11:16:20 +0800 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: another question about implementing add ip Date: Tue, 26 Nov 2002 11:14:58 +0800 Message-ID: Thread-Topic: another question about implementing add ip Thread-Index: AcKSQpVCgH3BEtAlRxaDv0jqZVKFOACttSIg From: To: , Cc: X-OriginalArrivalTime: 26 Nov 2002 03:16:20.0341 (UTC) FILETIME=[30EDA250:01C294FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07920 do you mean that the receiver just ignores the "set primary path" request and doesn't give a response in ASCONF_ACK? Then what shall the sender do when it gets such an ASCONF_ACK? Send the "set primary path" request again? -----Original Message----- From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] Sent: 23 November 2002 00:01 To: Manish Rajpal Cc: Zhang Dajiang (Nokia-RD/Beijing); sctp-impl@external.cisco.com Subject: Re: another question about implementing add ip Manish Rajpal wrote: >hi > >As told in the draft, its an option that receiver SHOULD perform. If the >request can not be honored for whatsoever reasons, it can be ignored. And no >response will be taken as success by the peer. > Yes.. I agree with the above.. you ignore the set-primary that sets to an address that does not exist. >newayz, any message from the peer with such an address that does not exist >will be responded back by an abort. > > Hmm.. what does "newayz" mean? You never would send an abort to a peer that said set-primary(x) when (x) is not in the association. R >regards >manish >----- Original Message ----- >From: >To: >Cc: >Sent: Friday, November 22, 2002 2:30 PM >Subject: another question about implementing add ip > > > >hi, > >Here is another question about implementing add ip. > >If the sender requests to set primary path to an address not in its address >list by mistake, what shall the receiver do? >Which error cause should be used? > >Thanks! > >Dajiang Zhang > > > > -- 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 Nov 26 06:08: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 GAA26959 for ; Tue, 26 Nov 2002 06:08:10 -0500 (EST) 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 gAQB6CKc018867 for ; Tue, 26 Nov 2002 03:06:12 -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 gAQB5uAL008892 for ; Tue, 26 Nov 2002 03:05:58 -0800 (PST) Received: from hotmail.com (oe47.law10.hotmail.com [64.4.14.19]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gAQB63UV019922 for ; Tue, 26 Nov 2002 03:06:07 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Nov 2002 03:04:02 -0800 X-Originating-IP: [202.134.200.4] From: "Manish Rajpal" To: , Cc: References: Subject: Re: another question about implementing add ip Date: Tue, 26 Nov 2002 16:28:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 26 Nov 2002 11:04:02.0675 (UTC) FILETIME=[8761FC30:01C2953B] Content-Transfer-Encoding: 7bit No response means success, so the sender can safely assume that the address x has been made primary at the receiver. Now how come the sender is trying to set an address primary that's not a part of association is interesting part of the story :-) ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, November 26, 2002 8:44 AM Subject: RE: another question about implementing add ip do you mean that the receiver just ignores the "set primary path" request and doesn't give a response in ASCONF_ACK? Then what shall the sender do when it gets such an ASCONF_ACK? Send the "set primary path" request again? -----Original Message----- From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] Sent: 23 November 2002 00:01 To: Manish Rajpal Cc: Zhang Dajiang (Nokia-RD/Beijing); sctp-impl@external.cisco.com Subject: Re: another question about implementing add ip Manish Rajpal wrote: >hi > >As told in the draft, its an option that receiver SHOULD perform. If the >request can not be honored for whatsoever reasons, it can be ignored. And no >response will be taken as success by the peer. > Yes.. I agree with the above.. you ignore the set-primary that sets to an address that does not exist. >newayz, any message from the peer with such an address that does not exist >will be responded back by an abort. > > Hmm.. what does "newayz" mean? You never would send an abort to a peer that said set-primary(x) when (x) is not in the association. R >regards >manish >----- Original Message ----- >From: >To: >Cc: >Sent: Friday, November 22, 2002 2:30 PM >Subject: another question about implementing add ip > > > >hi, > >Here is another question about implementing add ip. > >If the sender requests to set primary path to an address not in its address >list by mistake, what shall the receiver do? >Which error cause should be used? > >Thanks! > >Dajiang Zhang > > > > -- 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 Nov 26 06:57: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 GAA27898 for ; Tue, 26 Nov 2002 06:57:19 -0500 (EST) 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 gAQBuPKc003270 for ; Tue, 26 Nov 2002 03:56:25 -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 gAQBuAMT027742 for ; Tue, 26 Nov 2002 03:56:10 -0800 (PST) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAQBuNrY002764 for ; Tue, 26 Nov 2002 03:56:24 -0800 (PST) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 26 Nov 2002 04:50:09 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Tue, 26 Nov 2002 04:49:57 -0700 From: "Shekhar Amlekar" To: Subject: Use of SCTP by a java app Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA27898 Hello, Can a java application use SCTP today ? I think the only protocols available to a java app are TCP and UDP. What then about the new transport protocols coming up ? Thanks, Shekhar From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Nov 26 18:57:02 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 SAA27501 for ; Tue, 26 Nov 2002 18:57:00 -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 gAQNuCoh008190 for ; Tue, 26 Nov 2002 15:56:12 -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 gAQNuBUu024277 for ; Tue, 26 Nov 2002 15:56:12 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gAQNu7rS016556 for ; Tue, 26 Nov 2002 15:56:08 -0800 (PST) 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 gAQNam918498 for ; Wed, 27 Nov 2002 01:36:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 01:37:23 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 01:37:23 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 01:37:22 +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="x-user-defined" Subject: RE: question regarding the implementation of PMTU discovery Date: Wed, 27 Nov 2002 01:37:21 +0200 Message-ID: Thread-Topic: question regarding the implementation of PMTU discovery Thread-Index: AcKURzN+BqfPiABVEdeLyADQWRD0hgAR1RawABcfhqAALcguEA== From: To: , , , X-OriginalArrivalTime: 26 Nov 2002 23:37:22.0983 (UTC) FILETIME=[C4DDA370:01C295A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA27501 Hi Hui Huang! See my comments inline... > -----Original Message----- > From: ext [mailto:hui.huang@nokia.com] > Sent: 26. November 2002 3:43 > To: Arias-Rodriguez Ivan (NRC/Helsinki); sctp-impl@external.cisco.com; > lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us > Subject: RE: question regarding the implementation of PMTU discovery > > > Hi, Ivan, > > Thanks, several more questions: > > 1. We should send the different sized HBs within one HB > interval, is that right? Well... This is something completely implementation dependent, so I guess that you can do mostly however you want, as far as you don't go against the specification (or not that much). As the MTU discovery RFC says that you should wait 10 minutes after the previous test if that test was unsuccessful (which is I guess, the most common case), I think that it doesn't matter that much... I think you can forget about the normal HB interval and stuff, since you are not really going to add much traffic to the network. In fact, what I do (that I doubt that it is really the right option), is that at the very beginning of the association I set the MTU to 576 and then I send HBs to test up to my own MTU (following the plateaus in RFC 1191, and sending a new HB with a bigger size right after receiving the HB ACK). When either I receive the HB ACK of the HB sent with the size of my own MTU or the HB ACK is not received, I stop this mechanism and set the MTU to the value of the size of the last HB ACK received. Then, I send new HBs after 2 or 10 minutes if the last prove was successful or unsuccessful... All this is done per address... So, after the initial check of the MTU, I have an independent timer per address, that I set to 10 minutes after sending a "prove HB". If I don't receive the HB ACK, that timer expires and I will send another "prove HB" after that time. If I receive the HB ACK, I set the MTU to the new value and I reset the timer to 2 minutes, and after that time I will make another prove... So I use the recommended time values in RFC 1191... > 2. Currently HB can be used to test the reachability of the > path of association, if suppose an HB ack for a large sized > HB is not received, that may due to the too big MTU size, so > we should not increase the error count of the path. Well, as said before, this is implementation dependent... What I do personally, is not increasing the error counter if the HB ACK is received, but I do clear it if I receive the HB ACK. What other people think about this? What other people do? Thanks! BR Iván Arias Rodríguez > Best regards, > Hui Huang > > >-----Original Message----- > >From: Arias-Rodriguez Ivan (NRC/Helsinki) > >Sent: 25 November, 2002 22:47 > >To: Huang Hui (Nokia-RD/Beijing); sctp-impl@external.cisco.com; > >lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us > >Subject: RE: question regarding the implementation of PMTU discovery > > > > > > Hi all! > > > > See my comments inline... > > > >> -----Original Message----- > >> From: ext [mailto:hui.huang@nokia.com] > >> Sent: 25. November 2002 7:56 > >> To: sctp-impl@external.cisco.com; > >> lksctp-developers@lists.sourceforge.net; piggy@baqaqi.chi.il.us > >> Subject: question regarding the implementation of PMTU discovery > >> > >> > >> Hi, > >> > >> I have a question regarding the implementation of PMTU > >> discovery in SCTP layer. > >> > >> In RFC 1191, it said that in IP layer, PMTU works by using > >> the Donot fragment (DF) bit in the IP header, when the sender > >> receive an ICMP Destination Unreachable messages with a code > >> meaning "fragementation needed and DF set". > >> > >> RFC 1981 mentioned that, for TCP, a simple implementation > >> could ask the IP layer for the value of PMTU each time it > >> created a new segment, but this seems inefficient. > >> > >> While I remember La Monte had told me that may use heartbeat > >> to realize PMTU discovery, does that mean sending > >> heartbeat with DF bit set in IP header to discover the > size of PMTU? > > > > This is something I have done mostly since the > >beginning of SCTP... When I want to test one specific PMTU, > >what I do is just sending a HB to that address. As the HB > >doesn't have any structure, you can just fill it with 0s up to > >the MTU you want to test (taking into account all the > >headers). Of course, I sent that HEARTBEAT in a single packet > >and set the DF bit (if I'm using IPv4)... > > > > Then, you have three options: > > > > a) You receive the HEARTBEAT ACK: That means that the > >MTU is at least the one tested, and at the same time you also > >know that the address is working. > > b) You receive an ICMP packet: The MTU tested is too > >big. The address might or might not be working. > > c) You don't receive anything: Either the packet was > >lost at some point of the network, or the MTU was so big and a > >router in between simply discarded it (or the ICMP packet was > >lost), or the address is down (or something else?). > > > > In any case, I find the use of HB very helpful because: > > > > a) It is really simply to do it. > > b) At the same time you test the MTU you can test the > >RTO and stuff (however, the b case would be the normal one, I think). > > c) You can test exactly the size you want. In TCP it > >might be easy to do it using the "traditional" way, as it > >doesn't have any message boundaries. However, in SCTP, this is > >a little bit more difficult, and you might fragment user > >messages so the whole packet has the right shape... > > d) And which is more important, you don't increase the > >MTU beforehand, so it is not likely that you will lose > >packets. With the "traditional" way of PMTU discovery, you > >will normally lose some packets, and then you have to code > >some mechanism that realizes that those loses are due to a big > >MTU rather than because the peer is down (matching ICMPs and > >sent SCTP packets or something else). > > > > As far as I know, many of us use this way of measuring > >the PMTU. So many, that I think it might be a good idea to > >even write an Internet Draft relating this. If somebody is > >interested about this, I would like to take part in it... > > > > BR Iván Arias Rodríguez > > > >> Thanks! > >> > >> Hui Huang > >> > >> > >> > > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Nov 27 09:41:46 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 JAA12043 for ; Wed, 27 Nov 2002 09:41:45 -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 gAREcZK0005528 for ; Wed, 27 Nov 2002 06:38:35 -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 gAREcL4r008816 for ; Wed, 27 Nov 2002 06:38:21 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id gAREc8XP005794 for ; Wed, 27 Nov 2002 06:38:09 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gARE06r18956 for ; Wed, 27 Nov 2002 19:30:08 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gARE02818945 for ; Wed, 27 Nov 2002 19:30:04 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gARE1jc16262 for ; Wed, 27 Nov 2002 19:31:46 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C7E.004C61B4 ; Wed, 27 Nov 2002 19:24:17 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: Shekhar Amlekar , "sctp-impl.external.cisco.com "@hss.hns.com Message-ID: <65256C7E.004C5FC3.00@sandesh.hss.hns.com> Date: Wed, 27 Nov 2002 19:28:39 +0530 Subject: Re: Use of SCTP by a java app Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi shekhar java has a feature that allows you to call native language functions. So whatever be the protocol, you can write some wrappers that will allow your java applications to unleash the power of sctp and other new protocols. regards manish www.hssworld.com ----- Original Message ----- From: "Shekhar Amlekar" To: Sent: Tuesday, November 26, 2002 5:19 PM Subject: Use of SCTP by a java app Hello, Can a java application use SCTP today ? I think the only protocols available to a java app are TCP and UDP. What then about the new transport protocols coming up ? Thanks, Shekhar DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Nov 27 09:48:20 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 JAA12675 for ; Wed, 27 Nov 2002 09:48:19 -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 gAREje0R027600 for ; Wed, 27 Nov 2002 06:45:40 -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 gAREjTgS012620 for ; Wed, 27 Nov 2002 06:45:29 -0800 (PST) Received: from 55.45.41.27 (node-c-3d83.a2000.nl [62.194.61.131]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id gAREjerS001395 for ; Wed, 27 Nov 2002 06:45:41 -0800 (PST) Message-Id: <200211271445.gAREjerS001395@proxy1.cisco.com> From: "Mr. Greg Karekasmart" To: sctp-impl@external.cisco.com Reply-To: greg_karefasmart@mail.com Subject: I need you urgent response/call Date: Wed, 27 Nov 2002 15:45:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5d5c7059-58f9-4ed3-afe2-193ad4fe3613" This is a multi-part message in MIME format --5d5c7059-58f9-4ed3-afe2-193ad4fe3613 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable NOTE: PLEASE DIRECT ALL RESPONSE TO EMAIL ACCOUNT CONTAINED IN THIS LETTER FOR CONFIDENTIAL PURPOSE. STRICTLY CONFIDENTIAL FROM: Mr. GREG KAREFA-SMART Tel: +234 8037 210 251 E-mail: greg_karefasmart@mail.com Attention Please, BUSINESS PARTNERSHIP SOLICITED May I take the privilege to introduce myself; I am the son of Late Dr. John = Karefa-Smart who was a renowned politician of the republic of Sierra Leone in = West Africa. I presume you are aware when a group of rebel soldiers led by = Sir. Foday Sankoh overthrew the Government of Sierra Leone forcing the = President out of power and killing a number of ministers including some = politicians. After this political crisis, My Father went into exile for safety due to = pursuance from the present government under the leadership of Alhaji Tijan = Kabbah who sees my father as an opposition to his corrupt government. My = father while in exile died, may his soul rest in peace? Before his death, he = has in his possession a treasure containing a huge sum of US$15M (Fifteen = Million, United States Dollars). Which he entrusted to me as his next of kin.= However, when it became apparently obvious that the country was no longer = safe for citizens due to political crises: massive killing and destruction of = properties, I deposited the funds with a discrete Courier/Security company = for further shipment and safe-keeping to Europe while I flee to Nigeria as a = political refugee. The Courier/Security Company based on my recommendation on = that note can only release the funds to you. Meanwhile, I am soliciting for a reliable and trust worthy person who will = serve as the guardian/investor of this fund, with whom I could plan the best = way to invest funds into a profitable business. And this is why I decide to = contact you with all hope that you will help me achieve this dream. To show = my appreciation for your assistance in actualising this business with me, I = shall give you 25% of the total money and 5% for miscellaneous expense while = the remaining 70% belong to me, which I intend to re-invest into any = profitable Business in your country. Please, I need your entire support and co-operation for the success of the = business venture, your utmost confidentially, sincerity and secrecy is highly = required, due to my family's present predicament. Details of how I intend to = carry out this project will be discussed as soon as I get a response of your = willingness and interest. I sincerely will appreciate your urgent = acknowledgment as soon as possible by contacting me on my Telephone number: = +234 8037 210 251 or E-mail address. Thank you. Yours truly, Mr. GREG KAREFA-SMART NOTE: YOUR FAX & PHONE NUMBER ARE VERY IMPORTANT, AS BUSINESS OF THIS MAGNITUDE AND NATURE IS NOT SUPPOSED TO BE DONE VIA E-MAIL. --5d5c7059-58f9-4ed3-afe2-193ad4fe3613-- From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Nov 27 14:43: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 OAA25678 for ; Wed, 27 Nov 2002 14:43:18 -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 gARJgHK2011798; Wed, 27 Nov 2002 11:42:30 -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 AAX01864; Wed, 27 Nov 2002 11:39:12 -0800 (PST) Message-ID: <3DE51F54.5000304@cisco.com> Date: Wed, 27 Nov 2002 13:39:00 -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: mrajpal@hss.hns.com CC: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <65256C7C.004F88D0.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Doing this in the kernel is very very difficult.. (see my earlier email on this subject). To get by a nat one can always just send a INIT with no addresses... After all multi-homing behind a NAT is not going to work anyway.. R mrajpal@hss.hns.com wrote: > >Hi > >The socket draft - 04 no-where specifies an option for user to provide a >hostname for an address. This >creates a problem when a multi-homed endpoint is behind a NAT. As discussed in >sctp applicabilty >statement, this requires a hostname to be sent in INIT/INIT ack. >My question is how to get a hostname for the address provided in sctp-socket >interface. > >regards >manish >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. > > > > > -- 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 Nov 27 14:45: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 OAA25718 for ; Wed, 27 Nov 2002 14:45:14 -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 gARJXM0T003733; Wed, 27 Nov 2002 11:34: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 AAX01560; Wed, 27 Nov 2002 11:33:23 -0800 (PST) Message-ID: <3DE51DF9.5040304@cisco.com> Date: Wed, 27 Nov 2002 13:33:13 -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: mrajpal@hss.hns.com CC: sctp-impl@external.cisco.com Subject: Re: MSG_ABORT flag in sendmsg call References: <65256C7C.00491DAE.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mrajpal@hss.hns.com wrote: > >Hi > >The socket draft - 04 says: > >"whenever sendmsg() or sendto is called and the sctp stack at the sender finds >that there are > no associations between the sender and intended receiver, the stack will >automatically > setup an association to the intended receiver." > > Well yes if you send on a udp-style socket this is the required behavior.. I am guessing you meant to include "on a udp-style socket" in your query above... >Now my question is what if user has called sendmsg with MSG_ABORT flag set . >should an >implementation right away reject the request or should it establish an >asociation just to abort the >association. > > I don't follow you here do you mean: 1) An association exists and the user calls a) send_msg(MSG_ABORT) b) send_msg(some new message) or 2) No association exists and then the users calls a) send_msg(MSG_ABORT); For 1 it is logical that you setup an association... for 2) I would think you probably do NOT want to setup an association.. but this is implementation dependant.. one could I guess but I don't see the point (much less the point of why a user would do this anyway).. R >regards >Manish > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. > > > > > -- 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 Nov 27 23:00: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 XAA08111 for ; Wed, 27 Nov 2002 23:00: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 gAS3wOK0025971 for ; Wed, 27 Nov 2002 19:58:24 -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 gAS3wN3X011376 for ; Wed, 27 Nov 2002 19:58:23 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id gAS3wLOd007124 for ; Wed, 27 Nov 2002 19:58:22 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAS3K4r09119 for ; Thu, 28 Nov 2002 08:50:04 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAS3K3809115; Thu, 28 Nov 2002 08:50:03 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAS3Lm606949; Thu, 28 Nov 2002 08:51:48 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C7F.0011C956 ; Thu, 28 Nov 2002 08:44:16 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: "Randall Stewart (cisco)" cc: sctp-impl@external.cisco.com Message-ID: <65256C7F.0011C76D.00@sandesh.hss.hns.com> Date: Thu, 28 Nov 2002 08:48:40 +0530 Subject: Re: Multihoming with NAT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi, I don't think so, multihoming can work very well behind a NAT too. if NAT can translate one address, it can translate n addresses. I don't foresee any issue. In fact, with NAT, its possible that a host running sctp and having single address can appear as a multihomed host to the peer. Only NAT box has to Map both the external addresses to a single internal address. regards manish www.hssworld.com "Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM To: Manish Rajpal/HSS@HSS cc: sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT Doing this in the kernel is very very difficult.. (see my earlier email on this subject). To get by a nat one can always just send a INIT with no addresses... After all multi-homing behind a NAT is not going to work anyway.. R mrajpal@hss.hns.com wrote: > >Hi > >The socket draft - 04 no-where specifies an option for user to provide a >hostname for an address. This >creates a problem when a multi-homed endpoint is behind a NAT. As discussed in >sctp applicabilty >statement, this requires a hostname to be sent in INIT/INIT ack. >My question is how to get a hostname for the address provided in sctp-socket >interface. > >regards >manish >www.hssworld.com > >DISCLAIMER: This message is proprietary to Hughes Software Systems >Limited (HSS) and is intended solely for the use of the individual >to whom it is addressed. It may contain privileged or confidential >information and should not be circulated or used for any purpose other >than for what it is intended. If you have received this message in error, >please notify the originator immediately. If you are not the intended >recipient, you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. HSS accepts >no responsibility for loss or damage arising from the use of the information >transmitted by this email including damage from virus. > > > > > -- 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 Nov 28 08:00: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 IAA27116 for ; Thu, 28 Nov 2002 08:00:14 -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 gASCqTcb024118 for ; Thu, 28 Nov 2002 04:52: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 gASCqPoL005332 for ; Thu, 28 Nov 2002 04:52:29 -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 gASCq3XP023255 for ; Thu, 28 Nov 2002 04:52:04 -0800 (PST) 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 gASCX2927096 for ; Thu, 28 Nov 2002 14:33:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 14:33:36 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:33:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 14:33:35 +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: Multihoming with NAT Date: Thu, 28 Nov 2002 14:33:35 +0200 Message-ID: Thread-Topic: Multihoming with NAT Thread-Index: AcKWk599y5uATL9zQ0+m+WdaB0MjeQARcUxA From: To: , Cc: X-OriginalArrivalTime: 28 Nov 2002 12:33:35.0735 (UTC) FILETIME=[5ECD6070:01C296DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27116 Hi! > hi, > > I don't think so, multihoming can work very well behind a NAT > too. if NAT can > translate one address, it can translate n addresses. I don't I think this is precisely the problem... NATs don't know anything about SCTP, so at most they can translate the source address of the IP packet. All the deployed NATs are not ready to recognize Protocol Number 132 and then look inside every of such packets and recognize an INIT/INT ACK chunk, so it can dig inside the packet and recognize de address parameters... Of course, if you re-code a NAT to do such thing, I think it would work... :-/ But, who is the one that is going to re-code all the existing NATs...? Besides, I don't really think that having multihoming while being behind a NAT is really anything useful... I'm not an expert, but I would say that you normally have only one NAT that is "covering" a stub domain. It means that all the packets have to go anyway through the NAT... Well, you can always have several netwok cards, and then multihoming would prevent failure if one of the cards itself fails, but it won't prevent about misbehaving routers in the way... > foresee any issue. > In fact, with NAT, its possible that a host running sctp and > having single > address can appear as a multihomed host to the peer. Only NAT > box has to Map > both the external addresses to a single internal address. But it has to be able to do so... which is not true so far... BR Iván Arias Rodríguez > regards > manish > www.hssworld.com > > > > > "Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM > > To: Manish Rajpal/HSS@HSS > cc: sctp-impl@external.cisco.com > > Subject: Re: Multihoming with NAT > > > > > Doing this in the kernel is very very difficult.. (see my > earlier email on > this subject). > > To get by a nat one can always just send a INIT with no addresses... > After all multi-homing behind a NAT is not going to work anyway.. > > R > > mrajpal@hss.hns.com wrote: > > > > >Hi > > > >The socket draft - 04 no-where specifies an option for user > to provide a > >hostname for an address. This > >creates a problem when a multi-homed endpoint is behind a > NAT. As discussed in > >sctp applicabilty > >statement, this requires a hostname to be sent in INIT/INIT ack. > >My question is how to get a hostname for the address > provided in sctp-socket > >interface. > > > >regards > >manish > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any > purpose other > >than for what it is intended. If you have received this > message in error, > >please notify the originator immediately. If you are not the intended > >recipient, you are notified that you are strictly prohibited > from using, > >copying, altering, or disclosing the contents of this > message. HSS accepts > >no responsibility for loss or damage arising from the use of > the information > >transmitted by this email including damage from virus. > > > > > > > > > > > > > -- > 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 Nov 28 08:39: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 IAA27768 for ; Thu, 28 Nov 2002 08:39:09 -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 gASDcIK0028936 for ; Thu, 28 Nov 2002 05:38:18 -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 gASDc4nC027958 for ; Thu, 28 Nov 2002 05:38:04 -0800 (PST) Received: from hindon.hss.co.in ([202.54.26.202]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id gASDcDrS011249 for ; Thu, 28 Nov 2002 05:38:15 -0800 (PST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gASCxvr10804 for ; Thu, 28 Nov 2002 18:29:58 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gASCxv810800; Thu, 28 Nov 2002 18:29:57 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gASD1fR13145; Thu, 28 Nov 2002 18:31:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C7F.0046DF3F ; Thu, 28 Nov 2002 18:24:06 +0530 X-Lotus-FromDomain: HSS From: mrajpal@hss.hns.com To: Ivan.Arias-Rodriguez@nokia.com cc: rrs@cisco.com, sctp-impl@external.cisco.com Message-ID: <65256C7F.0046DEAF.00@sandesh.hss.hns.com> Date: Thu, 28 Nov 2002 18:28:32 +0530 Subject: RE: Multihoming with NAT Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=BEsC2MdLCdeWrG02YYjAHoyL2iqUaD5dNFtVP2HUI2wGyO9UO3KUY5G5" Content-Disposition: inline --0__=BEsC2MdLCdeWrG02YYjAHoyL2iqUaD5dNFtVP2HUI2wGyO9UO3KUY5G5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi No! you don't need a SCTP aware NAT, lets suppose NAT has two addresses, then both these addresses can be used for the association. The packets sent by the peer to any of these addresses will be routed to the sctp host which has got a single address. So u have a multihomed association without the host having more than one address. about the misbehaving routers, i'ld like say that its the multihoming that comes to rescue when you have diffrent addresses belonging to different networks, So while one network is not in good health the packets can take diffrent route to reach destination. Its just that the INIT/INIT ACK chunks that communicate the addresses to the peer and if we can send a hostname, we can create the multi-homed association. Only restrition I see is dynamically adding or delteting IP addresses from such an association. And if NAT is sctp aware, which is least likely, you don't even need the hostname as the NAT can itself translate the addresses in INIT/INIT-ACK. So we don't require anything new from existing NAT box, all that is required is to send a hostname in the INIT/ INIT ACK that will be resolved to the address(es) of NAT. So probably a new interface that allows a user to specify a hostname for a socket to bind to. If the NAT io regards manish www.hssworld.com Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM To: Manish Rajpal/HSS@HSS, rrs@cisco.com cc: sctp-impl@external.cisco.com Subject: RE: Multihoming with NAT Hi! > hi, > > I don't think so, multihoming can work very well behind a NAT > too. if NAT can > translate one address, it can translate n addresses. I don't I think this is precisely the problem... NATs don't know anything about SCTP, so at most they can translate the source address of the IP packet. All the deployed NATs are not ready to recognize Protocol Number 132 and then look inside every of such packets and recognize an INIT/INT ACK chunk, so it can dig inside the packet and recognize de address parameters... Of course, if you re-code a NAT to do such thing, I think it would work... :-/ But, who is the one that is going to re-code all the existing NATs...? Besides, I don't really think that having multihoming while being behind a NAT is really anything useful... I'm not an expert, but I would say that you normally have only one NAT that is "covering" a stub domain. It means that all the packets have to go anyway through the NAT... Well, you can always have several netwok cards, and then multihoming would prevent failure if one of the cards itself fails, but it won't prevent about misbehaving routers in the way... > foresee any issue. > In fact, with NAT, its possible that a host running sctp and > having single > address can appear as a multihomed host to the peer. Only NAT > box has to Map > both the external addresses to a single internal address. But it has to be able to do so... which is not true so far... BR Iv --0__=BEsC2MdLCdeWrG02YYjAHoyL2iqUaD5dNFtVP2HUI2wGyO9UO3KUY5G5 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =E1n Arias Rodr=EDguez > regards > manish > www.hssworld.com > > > > > "Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM > > To: Manish Rajpal/HSS@HSS > cc: sctp-impl@external.cisco.com > > Subject: Re: Multihoming with NAT > > > > > Doing this in the kernel is very very difficult.. (see my > earlier email on > this subject). > > To get by a nat one can always just send a INIT with no addresses... > After all multi-homing behind a NAT is not going to work anyway.. > > R > > mrajpal@hss.hns.com wrote: > > > > >Hi > > > >The socket draft - 04 no-where specifies an option for user > to provide a > >hostname for an address. This > >creates a problem when a multi-homed endpoint is behind a > NAT. As discussed in > >sctp applicabilty > >statement, this requires a hostname to be sent in INIT/INIT ack. > >My question is how to get a hostname for the address > provided in sctp-socket > >interface. > > > >regards > >manish > >www.hssworld.com > > > >DISCLAIMER: This message is proprietary to Hughes Software Systems > >Limited (HSS) and is intended solely for the use of the individual > >to whom it is addressed. It may contain privileged or confidential > >information and should not be circulated or used for any > purpose other > >than for what it is intended. If you have received this > message in error, > >please notify the originator immediately. If you are not the intende= d > >recipient, you are notified that you are strictly prohibited > from using, > >copying, altering, or disclosing the contents of this > message. HSS accepts > >no responsibility for loss or damage arising from the use of > the information > >transmitted by this email including damage from virus. > > > > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > > > > > = --0__=BEsC2MdLCdeWrG02YYjAHoyL2iqUaD5dNFtVP2HUI2wGyO9UO3KUY5G5-- From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Thu Nov 28 09:30:35 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 JAA28424 for ; Thu, 28 Nov 2002 09:30:34 -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 gASETdcb019963 for ; Thu, 28 Nov 2002 06:29:39 -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 gASETcYD005639 for ; Thu, 28 Nov 2002 06:29:39 -0800 (PST) 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 gASETYrS023076 for ; Thu, 28 Nov 2002 06:29:35 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gASEBp609595 for ; Thu, 28 Nov 2002 16:11:51 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 16:10:49 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 16:10:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 16:10:44 +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: Multihoming with NAT Date: Thu, 28 Nov 2002 16:10:42 +0200 Message-ID: Thread-Topic: Multihoming with NAT Thread-Index: AcKW45G5FMsgBoh/SqWGe/V1wI2ceQAAlZgw From: To: Cc: , X-OriginalArrivalTime: 28 Nov 2002 14:10:44.0034 (UTC) FILETIME=[F0BD3A20:01C296E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA28424 Hi! > hi > > No! you don't need a SCTP aware NAT, lets suppose NAT has two > addresses, then > both these addresses can be used for the association. The > packets sent by the > peer to any of these addresses will be routed to the sctp > host which has got a > single address. So u have a multihomed association without > the host having more > than one address. I must confess that I really never completely understood how NATs and DNS are compatible... NATs allocate address for the use of a host during a certain time... so, are NATs changing DNS entries every time they assign different addresses to different hosts? And they have to do this so everybody can know... I don't really know how this can work... :-/ Unless DNS entries are only given to "static" hosts that have regular access to the "outside world" and that always use the same addresses... > about the misbehaving routers, i'ld like say that its the > multihoming that comes > to rescue when you have diffrent addresses belonging to > different networks, So > while one network is not in good health the packets can take > diffrent route to > reach destination. But at the end, all the packets have to go to the same destination: the NAT. Well, the NAT can be connected easily to different networks... yes you are right... > Its just that the INIT/INIT ACK chunks that communicate the > addresses to the > peer and if we can send a hostname, we can create the > multi-homed association. Could you please quickly explain me how DNS and NATs are compatible? I just don't know and feel lazy to check RFCs... :-) > Only restrition I see is dynamically adding or delteting IP > addresses from such > an association. Yes, that's right... Unless you change the DNS entry and then you send in the ASCONF not the IP address but the host name... I don't think anybody would support this... and I don't think it is feasible either... > And if NAT is sctp aware, which is least likely, you don't > even need the > hostname as the NAT can itself translate the addresses in > INIT/INIT-ACK. > So we don't require anything new from existing NAT box, all > that is required is > to send a hostname in the INIT/ INIT ACK that will be resolved to the > address(es) of NAT. So probably a new interface that allows a > user to specify a > hostname for a socket to bind to. If the NAT io Seems that the message was truncated... BR Iván Arias Rodríguez > regards > manish > www.hssworld.com > > > > > > Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > > To: Manish Rajpal/HSS@HSS, rrs@cisco.com > cc: sctp-impl@external.cisco.com > > Subject: RE: Multihoming with NAT > > > > > Hi! > > > hi, > > > > I don't think so, multihoming can work very well behind a NAT > > too. if NAT can > > translate one address, it can translate n addresses. I don't > > I think this is precisely the problem... NATs don't know > anything about > SCTP, so at most they can translate the source address of the > IP packet. All the > deployed NATs are not ready to recognize Protocol Number 132 > and then look > inside every of such packets and recognize an INIT/INT ACK > chunk, so it can dig > inside the packet and recognize de address parameters... > > Of course, if you re-code a NAT to do such thing, I > think it would work... > :-/ But, who is the one that is going to re-code all the > existing NATs...? > > Besides, I don't really think that having multihoming > while being behind a > NAT is really anything useful... I'm not an expert, but I > would say that you > normally have only one NAT that is "covering" a stub domain. > It means that all > the packets have to go anyway through the NAT... Well, you > can always have > several netwok cards, and then multihoming would prevent > failure if one of the > cards itself fails, but it won't prevent about misbehaving > routers in the way... > > > foresee any issue. > > In fact, with NAT, its possible that a host running sctp and > > having single > > address can appear as a multihomed host to the peer. Only NAT > > box has to Map > > both the external addresses to a single internal address. > > But it has to be able to do so... which is not true so far... > > BR Iv > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Thu Nov 28 20:21: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 UAA07922 for ; Thu, 28 Nov 2002 20:21:56 -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 gAT1LTK0025072; Thu, 28 Nov 2002 17:21: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 AAX25264; Thu, 28 Nov 2002 17:21:27 -0800 (PST) Message-ID: <3DE6C10A.5020300@cisco.com> Date: Thu, 28 Nov 2002 19:21: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: mrajpal@hss.hns.com CC: Ivan.Arias-Rodriguez@nokia.com, sctp-impl@external.cisco.com Subject: Re: Multihoming with NAT References: <65256C7F.0046DEAF.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Manish: I think you miss my point... To have an effective NAT arrangement where multi-homing is going (i.e. you want no single point of failure): host -------nat1 ------ISP1 | +----------nat2-------ISP2 Having host -----net1----NAT-------ISP | | +----------net2----+ makes two different single points of failure .. aka the NAT itself as well as your ISP Moving the two ISPs to talk to one NAT does not help since you still have a single point of failure.. and it does not work anyway.. Most nats can only handle translating to one address... I have this arrangment in my own router/nat box... It has two ISP's hooked to it and I must run two different instances of the nat software.. one for one interface and the other for the second... these two do NOT know how to communicate about the two networks...This is what is hard.. you must get the NAT's to talk to each other and reserve the SAME port on two seperate networks and setup state. There may be some nat software out there that can handle two networks but this is the rarity if it even exits... Yes it can work.. without this.. but not with multihoming in the picture.. except maybe behind the nat (my second drawing).. and in this case it does not really help you that much ... and one can just do the send the INIT with no addresses... I don't see how you could get any benefit of the two internal addresses without external addresses to go with them... Remember a SCTP association is only on ONE port and a NAT uses the ports to find the state... So my second picture gets NO benefit and the second requires intra-nat communications... And if you really wanted it done right you would need to have the nats on seperate boxes with a intra-nat communication protocol so you would have no single point of failure.. not one nat controlling two addresses... which I don't know if it even exits.... R mrajpal@hss.hns.com wrote: > >hi > >No! you don't need a SCTP aware NAT, lets suppose NAT has two addresses, then >both these addresses can be used for the association. The packets sent by the >peer to any of these addresses will be routed to the sctp host which has got a >single address. So u have a multihomed association without the host having more >than one address. >about the misbehaving routers, i'ld like say that its the multihoming that comes >to rescue when you have diffrent addresses belonging to different networks, So >while one network is not in good health the packets can take diffrent route to >reach destination. >Its just that the INIT/INIT ACK chunks that communicate the addresses to the >peer and if we can send a hostname, we can create the multi-homed association. >Only restrition I see is dynamically adding or delteting IP addresses from such >an association. > >And if NAT is sctp aware, which is least likely, you don't even need the >hostname as the NAT can itself translate the addresses in INIT/INIT-ACK. >So we don't require anything new from existing NAT box, all that is required is >to send a hostname in the INIT/ INIT ACK that will be resolved to the >address(es) of NAT. So probably a new interface that allows a user to specify a >hostname for a socket to bind to. If the NAT io > >regards >manish >www.hssworld.com > > > > > >Ivan.Arias-Rodriguez@nokia.com on 11/28/2002 06:03:35 PM > >To: Manish Rajpal/HSS@HSS, rrs@cisco.com >cc: sctp-impl@external.cisco.com > >Subject: RE: Multihoming with NAT > > > > > Hi! > > > >>hi, >> >>I don't think so, multihoming can work very well behind a NAT >>too. if NAT can >>translate one address, it can translate n addresses. I don't >> >> > > I think this is precisely the problem... NATs don't know anything about >SCTP, so at most they can translate the source address of the IP packet. All the >deployed NATs are not ready to recognize Protocol Number 132 and then look >inside every of such packets and recognize an INIT/INT ACK chunk, so it can dig >inside the packet and recognize de address parameters... > > Of course, if you re-code a NAT to do such thing, I think it would work... >:-/ But, who is the one that is going to re-code all the existing NATs...? > > Besides, I don't really think that having multihoming while being behind a >NAT is really anything useful... I'm not an expert, but I would say that you >normally have only one NAT that is "covering" a stub domain. It means that all >the packets have to go anyway through the NAT... Well, you can always have >several netwok cards, and then multihoming would prevent failure if one of the >cards itself fails, but it won't prevent about misbehaving routers in the way... > > > >>foresee any issue. >>In fact, with NAT, its possible that a host running sctp and >>having single >>address can appear as a multihomed host to the peer. Only NAT >>box has to Map >>both the external addresses to a single internal address. >> >> > > But it has to be able to do so... which is not true so far... > > BR Iv > >------------------------------------------------------------------------ > > >án Arias Rodríguez > > > >>regards >>manish >>www.hssworld.com >> >> >> >> >>"Randall Stewart (cisco)" on 11/28/2002 01:09:00 AM >> >>To: Manish Rajpal/HSS@HSS >>cc: sctp-impl@external.cisco.com >> >>Subject: Re: Multihoming with NAT >> >> >> >> >>Doing this in the kernel is very very difficult.. (see my >>earlier email on >>this subject). >> >>To get by a nat one can always just send a INIT with no addresses... >>After all multi-homing behind a NAT is not going to work anyway.. >> >>R >> >>mrajpal@hss.hns.com wrote: >> >> >> >>>Hi >>> >>>The socket draft - 04 no-where specifies an option for user >>> >>> >>to provide a >> >> >>>hostname for an address. This >>>creates a problem when a multi-homed endpoint is behind a >>> >>> >>NAT. As discussed in >> >> >>>sctp applicabilty >>>statement, this requires a hostname to be sent in INIT/INIT ack. >>>My question is how to get a hostname for the address >>> >>> >>provided in sctp-socket >> >> >>>interface. >>> >>>regards >>>manish >>>www.hssworld.com >>> >>>DISCLAIMER: This message is proprietary to Hughes Software Systems >>>Limited (HSS) and is intended solely for the use of the individual >>>to whom it is addressed. It may contain privileged or confidential >>>information and should not be circulated or used for any >>> >>> >>purpose other >> >> >>>than for what it is intended. If you have received this >>> >>> >>message in error, >> >> >>>please notify the originator immediately. If you are not the intended >>>recipient, you are notified that you are strictly prohibited >>> >>> >>from using, >> >> >>>copying, altering, or disclosing the contents of this >>> >>> >>message. HSS accepts >> >> >>>no responsibility for loss or damage arising from the use of >>> >>> >>the information >> >> >>>transmitted by this email including damage from virus. >>> >>> >>> >>> >>> >>> >>> >>-- >>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-1.cisco.com Thu Nov 28 20:27:01 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 UAA07959 for ; Thu, 28 Nov 2002 20:27:00 -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 gAT1QKK0025954; Thu, 28 Nov 2002 17:26:20 -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 AAX25274; Thu, 28 Nov 2002 17:26:19 -0800 (PST) Message-ID: <3DE6C22F.7020508@cisco.com> Date: Thu, 28 Nov 2002 19:26:07 -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: dajiang.zhang@nokia.com CC: h_s_i_n_a_m@hotmail.com, sctp-impl@external.cisco.com Subject: Re: another question about implementing add ip References: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Set primary is always at the receivers option... in the ASCONF ack it does not mean you honored the request ... you may understand it and ack it but you do NOT have to do it... R dajiang.zhang@nokia.com wrote: >do you mean that the receiver just ignores the "set primary path" request and doesn't give a response in ASCONF_ACK? >Then what shall the sender do when it gets such an ASCONF_ACK? Send the "set primary path" request again? > >-----Original Message----- >From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] >Sent: 23 November 2002 00:01 >To: Manish Rajpal >Cc: Zhang Dajiang (Nokia-RD/Beijing); sctp-impl@external.cisco.com >Subject: Re: another question about implementing add ip > > >Manish Rajpal wrote: > > > >>hi >> >>As told in the draft, its an option that receiver SHOULD perform. If the >>request can not be honored for whatsoever reasons, it can be ignored. And no >>response will be taken as success by the peer. >> >> >> > >Yes.. I agree with the above.. you ignore the set-primary that sets to >an address that does >not exist. > > > >>newayz, any message from the peer with such an address that does not exist >>will be responded back by an abort. >> >> >> >> > >Hmm.. what does "newayz" mean? You never would send an abort to a peer >that said >set-primary(x) when (x) is not in the association. > >R > > > >>regards >>manish >>----- Original Message ----- >>From: >>To: >>Cc: >>Sent: Friday, November 22, 2002 2:30 PM >>Subject: another question about implementing add ip >> >> >> >>hi, >> >>Here is another question about implementing add ip. >> >>If the sender requests to set primary path to an address not in its address >>list by mistake, what shall the receiver do? >>Which error cause should be used? >> >>Thanks! >> >>Dajiang Zhang >> >> >> >> >> >> > > > > -- 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 Nov 28 20:35:06 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 UAA08097 for ; Thu, 28 Nov 2002 20:35:05 -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 gAT1T10R009467; Thu, 28 Nov 2002 17:29:01 -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 AAX25278; Thu, 28 Nov 2002 17:29:03 -0800 (PST) Message-ID: <3DE6C2D3.7040306@cisco.com> Date: Thu, 28 Nov 2002 19:28:51 -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: Manish Rajpal CC: dajiang.zhang@nokia.com, sctp-impl@external.cisco.com Subject: Re: another question about implementing add ip References: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Manish Rajpal wrote: >No response means success, so the sender can safely assume that the address >x has been made primary at the receiver. Now how come the sender is trying >to set an address primary that's not a part of association is interesting >part of the story :-) > It is a BUGGY peer first and formost... Now as far as setting primary saying ASCONF-ACK does not mean you accept the peers judgment of what should be primary... I can acknowledge your opinion.. but it does not mean that I agree with it.. It is always possible the receiver of the set-primary has some better knowledge of what should be primary than the sender... this is why it is optional for the receiver to do anything with it. Realistically the sender probably knows best and so in my implementation I always do the change of primary (if it is possible)... it is NOT possible if the address is not part of the association... R >----- Original Message ----- >From: >To: ; >Cc: >Sent: Tuesday, November 26, 2002 8:44 AM >Subject: RE: another question about implementing add ip > > >do you mean that the receiver just ignores the "set primary path" request >and doesn't give a response in ASCONF_ACK? >Then what shall the sender do when it gets such an ASCONF_ACK? Send the >"set primary path" request again? > >-----Original Message----- >From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] >Sent: 23 November 2002 00:01 >To: Manish Rajpal >Cc: Zhang Dajiang (Nokia-RD/Beijing); sctp-impl@external.cisco.com >Subject: Re: another question about implementing add ip > > >Manish Rajpal wrote: > > > >>hi >> >>As told in the draft, its an option that receiver SHOULD perform. If the >>request can not be honored for whatsoever reasons, it can be ignored. And >> >> >no > > >>response will be taken as success by the peer. >> >> >> > >Yes.. I agree with the above.. you ignore the set-primary that sets to >an address that does >not exist. > > > >>newayz, any message from the peer with such an address that does not exist >>will be responded back by an abort. >> >> >> >> > >Hmm.. what does "newayz" mean? You never would send an abort to a peer >that said >set-primary(x) when (x) is not in the association. > >R > > > >>regards >>manish >>----- Original Message ----- >>From: >>To: >>Cc: >>Sent: Friday, November 22, 2002 2:30 PM >>Subject: another question about implementing add ip >> >> >> >>hi, >> >>Here is another question about implementing add ip. >> >>If the sender requests to set primary path to an address not in its address >>list by mistake, what shall the receiver do? >>Which error cause should be used? >> >>Thanks! >> >>Dajiang Zhang >> >> >> >> >> >> > > >-- >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)