From owner-sctp-impl@cisco.com Wed Sep 18 13:47:36 2002 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23387 for ; Wed, 18 Sep 2002 13:47:35 -0400 (EDT) Received: (daemon@localhost) by cliff.cisco.com (8.6.12/8.6.5) id KAA17009; Wed, 18 Sep 2002 10:48:51 -0700 Date: Wed, 18 Sep 2002 10:48:51 -0700 Message-Id: <200209181748.KAA17009@cliff.cisco.com> To: sctp-impl-archive@ietf.org From: mailer@cisco.com Subject: Welcome to sctp-impl Precedence: bulk Reply-To: mailer@cisco.com -- Welcome to the sctp-impl mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "mailer@cisco.com" with the following command in the body of your email message: unsubscribe sctp-impl sctp-impl-archive@ietf.org Here's the general information for the list you've subscribed to, in case you don't already have it: [Last updated on: Fri Aug 2 15:45:28 PDT 2002] This list is EXTERNAL and is used for querys and questions to implementing SCTP. It is provided as a service to the IETF by Cisco Systems Inc. Views expressed on this list may NOT be the views of Cisco Systems :> To post to this list please send email to sctp-impl@external.cisco.com. Happy SCTP'ing :> From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Sep 20 07:02:53 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18315 for ; Fri, 20 Sep 2002 07:02:52 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KAkF3x020650 for ; Fri, 20 Sep 2002 03:46:15 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KAkKGm001348 for ; Fri, 20 Sep 2002 03:46:20 -0700 (PDT) Received: from gatekeeper3.emailsolutions.com ([199.232.85.131]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g8KAkGZ3027510 for ; Fri, 20 Sep 2002 03:46:16 -0700 (PDT) Received: (from root@localhost) by gatekeeper3.emailsolutions.com (8.11.6/8.11.6) id g8KAdiv18592; Fri, 20 Sep 2002 06:39:44 -0400 Received: from jnkh78t76 (da001d2108.cam-ma.osd.concentric.net [207.88.96.62]) by gatekeeper3.emailsolutions.com (8.11.6/8.11.6) with ESMTP id g8KAdOd18505; Fri, 20 Sep 2002 06:39:24 -0400 Message-Id: <200209201039.g8KAdOd18505@gatekeeper3.emailsolutions.com> From: "Greg Sardris" Subject: Any Question To: <#field0#@gatekeeper3.emailsolutions.com> Date: Thu, 19 Sep 2002 17:19:20 -0500 X-Mailer: Mozilla 4.73 [en] (Win95; I) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=29.2 required=3.8 tests=TO_MALFORMED,HOME_EMPLOYMENT,RISK_FREE,DOUBLE_CAPSWORD, NO_OBLIGATION,CLICK_BELOW,SUBJ_REMOVE,LINES_OF_YELLING, MAILTO_WITH_SUBJ,MAILTO_TO_SPAM_ADDR,MAILTO_TO_REMOVE, MAILTO_WITH_SUBJ_REMOVE,FRONTPAGE,BIG_FONT, FORM_W_MAILTO_ACTION,MAILTO_LINK,FREQ_SPAM_PHRASE, MSG_ID_ADDED_BY_MTA_3 version=2.31 X-Spam-Flag: YES X-Spam-Level: ***************************** X-Spam-Report: 29.2 hits, 3.8 required; * 1.1 -- To: has a malformed address * 2.9 -- BODY: Information on how to work at home (2) * 1.9 -- BODY: Risk free. Suuurreeee.... * 1.1 -- BODY: A word in all caps repeated on the line * 1.9 -- BODY: There is no obligation. * 1.5 -- BODY: Asks you to click below * -0.8 -- BODY: List removal information * -0.0 -- BODY: A WHOLE LINE OF YELLING DETECTED * 1.9 -- URI: Includes a link to send a mail with a subject * 0.5 -- URI: Includes a link to a likely spammer email address * -1.7 -- URI: Includes a 'remove' email address * 4.9 -- URI: Includes a URL link to send an email with the subject 'remove' * 4.4 -- BODY: Frontpage used to create the message * 2.1 -- BODY: FONT Size +2 and up or 3 and up * 3.2 -- BODY: Includes a form which will send an email * 0.8 -- BODY: Includes a URL link to send an email * 2.4 -- Contains phrases frequently found in spam [score: 15, hits: accept credit, all] [information, based business, click here, credit] [card, credit cards, credit rating, email] [address, fair poor, fill out, for any, for your,] [free shipping, get your, good fair, home based,] [home phone, list removal, merchant account, one] [our, order phone, phone number, that you, with] [risk, you like, you with, your business, your] [name] * 1.1 -- 'Message-Id' was added by a relay (3) This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNET - HOME BASED - MAIL ORDER - PHONE ORDER Do you accept credit cards? Your competition does!   Everyone Approved - Credit Problems OK! Approval in less than 24 hours! Increase your sales by 300% Start Accepting Credit Cards on your website! Free Information, No Risk, 100% confidential=2E Your name and information will not be sold to third parties! Home Businesses OK! Phone/Mail Order OK! No Application Fee, No Setup Fee! Close More Impulse Sales! Everyone Approved! Good Credit or Bad!  To apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For area's that do not apply to you please put "n/a" in the box=2E Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we can have your account approved within 24 hours=2E  Service Industry Standard US Site Inspection $50 - $75 FREE Shipping $50 - $75 FREE Warranty $10 Per Month FREE Sales Receipts $10 - $50  FREE Fraud Screening $=2E50 - $1=2E00 Per Transaction FREE Amex Set Up $50 - $75 FREE 24 Hour Help Line $10 Month FREE Security Bond $5000- $10,000 Or More NONE This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will "not enter" in to any obligations or contracts with us=2E We will use it to determine the best program to offer you based on the information you provide=2E You will be contacted by one of our representatives within 1-2 business days to go over the rest of your account set up=2E Note:  All Information Provided To Us Will Remain 100% Confidential !!  Apply Free With No Risk! Please fill out the express application form completely=2EIncomplete information may prevent us from properly processing your application=2E Your Full Email Address: be sure to use your full address (i=2Ee=2E user@domain=2Ecom) Your Name: Business Name: Business Phone Number: Home Phone Number: Type of Business: Retail Business Mail Order Business Internet Based Business Personal Credit Rating: Excellent Good Fair Poor How Soon Would You Like a Merchant Account? Your information is confidential, it will not be sold or used for any other purpose, and you are under no obligation=2E Your information will be used solely for the purpose of evaluating your business or website for a merchant account so that you may begin accepting credit card payments=2E List Removal/OPT-OUT Option Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

Do you accept credit cards? Your competition does!

 

Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to third parties!
Home Businesses OK! Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!

Everyone Approved!

Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
 

Service Industry Standard

US
Site Inspection $50 - $75 FREE
Shipping $50 - $75 FREE
Warranty $10 Per Month= FREE
Sales Receipts $10 - $50&nbs= p; FREE
Fraud Screening

$=2E50 - $1=2E00
Per Transaction

 FREE
Amex Set Up $50 - $75 FREE
24 Hour Help Line $10 Month FREE
Security Bond $5000- $10,00= 0
Or More		 NONE

This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

<= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

Apply Free With No Risk!

Pleas= e fill out the express application form completely=2E
Incomplete information m= ay prevent us from properly processing your application=2E
Your Full Emai= l Address:
be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
Your Name:
Business Name:=
Business Phone= Number:
Home Phone Num= ber:
Type of Busine= ss:
Retail Business
Mail Order Business
Internet Based Busines= s
Personal Credi= t Rating:
Excellent
Good
Fair
Poor
How Soon Would= You Like a Merchant Account?


Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Fri Sep 20 10:57:14 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24892 for ; Fri, 20 Sep 2002 10:57:14 -0400 (EDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8KEpZ3x002786 for ; Fri, 20 Sep 2002 07:51:36 -0700 (PDT) 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 QAA05164 for ; Fri, 20 Sep 2002 16:51:39 +0200 (MET DST) Received: (qmail 445 invoked by uid 1000); 20 Sep 2002 14:51:35 -0000 Message-ID: <20020920145135.444.qmail@cobweb.example.org> Date: Fri, 20 Sep 2002 16:51:35 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: Q. on draft-ietf-tsvwg-sctpsocket-04.txt X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randall :-) section 5.3 of draft-ietf-tsvwg-sctpsocket-04.txt says: 1209 Multiple notifications may be returned to a single recvmsg() 1210 call. and then: 1216 A recvmsg() call will return only one notification at a time. Just which is correct ? thanks Marco 1192 5.3 SCTP Events and Notifications 1193 1194 An SCTP application may need to understand and process events and 1195 errors that happen on the SCTP stack. These events include network 1196 status changes, association startups, remote operational errors and 1197 undeliverable messages. All of these can be essential for the 1198 application. 1199 1200 When an SCTP application layer does a recvmsg() the message read is 1201 normally a data message from a peer endpoint. If the application 1202 wishes to have the SCTP stack deliver notifications of non-data 1203 events, it sets the appropriate socket option for the notifications 1204 it wants. See section 7.3 for these socket options. When a 1205 notification arrives, recvmsg() returns the notification in the 1206 application-supplied data buffer via msg_iov, and sets 1207 MSG_NOTIFICATION in msg_flags. 1208 1209 Multiple notifications may be returned to a single recvmsg() 1210 call. 1211 1212 This section details the notification structures. Every 1213 notification structure carries some common fields which provides 1214 general information. 1215 1216 A recvmsg() call will return only one notification at a time. Just 1217 as when reading normal data, it may return part of a notification if 1218 the msg_iov buffer is not large enough. If a single read is not 1219 sufficient, msg_flags will have MSG_EOR clear. The user MUST finish 1220 reading the notification before subsequent data can arrive. From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Fri Sep 20 12:03:38 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27447 for ; Fri, 20 Sep 2002 12:03:37 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8KFuQW4024797; Fri, 20 Sep 2002 08:56:26 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC76955; Fri, 20 Sep 2002 08:56:24 -0700 (PDT) Sender: rrs@cisco.com Message-ID: <3D8B4527.3EA6A4E5@cisco.com> Date: Fri, 20 Sep 2002 10:56:24 -0500 From: "Randall Stewart (cisco)" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com, La Monte Henry Piggy Yarroll Subject: Re: Q. on draft-ietf-tsvwg-sctpsocket-04.txt References: <20020920145135.444.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well.. this is a good one for La Monte because I think it was his idea to change it to multiple notifications coming up in one read... but I can't remember which the authors agreed to... in any event one of the lines is wrong :> R Marco Molteni wrote: > > Hi Randall :-) > > section 5.3 of draft-ietf-tsvwg-sctpsocket-04.txt says: > > 1209 Multiple notifications may be returned to a single recvmsg() > 1210 call. > > and then: > > 1216 A recvmsg() call will return only one notification at a time. Just > > which is correct ? > > thanks > Marco > > 1192 5.3 SCTP Events and Notifications > 1193 > 1194 An SCTP application may need to understand and process events and > 1195 errors that happen on the SCTP stack. These events include network > 1196 status changes, association startups, remote operational errors and > 1197 undeliverable messages. All of these can be essential for the > 1198 application. > 1199 > 1200 When an SCTP application layer does a recvmsg() the message read is > 1201 normally a data message from a peer endpoint. If the application > 1202 wishes to have the SCTP stack deliver notifications of non-data > 1203 events, it sets the appropriate socket option for the notifications > 1204 it wants. See section 7.3 for these socket options. When a > 1205 notification arrives, recvmsg() returns the notification in the > 1206 application-supplied data buffer via msg_iov, and sets > 1207 MSG_NOTIFICATION in msg_flags. > 1208 > 1209 Multiple notifications may be returned to a single recvmsg() > 1210 call. > 1211 > 1212 This section details the notification structures. Every > 1213 notification structure carries some common fields which provides > 1214 general information. > 1215 > 1216 A recvmsg() call will return only one notification at a time. Just > 1217 as when reading normal data, it may return part of a notification if > 1218 the msg_iov buffer is not large enough. If a single read is not > 1219 sufficient, msg_flags will have MSG_EOR clear. The user MUST finish > 1220 reading the notification before subsequent data can arrive. -- 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 Sat Sep 21 11:39:26 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12523 for ; Sat, 21 Sep 2002 11:39:26 -0400 (EDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8LFFW3x008995 for ; Sat, 21 Sep 2002 08:15:32 -0700 (PDT) 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 RAA09635 for ; Sat, 21 Sep 2002 17:15:36 +0200 (MET DST) Received: (qmail 5232 invoked by uid 1000); 21 Sep 2002 15:15:30 -0000 Message-ID: <20020921151530.5231.qmail@cobweb.example.org> Date: Sat, 21 Sep 2002 17:15:30 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Bcc to snap-users@kame.net, please follow-up on sctp-impl@external.cisco.com] Hi all, the following refers to the SCTP/KAME implementation. The SCTP socket API draft in section "3.3 Non-blocking mode" says: 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). I read that as meaning that the default mode is blocking. So I wrote my test program for a UDP-style SCTP socket, I called recvmsg() and I got back EAGAIN! I started trying all kinds of modifications to the program, and then dig into the SCTP/KAME source code. After two long days, I found some comments in sctp.h that say that blocking is the default for TCP-style, and non-blocking is the default for UDP-style. Please update the draft to reflect this behaviour. Also, the code example in the draft will loop forever, since it expects a blocking socket. Also, what is the proper way to set blocking an UDP-style socket? What I did is the following: if (fcntl(fd, F_SETFL, 0) < 0) { err(1, "fcntl"); } which is ugly. Or maybe, given the semantics, it simply doesn't make sense to have a blocking UDP-style socket? marco From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Sat Sep 21 13:42:38 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14850 for ; Sat, 21 Sep 2002 13:42:38 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8LHWK1X010461; Sat, 21 Sep 2002 10:32:20 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD02954; Sat, 21 Sep 2002 10:32:18 -0700 (PDT) Sender: rrs@cisco.com Message-ID: <3D8CAD22.31111842@cisco.com> Date: Sat, 21 Sep 2002 12:32:18 -0500 From: "Randall Stewart (cisco)" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020921151530.5231.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco Molteni wrote: > > [Bcc to snap-users@kame.net, please follow-up on sctp-impl@external.cisco.com] > > Hi all, the following refers to the SCTP/KAME implementation. > > The SCTP socket API draft in section "3.3 Non-blocking mode" says: > > 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). > > I read that as meaning that the default mode is blocking. So I wrote my > test program for a UDP-style SCTP socket, I called recvmsg() and I got > back EAGAIN! I started trying all kinds of modifications to the program, > and then dig into the SCTP/KAME source code. > > After two long days, I found some comments in sctp.h that say that > blocking is the default for TCP-style, and non-blocking is the default > for UDP-style. > > Please update the draft to reflect this behaviour. > Not sure.. maybe we should update the implementation :> > Also, the code example in the draft will loop forever, since it expects > a blocking socket. > > Also, what is the proper way to set blocking an UDP-style socket? > What I did is the following: > > if (fcntl(fd, F_SETFL, 0) < 0) { > err(1, "fcntl"); > } I think that you can also do int off=0; ioctl(sd,FIONBIO,&off); or to turn it on int on=1; ioctl(sd,FIONBIO,&on); R > > which is ugly. Or maybe, given the semantics, it simply doesn't make sense > to have a blocking UDP-style socket? > > marco -- 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 Sep 23 04:04:11 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01643 for ; Mon, 23 Sep 2002 04:04:11 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-82.cisco.com [64.103.26.82]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id g8N7iX3x011710 for ; Mon, 23 Sep 2002 00:44:34 -0700 (PDT) Received: (qmail 7097 invoked by uid 1000); 23 Sep 2002 07:44:32 -0000 Message-ID: <20020923074432.7096.qmail@cobweb.example.org> Date: Mon, 23 Sep 2002 09:44:32 +0200 From: Marco Molteni To: "Randall Stewart \(cisco\)" Cc: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-Reply-To: <3D8CAD22.31111842@cisco.com> References: <20020921151530.5231.qmail@cobweb.example.org> <3D8CAD22.31111842@cisco.com> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 21 Sep 2002, "Randall Stewart (cisco)" wrote: > Marco Molteni wrote: [..] > > I read that as meaning that the default mode is blocking. So I wrote > > my test program for a UDP-style SCTP socket, I called recvmsg() and > > I got back EAGAIN! I started trying all kinds of modifications to > > the program, and then dig into the SCTP/KAME source code. > > > > After two long days, I found some comments in sctp.h that say that > > blocking is the default for TCP-style, and non-blocking is the > > default for UDP-style. > > > > Please update the draft to reflect this behaviour. > > > Not sure.. maybe we should update the implementation :> Hi Randall, sure, I made that suggestion because I though that the implementation was more updated than the draft. Thanks for the examples on how to set the socket blocking. ciao Marco From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Mon Sep 23 15:53:01 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22507 for ; Mon, 23 Sep 2002 15:53:01 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NJgu3x019493 for ; Mon, 23 Sep 2002 12:42:56 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8NJh163008503 for ; Mon, 23 Sep 2002 12:43:01 -0700 (PDT) Received: from web10105.mail.yahoo.com (web10105.mail.yahoo.com [216.136.130.55]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g8NJg6uR008213 for ; Mon, 23 Sep 2002 12:42:06 -0700 (PDT) Message-ID: <20020923193848.98736.qmail@web10105.mail.yahoo.com> Received: from [216.98.102.225] by web10105.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 12:38:47 PDT Date: Mon, 23 Sep 2002 12:38:47 -0700 (PDT) From: "K. Poon" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode To: Marco Molteni , sctp-impl@external.cisco.com In-Reply-To: <20020921151530.5231.qmail@cobweb.example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Marco Molteni wrote: > The SCTP socket API draft in section "3.3 Non-blocking mode" says: > > 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). > > I read that as meaning that the default mode is blocking. So I wrote > my > test program for a UDP-style SCTP socket, I called recvmsg() and I > got > back EAGAIN! I started trying all kinds of modifications to the > program, > and then dig into the SCTP/KAME source code. So it seems to be a bug in the SCTP/KAME implementation. It should be in blocking mode by default. > Please update the draft to reflect this behaviour. I guess instead of updating the draft, a bug should be filed against the SCTP/KAME implementation... > which is ugly. Or maybe, given the semantics, it simply doesn't make > sense > to have a blocking UDP-style socket? I guess the reason for blocking mode by default is to follow the traditional semantics of all socket calls, which are all in blocking mode. And whether a blcoking or non-blocking mode makes more sense really depends on the context. So the simple solution is to just pick one which conforms to all other socket calls. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Mon Sep 23 15:56:18 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22644 for ; Mon, 23 Sep 2002 15:56:17 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8NJkj1X025866 for ; Mon, 23 Sep 2002 12:46:45 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8NJkibM026639 for ; Mon, 23 Sep 2002 12:46:45 -0700 (PDT) Received: from web10105.mail.yahoo.com (web10105.mail.yahoo.com [216.136.130.55]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g8NJjquR011505 for ; Mon, 23 Sep 2002 12:45:53 -0700 (PDT) Message-ID: <20020923194331.99965.qmail@web10105.mail.yahoo.com> Received: from [216.98.102.225] by web10105.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 12:43:31 PDT Date: Mon, 23 Sep 2002 12:43:31 -0700 (PDT) From: "K. Poon" Subject: Re: Q. on draft-ietf-tsvwg-sctpsocket-04.txt To: "Randall Stewart \(cisco\)" , Marco Molteni Cc: sctp-impl@external.cisco.com, La Monte Henry Piggy Yarroll In-Reply-To: <3D8B4527.3EA6A4E5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- "Randall Stewart (cisco)" wrote: > Well.. this is a good one for La Monte because > I think it was his idea to change it to multiple notifications > coming up in one read... but I can't remember which the authors > agreed to... in any event one of the lines is wrong :> Was this discussed? I didn't remember it... ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Mon Sep 23 20:04:01 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29981 for ; Mon, 23 Sep 2002 20:04:01 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8NNw1W4004070; Mon, 23 Sep 2002 16:58:01 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD37373; Mon, 23 Sep 2002 16:58:00 -0700 (PDT) Message-ID: <3D8FAA87.9040904@cisco.com> Date: Mon, 23 Sep 2002 18:57:59 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "K. Poon" CC: Marco Molteni , sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit K: Here is a question for you... can you make a UDP send() call block? R K. Poon wrote: >--- Marco Molteni wrote: > > > >>The SCTP socket API draft in section "3.3 Non-blocking mode" says: >> >> 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). >> >>I read that as meaning that the default mode is blocking. So I wrote >>my >>test program for a UDP-style SCTP socket, I called recvmsg() and I >>got >>back EAGAIN! I started trying all kinds of modifications to the >>program, >>and then dig into the SCTP/KAME source code. >> >> > >So it seems to be a bug in the SCTP/KAME implementation. It >should be in blocking mode by default. > > > >>Please update the draft to reflect this behaviour. >> >> > >I guess instead of updating the draft, a bug should be filed >against the SCTP/KAME implementation... > > > >>which is ugly. Or maybe, given the semantics, it simply doesn't make >>sense >>to have a blocking UDP-style socket? >> >> > >I guess the reason for blocking mode by default is to follow >the traditional semantics of all socket calls, which are all >in blocking mode. And whether a blcoking or non-blocking mode >makes more sense really depends on the context. So the simple >solution is to just pick one which conforms to all other socket >calls. > > > >===== >K. Poon. kcpoon@yahoo.com > >__________________________________________________ >Do you Yahoo!? >New DSL Internet Access from SBC & Yahoo! >http://sbc.yahoo.com > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Sep 24 00:08:28 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06415 for ; Tue, 24 Sep 2002 00:08:28 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8O4211X025824 for ; Mon, 23 Sep 2002 21:02:01 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8O420wo003398 for ; Mon, 23 Sep 2002 21:02:00 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-33-191.client.attbi.com [12.249.33.191]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8O41wFC022397 for ; Mon, 23 Sep 2002 21:01:59 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g8O3A6T23418; Mon, 23 Sep 2002 22:10:06 -0500 Message-Id: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> To: "Randall Stewart (cisco)" cc: "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: Your message of Mon, 23 Sep 2002 18:57:59 -0500. <3D8FAA87.9040904@cisco.com> Date: Mon, 23 Sep 2002 22:10:05 -0500 Sender: piggy@baqaqi.chi.il.us Of course! If you consume the buffer space available to a given UDP socket, it should block until the IP layer has cleared some buffer space. "Randall Stewart (cisco)" writes: > K: > > Here is a question for you... can you make a UDP send() call block? > > R > > K. Poon wrote: > > >--- Marco Molteni wrote: > > > > > > > >>The SCTP socket API draft in section "3.3 Non-blocking mode" says: > >> > >> 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). > >> > >>I read that as meaning that the default mode is blocking. So I wrote > >>my > >>test program for a UDP-style SCTP socket, I called recvmsg() and I > >>got > >>back EAGAIN! I started trying all kinds of modifications to the > >>program, > >>and then dig into the SCTP/KAME source code. > >> > >> > > > >So it seems to be a bug in the SCTP/KAME implementation. It > >should be in blocking mode by default. > > > > > > > >>Please update the draft to reflect this behaviour. > >> > >> > > > >I guess instead of updating the draft, a bug should be filed > >against the SCTP/KAME implementation... > > > > > > > >>which is ugly. Or maybe, given the semantics, it simply doesn't make > >>sense > >>to have a blocking UDP-style socket? > >> > >> > > > >I guess the reason for blocking mode by default is to follow > >the traditional semantics of all socket calls, which are all > >in blocking mode. And whether a blcoking or non-blocking mode > >makes more sense really depends on the context. So the simple > >solution is to just pick one which conforms to all other socket > >calls. > > > > > > > >===== > >K. Poon. kcpoon@yahoo.com > > > >__________________________________________________ > >Do you Yahoo!? > >New DSL Internet Access from SBC & Yahoo! > >http://sbc.yahoo.com > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Sep 24 00:08:58 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06432 for ; Tue, 24 Sep 2002 00:08:53 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8O42DW4015897 for ; Mon, 23 Sep 2002 21:02:13 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8O42C85006010 for ; Mon, 23 Sep 2002 21:02:12 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-33-191.client.attbi.com [12.249.33.191]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8O41wFG022397 for ; Mon, 23 Sep 2002 21:02:06 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g8O3Fur23446; Mon, 23 Sep 2002 22:15:56 -0500 Message-Id: <200209240315.g8O3Fur23446@baqaqi.chi.il.us> To: "Randall Stewart (cisco)" cc: "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: Your message of Mon, 23 Sep 2002 18:57:59 -0500. <3D8FAA87.9040904@cisco.com> Date: Mon, 23 Sep 2002 22:15:55 -0500 Sender: piggy@baqaqi.chi.il.us Of course! If you consume the buffer space available to a given UDP socket, it should block until the IP layer has cleared some buffer space. "Randall Stewart (cisco)" writes: > K: > > Here is a question for you... can you make a UDP send() call block? > > R > > K. Poon wrote: > > >--- Marco Molteni wrote: > > > > > > > >>The SCTP socket API draft in section "3.3 Non-blocking mode" says: > >> > >> 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). > >> > >>I read that as meaning that the default mode is blocking. So I wrote > >>my > >>test program for a UDP-style SCTP socket, I called recvmsg() and I > >>got > >>back EAGAIN! I started trying all kinds of modifications to the > >>program, > >>and then dig into the SCTP/KAME source code. > >> > >> > > > >So it seems to be a bug in the SCTP/KAME implementation. It > >should be in blocking mode by default. > > > > > > > >>Please update the draft to reflect this behaviour. > >> > >> > > > >I guess instead of updating the draft, a bug should be filed > >against the SCTP/KAME implementation... > > > > > > > >>which is ugly. Or maybe, given the semantics, it simply doesn't make > >>sense > >>to have a blocking UDP-style socket? > >> > >> > > > >I guess the reason for blocking mode by default is to follow > >the traditional semantics of all socket calls, which are all > >in blocking mode. And whether a blcoking or non-blocking mode > >makes more sense really depends on the context. So the simple > >solution is to just pick one which conforms to all other socket > >calls. > > > > > > > >===== > >K. Poon. kcpoon@yahoo.com > > > >__________________________________________________ > >Do you Yahoo!? > >New DSL Internet Access from SBC & Yahoo! > >http://sbc.yahoo.com > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Sep 24 05:02:28 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20526 for ; Tue, 24 Sep 2002 05:02:27 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8O8rW1X006321 for ; Tue, 24 Sep 2002 01:53:33 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8O8rTCN020075 for ; Tue, 24 Sep 2002 01:53:30 -0700 (PDT) Received: from 263.net ([211.157.130.145]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8O8rOFC021763 for ; Tue, 24 Sep 2002 01:53:27 -0700 (PDT) Received: by 263.net (Postfix, from userid 60001) id 751971C7C2A33; Tue, 24 Sep 2002 16:44:56 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D902608.00001A.02764@mta5> Date: Tue, 24 Sep 2002 16:44:56 +0800 (CST) From: "Ê©" To: sctp-impl@external.cisco.com Subject: =?gb2312?B?c29ja2V0IG9wdGlvbjpTT19OT0RFTEFZIGFuZCBTQ1RQX1NFVF9QUklNQVJZX0FERFI=?= X-Priority: 1 X-Originating-IP: [210.12.42.4] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Dear all, I am implementing the SCTP socket-option in linux, and most of the read/write and read-only options are finished, now i have questions about two options: 7.1.5 SO_NODELAY This option is to turn off any Nagle-like algorithm. Had the LKSCTP in sourceforge.net implemented the Nagle-like algorithm? It seems that the Nagle algorithm (RFC 896) can only impact the performance of SCTP, whether we use SCTP to transport the signaling or use PR-SCTP to transport the real-time media application. So can we set the Nagle algorithm off by default, or even ignore this option? 7.1.9 SCTP_SET_PRIMARY_ADDR This option requests the peer to set the association primary. Do we need another more chunk-type, such as SETPRIM chunk, to performance this option? For example, When setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk will be sent immediately to the peer; and when the peer receive a SETPRIM chunk, after doing some verification, it will reset its primary according to the enclosed address in the SETPRIM chunk. I am not sure about this and thanks for help! Best regards Jinyang Shi 24/09/02 From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Sep 24 07:42:59 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23043 for ; Tue, 24 Sep 2002 07:42:54 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8OBasW4014855; Tue, 24 Sep 2002 04:36:54 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD49053; Tue, 24 Sep 2002 04:36:52 -0700 (PDT) Message-ID: <3D904E54.5080702@cisco.com> Date: Tue, 24 Sep 2002 06:36:52 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hmmm... I don't think that any buffer space is consumed by a udp send call. It is put on the wire when the call is made and never is it added to the output socket buffer. The only way I can imagine it every blocking is ONLY if one chews up all the MBUF's (say in some tcp connections) and then trys the send. I believe the MGET() call is setup to block in this case.... But of course if you chew up all the mbufs in a system things are so sick I am not to sure the system would survive :-0 R La Monte Henry Piggy Yarroll wrote: >Of course! If you consume the buffer space available to a given UDP >socket, it should block until the IP layer has cleared some buffer >space. > >"Randall Stewart (cisco)" writes: > > >>K: >> >>Here is a question for you... can you make a UDP send() call block? >> >>R >> >>K. Poon wrote: >> >> >> >>>--- Marco Molteni wrote: >>> >>> >>> >>> >>> >>>>The SCTP socket API draft in section "3.3 Non-blocking mode" says: >>>> >>>> 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). >>>> >>>>I read that as meaning that the default mode is blocking. So I wrote >>>>my >>>>test program for a UDP-style SCTP socket, I called recvmsg() and I >>>>got >>>>back EAGAIN! I started trying all kinds of modifications to the >>>>program, >>>>and then dig into the SCTP/KAME source code. >>>> >>>> >>>> >>>> >>>So it seems to be a bug in the SCTP/KAME implementation. It >>>should be in blocking mode by default. >>> >>> >>> >>> >>> >>>>Please update the draft to reflect this behaviour. >>>> >>>> >>>> >>>> >>>I guess instead of updating the draft, a bug should be filed >>>against the SCTP/KAME implementation... >>> >>> >>> >>> >>> >>>>which is ugly. Or maybe, given the semantics, it simply doesn't make >>>>sense >>>>to have a blocking UDP-style socket? >>>> >>>> >>>> >>>> >>>I guess the reason for blocking mode by default is to follow >>>the traditional semantics of all socket calls, which are all >>>in blocking mode. And whether a blcoking or non-blocking mode >>>makes more sense really depends on the context. So the simple >>>solution is to just pick one which conforms to all other socket >>>calls. >>> >>> >>> >>>===== >>>K. Poon. kcpoon@yahoo.com >>> >>>__________________________________________________ >>>Do you Yahoo!? >>>New DSL Internet Access from SBC & Yahoo! >>>http://sbc.yahoo.com >>> >>> >>> >>> >>> >>-- >>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-3.cisco.com Tue Sep 24 08:04:14 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23934 for ; Tue, 24 Sep 2002 08:04:09 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-82.cisco.com [64.103.26.82]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id g8OBw23x017020 for ; Tue, 24 Sep 2002 04:58:03 -0700 (PDT) Received: (qmail 1842 invoked by uid 1000); 24 Sep 2002 11:58:06 -0000 Message-ID: <20020924115806.1841.qmail@cobweb.example.org> Date: Tue, 24 Sep 2002 13:58:06 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-Reply-To: <3D8FAA87.9040904@cisco.com> References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> <3D8FAA87.9040904@cisco.com> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 23 Sep 2002, "Randall Stewart (cisco)" wrote: > K: > > Here is a question for you... can you make a UDP send() call block? Randall, just to be sure, in my previous email I was talking about revcmsg(), not sendmsg(). Marco > > R > > K. Poon wrote: > > >--- Marco Molteni wrote: > > > > > > > >>The SCTP socket API draft in section "3.3 Non-blocking mode" says: > >> > >> 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). > >> > >>I read that as meaning that the default mode is blocking. So I wrote > >>my > >>test program for a UDP-style SCTP socket, I called recvmsg() and I > >>got > >>back EAGAIN! I started trying all kinds of modifications to the > >>program, > >>and then dig into the SCTP/KAME source code. > >> > >> > > > >So it seems to be a bug in the SCTP/KAME implementation. It > >should be in blocking mode by default. > > > > > > > >>Please update the draft to reflect this behaviour. > >> > >> > > > >I guess instead of updating the draft, a bug should be filed > >against the SCTP/KAME implementation... > > > > > > > >>which is ugly. Or maybe, given the semantics, it simply doesn't make > >>sense > >>to have a blocking UDP-style socket? > >> > >> > > > >I guess the reason for blocking mode by default is to follow > >the traditional semantics of all socket calls, which are all > >in blocking mode. And whether a blcoking or non-blocking mode > >makes more sense really depends on the context. So the simple > >solution is to just pick one which conforms to all other socket > >calls. > > > > > > > >===== > >K. Poon. kcpoon@yahoo.com > > > >__________________________________________________ > >Do you Yahoo!? > >New DSL Internet Access from SBC & Yahoo! > >http://sbc.yahoo.com > > > > > > > > -- Computers are like air conditioners. They stop working when you open Windows. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Sep 24 08:33:40 2002 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24823 for ; Tue, 24 Sep 2002 08:33:39 -0400 (EDT) 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 g8OCS6Ha000695; Tue, 24 Sep 2002 05:28:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD49612; Tue, 24 Sep 2002 05:28:05 -0700 (PDT) Message-ID: <3D905A54.5040708@cisco.com> Date: Tue, 24 Sep 2002 07:28:04 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> <3D8FAA87.9040904@cisco.com> <20020924115806.1841.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco: I figured you were talking about recv-msg.. but this is the real crux of the matter. In practice UDP sockets WILL block on a recvmsg but WON'T block on a sendmsg. The reason being that of course you block when you read.. but unless the system is under sever conditions (out of mbufs really does not happen unless something is very very wrong) a sendto() will never block. This is kind of an issue...IMO in that in a TCP app I would expect to block in a sendto() possibly.. but will this blocking surprise any UDP style model? I don't know the answer but it is the reason I made the default UDP side do a non-blocking model (which is a one line code change by the way :>) R Marco Molteni wrote: >On Mon, 23 Sep 2002, "Randall Stewart (cisco)" wrote: > > > >>K: >> >>Here is a question for you... can you make a UDP send() call block? >> >> > >Randall, > >just to be sure, in my previous email I was talking about revcmsg(), not >sendmsg(). > >Marco > > > >>R >> >>K. Poon wrote: >> >> >> >>>--- Marco Molteni wrote: >>> >>> >>> >>> >>> >>>>The SCTP socket API draft in section "3.3 Non-blocking mode" says: >>>> >>>> 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). >>>> >>>>I read that as meaning that the default mode is blocking. So I wrote >>>>my >>>>test program for a UDP-style SCTP socket, I called recvmsg() and I >>>>got >>>>back EAGAIN! I started trying all kinds of modifications to the >>>>program, >>>>and then dig into the SCTP/KAME source code. >>>> >>>> >>>> >>>> >>>So it seems to be a bug in the SCTP/KAME implementation. It >>>should be in blocking mode by default. >>> >>> >>> >>> >>> >>>>Please update the draft to reflect this behaviour. >>>> >>>> >>>> >>>> >>>I guess instead of updating the draft, a bug should be filed >>>against the SCTP/KAME implementation... >>> >>> >>> >>> >>> >>>>which is ugly. Or maybe, given the semantics, it simply doesn't make >>>>sense >>>>to have a blocking UDP-style socket? >>>> >>>> >>>> >>>> >>>I guess the reason for blocking mode by default is to follow >>>the traditional semantics of all socket calls, which are all >>>in blocking mode. And whether a blcoking or non-blocking mode >>>makes more sense really depends on the context. So the simple >>>solution is to just pick one which conforms to all other socket >>>calls. >>> >>> >>> >>>===== >>>K. Poon. kcpoon@yahoo.com >>> >>>__________________________________________________ >>>Do you Yahoo!? >>>New DSL Internet Access from SBC & Yahoo! >>>http://sbc.yahoo.com >>> >>> >>> >>> >>> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Sep 24 08:35:22 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24843 for ; Tue, 24 Sep 2002 08:35:21 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8OCU63x001679; Tue, 24 Sep 2002 05:30:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD49629; Tue, 24 Sep 2002 05:30:10 -0700 (PDT) Message-ID: <3D905AD2.7040904@cisco.com> Date: Tue, 24 Sep 2002 07:30:10 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=3F?= CC: sctp-impl@external.cisco.com Subject: Re: socket option:SO_NODELAY and SCTP_SET_PRIMARY_ADDR References: <3D902608.00001A.02764@mta5> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ? wrote: >Dear all, > > I am implementing the SCTP socket-option in linux, and most of the read/write and read-only options are finished, now i have questions about two options: > >7.1.5 SO_NODELAY > This option is to turn off any Nagle-like algorithm. Had the LKSCTP in sourceforge.net implemented the Nagle-like algorithm? > It seems that the Nagle algorithm (RFC 896) can only impact the performance of SCTP, whether we use SCTP to transport the signaling or use PR-SCTP to transport the real-time media application. So can we set the Nagle algorithm off by default, or even ignore this option? > > We have not yet implemented a Nagle algorithm in our release.. and yet we do have this option. It currently just tracks a flag on and off indicating that the endpoint does or does not want a "Nagle" like algorithm. Now you may ask why in the world would you still want it. a) For existing TCP app's porting to SCTP it gives them a transition option.. many of the TCP apps we have put up do a "TCP_NODELAY" so this then allows us to have a option they can hang a hook on :> b) In the future we do plan on implementing some type of "Nagle" algo so we want to have the app be able to turn it on and off... So I would advise you to do the same even if you have not implemented it yet .. >7.1.9 SCTP_SET_PRIMARY_ADDR > This option requests the peer to set the association primary. > Do we need another more chunk-type, such as SETPRIM chunk, to performance this option? For example, When setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk will be sent immediately to the peer; and when the peer receive a SETPRIM chunk, after doing some verification, it will reset its primary according to the enclosed address in the SETPRIM chunk. > > I am not sure what you mean by this. We have a chunk that already takes care of this. It is called a ASCONF chunk and it is in the addip draft. Please have a look at this draft. 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-2.cisco.com Tue Sep 24 09:01:33 2002 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25561 for ; Tue, 24 Sep 2002 09:01:33 -0400 (EDT) Received: from www.example.org (dhcp-nic-val-26-82.cisco.com [64.103.26.82]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with SMTP id g8OCu0Ha014411 for ; Tue, 24 Sep 2002 05:56:01 -0700 (PDT) Received: (qmail 2390 invoked by uid 1000); 24 Sep 2002 12:55:58 -0000 Message-ID: <20020924125558.2389.qmail@cobweb.example.org> Date: Tue, 24 Sep 2002 14:55:58 +0200 From: Marco Molteni To: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-Reply-To: <3D905A54.5040708@cisco.com> References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> <3D8FAA87.9040904@cisco.com> <20020924115806.1841.qmail@cobweb.example.org> <3D905A54.5040708@cisco.com> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 24 Sep 2002, "Randall Stewart (cisco)" wrote: > Marco: > > I figured you were talking about recv-msg.. but this is the real crux > of the matter. > In practice UDP sockets WILL block on a recvmsg but WON'T block on a > sendmsg. > > The reason being that of course you block when you read.. but unless > the system is under sever conditions (out of mbufs really does not happen > unless something is very very wrong) a sendto() will never block. > This is kind of an issue...IMO in that in a TCP app I would expect > to block in a sendto() possibly.. but will this blocking surprise any > UDP style model? Randall, I may be missing something, but what's wrong with the following: If I set a socket (who cares if TCP/UDP/SCTP) in blocking mode, I do _not_ expect a read/write syscall to block just because the socket is in blocking mode, what I expect is a read/write syscall to block _only_ if there isn't data available to read or if there isn't buffer space to write. This is what happens with BSD kernels for UDP sockets, as you said: a write, in normal system operation, is always successful without blocking. > I don't know the answer but it is the reason I made the default UDP > side do a non-blocking > model (which is a one line code change by the way :>) > > R Marco From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Sep 24 09:07:38 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25834 for ; Tue, 24 Sep 2002 09:07:38 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8OD2VW4012939 for ; Tue, 24 Sep 2002 06:02:31 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8OD2VOc018910 for ; Tue, 24 Sep 2002 06:02:31 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-33-191.client.attbi.com [12.249.33.191]) by proxy1.cisco.com (8.12.2/8.11.2) with ESMTP id g8OD2Rpi011627 for ; Tue, 24 Sep 2002 06:02:28 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g8OCHEs25327; Tue, 24 Sep 2002 07:17:18 -0500 Message-Id: <200209241217.g8OCHEs25327@baqaqi.chi.il.us> To: "Ê©" cc: sctp-impl@external.cisco.com, lksctp-developers@lists.sourceforge.net From: "La Monte Henry Piggy Yarroll" Subject: Re: =?gb2312?B?c29ja2V0IG9wdGlvbjpTT19OT0RFTEFZIGFuZCBTQ1RQX1NFVF9QUklNQVJZX0FERFI=?= In-reply-to: Your message of Tue, 24 Sep 2002 16:44:56 +0800. <3D902608.00001A.02764@mta5> Date: Tue, 24 Sep 2002 07:17:13 -0500 Sender: piggy@baqaqi.chi.il.us Discussion of LKSCTP (the official Linux implementation of SCTP) belongs on lksctp-developers@lists.sourceforge.net. bupt_sjy@263.net writes: > Dear all, > > I am implementing the SCTP socket-option in linux, and most of > the read/write and read-only options are finished, now i have > questions about two options: > > 7.1.5 SO_NODELAY > This option is to turn off any Nagle-like algorithm. Had the > LKSCTP in sourceforge.net implemented the Nagle-like algorithm? AFAIK, Nagle remains unimplemented. > It seems that the Nagle algorithm (RFC 896) can only impact the > performance of SCTP, whether we use SCTP to transport the signaling > or use PR-SCTP to transport the real-time media application. So can > we set the Nagle algorithm off by default, or even ignore this > option? Nagle is supposed to be on by default. That is just normal sockets semantics. Even though Nagle is still unimplemented, there should be a flag in the socket structure which indicates whether or not Nagle is active. You may toggle that flag. > 7.1.9 SCTP_SET_PRIMARY_ADDR > This option requests the peer to set the association primary. > > Do we need another more chunk-type, such as SETPRIM chunk, to > performance this option? For example, When > setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk > will be sent immediately to the peer; and when the peer receive a > SETPRIM chunk, after doing some verification, it will reset its > primary according to the enclosed address in the SETPRIM chunk. This is part of the AddIP extension. Xingang Guo did a preliminary implementation of AddIP quite some time ago. It was never fully integrated. His implementation is available as a patch on SourceForge, but it will no doubt take some work to integrate it with the current code base. Meanwhile, the following quote from the API draft applies: This functionality is optional. Implementations that do not support this functionality should return EOPNOTSUPP. > I am not sure about this and thanks for help! My pleasure. > Best regards > > Jinyang Shi > 24/09/02 From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Tue Sep 24 09:46:22 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27159 for ; Tue, 24 Sep 2002 09:46:21 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8ODeCW4027147 for ; Tue, 24 Sep 2002 06:40:12 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8ODeCiY029939 for ; Tue, 24 Sep 2002 06:40:12 -0700 (PDT) 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 g8ODe9NS011668 for ; Tue, 24 Sep 2002 06:40:10 -0700 (PDT) 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 IAA34960; Tue, 24 Sep 2002 08:34:28 -0500 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA26758; Tue, 24 Sep 2002 08:32:41 -0500 Received: from us.ibm.com (touki.austin.ibm.com [9.53.216.243]) by popmail.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id IAA23028; Tue, 24 Sep 2002 08:32:40 -0500 Sender: root@popmail.austin.ibm.com Message-ID: <3D906543.F32DC7F5@us.ibm.com> Date: Tue, 24 Sep 2002 08:14:43 -0500 From: Jon Grimm X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.5.31 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Marco Molteni , sctp-impl@external.cisco.com, La Monte Henry Piggy Yarroll Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> <3D8FAA87.9040904@cisco.com> <20020924115806.1841.qmail@cobweb.example.org> <3D905A54.5040708@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy/Marco/La Monte/Everyone: "Randall Stewart (cisco)" wrote: > > Marco: > > I figured you were talking about recv-msg.. but this is the real crux of > the matter. > In practice UDP sockets WILL block on a recvmsg but WON'T block on a > sendmsg. > > The reason being that of course you block when you read.. but unless the > system is under > sever conditions (out of mbufs really does not happen unless something > is very very wrong) > a sendto() will never block. This is kind of an issue...IMO in that in a > TCP app I would expect > to block in a sendto() possibly.. but will this blocking surprise any > UDP style model? > Or stated in another way... will receiving an EAGAIN error from sendto() suprise any UDP-style model in the face of SCTP output buffers filling up? ;-) Its not a clean fit either way...SCTP is so much more than UDP that its difficult to get the absolute behavior of SOCK_DGRAM (Is this why SOCK_DGRAM was not used?) One thing we touched on a bit out at the Bakeoff and should probably spin into its own thread if folks think interesting is that of the UDP-style API itself: Is the UDP-style API goal really towards a programming model or towards SOCK_DGRAM transparency? (or likely even a little of both). > I don't know the answer but it is the reason I made the default UDP side > do a non-blocking > model (which is a one line code change by the way :>) > IIRC, we default to blocking behavior since that is normal default sockets configuration. Best Regards, Jon > R > > Marco Molteni wrote: > > >On Mon, 23 Sep 2002, "Randall Stewart (cisco)" wrote: > > > > > > > >>K: > >> > >>Here is a question for you... can you make a UDP send() call block? > >> > >> > > > >Randall, > > > >just to be sure, in my previous email I was talking about revcmsg(), not > >sendmsg(). > > > >Marco > > > > > > > >>R > >> > >>K. Poon wrote: > >> > >> > >> > >>>--- Marco Molteni wrote: > >>> > >>> > >>> > >>> > >>> > >>>>The SCTP socket API draft in section "3.3 Non-blocking mode" says: > >>>> > >>>> 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). > >>>> > >>>>I read that as meaning that the default mode is blocking. So I wrote > >>>>my > >>>>test program for a UDP-style SCTP socket, I called recvmsg() and I > >>>>got > >>>>back EAGAIN! I started trying all kinds of modifications to the > >>>>program, > >>>>and then dig into the SCTP/KAME source code. > >>>> > >>>> > >>>> > >>>> > >>>So it seems to be a bug in the SCTP/KAME implementation. It > >>>should be in blocking mode by default. > >>> > >>> > >>> > >>> > >>> > >>>>Please update the draft to reflect this behaviour. > >>>> > >>>> > >>>> > >>>> > >>>I guess instead of updating the draft, a bug should be filed > >>>against the SCTP/KAME implementation... > >>> > >>> > >>> > >>> > >>> > >>>>which is ugly. Or maybe, given the semantics, it simply doesn't make > >>>>sense > >>>>to have a blocking UDP-style socket? > >>>> > >>>> > >>>> > >>>> > >>>I guess the reason for blocking mode by default is to follow > >>>the traditional semantics of all socket calls, which are all > >>>in blocking mode. And whether a blcoking or non-blocking mode > >>>makes more sense really depends on the context. So the simple > >>>solution is to just pick one which conforms to all other socket > >>>calls. > >>> > >>> > >>> > >>>===== > >>>K. Poon. kcpoon@yahoo.com > >>> > >>>__________________________________________________ > >>>Do you Yahoo!? > >>>New DSL Internet Access from SBC & Yahoo! > >>>http://sbc.yahoo.com > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Tue Sep 24 09:48:47 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27270 for ; Tue, 24 Sep 2002 09:48:47 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8ODhJ1X003870; Tue, 24 Sep 2002 06:43:19 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD50556; Tue, 24 Sep 2002 06:43:18 -0700 (PDT) Message-ID: <3D906BF5.3020500@cisco.com> Date: Tue, 24 Sep 2002 08:43:17 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni CC: sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020923193848.98736.qmail@web10105.mail.yahoo.com> <3D8FAA87.9040904@cisco.com> <20020924115806.1841.qmail@cobweb.example.org> <3D905A54.5040708@cisco.com> <20020924125558.2389.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco Molteni wrote: >On Tue, 24 Sep 2002, "Randall Stewart (cisco)" wrote: > > > >>Marco: >> >>I figured you were talking about recv-msg.. but this is the real crux >>of the matter. >>In practice UDP sockets WILL block on a recvmsg but WON'T block on a >>sendmsg. >> >>The reason being that of course you block when you read.. but unless >>the system is under sever conditions (out of mbufs really does not happen >>unless something is very very wrong) a sendto() will never block. >>This is kind of an issue...IMO in that in a TCP app I would expect >>to block in a sendto() possibly.. but will this blocking surprise any >>UDP style model? >> >> > >Randall, > >I may be missing something, but what's wrong with the following: > >If I set a socket (who cares if TCP/UDP/SCTP) in blocking mode, I >do _not_ expect a read/write syscall to block just because the socket is >in blocking mode, what I expect is a read/write syscall to block _only_ if >there isn't data available to read or if there isn't buffer space to >write. > > If in TCP you have blocking turned on and you do a send/write call you WILL block if there is not room in the socket buffer. This does not occur in a UDP model since the data is never kept in the socket buffer and hits the wire right away (or is dropped). So this IS fundamentally different in a Udp style.. R >This is what happens with BSD kernels for UDP sockets, as you said: a >write, in normal system operation, is always successful without blocking. > > > > >>I don't know the answer but it is the reason I made the default UDP >>side do a non-blocking >>model (which is a one line code change by the way :>) >> >>R >> >> > >Marco > > > -- 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 Sep 24 10:52:10 2002 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00482 for ; Tue, 24 Sep 2002 10:52:09 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8OEgIHa005409 for ; Tue, 24 Sep 2002 07:42:19 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8OEgHmD011934 for ; Tue, 24 Sep 2002 07:42:17 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8OEg9NS018639 for ; Tue, 24 Sep 2002 07:42:14 -0700 (PDT) Received: from livingroom.acm.org (pcp01480934pcs.ncstl01.de.comcast.net [68.82.70.108]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0H2Y0089Y5F66D@mtaout04.icomcast.net> for sctp-impl@external.cisco.com; Tue, 24 Sep 2002 10:25:56 -0400 (EDT) Date: Tue, 24 Sep 2002 10:30:26 -0400 From: Phillip Conrad Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: <3D904E54.5080702@cisco.com> X-Sender: phillipconrad@mail.comcast.net To: "Randall Stewart (cisco)" , La Monte Henry Piggy Yarroll Cc: "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Message-id: <5.1.0.14.2.20020924102156.0393b0f8@mail.earthlink.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> Content-Transfer-Encoding: 7BIT Randy, Your question (can a UDP socket ever block on a write() ) misses an important point, and illustrates the problem with the use of the term "UDP style" socket. A true UDP socket is "many to one" (many associations, one socket). This is the main similarity with a so-called UDP-style SCTP socket. BUT that UDP socket also is unreliable and not flow controlled. With a *true* UDP socket, there is no flow control, and there is no guarantee of reliability. It is reasonable to say that there is really no good reason for a UDP socket to block on a write(), because if there is no buffer space left, there is no problem with just throwing the write away! (After all, the protocol is "best effort"... if there is no buffer space, oh well!) This may or may not be what real UDP implementations do, but if they did, there would be no mismatch between the API and the protocol semantics. But in a reliable, flow controlled protocol, such as SCTP, a write() should either block or fail if there is no rwnd() space. This is what provides backpressure to applications to let them know to stop sending when the receiver is not consuming data fast enough and is an important part of what allows the protocol to be "reliable". Now, of course, that is much easier to apply in the "TCP model" where you have one socket for one association, and where there is an implicit understanding that things are always reliable. With an SCTP "UDP-style" socket, we have a new animal: a many-to-one socket (many associations, one socket) that is also reliable and flow controlled. We cannot just apply "UDP-style" thinking here. There are two choices: (1) make the socket ALWAYS non blocking, in which case a send () directed towards an association that has a zero rwnd should return an error (perhaps EWOULDBLOCK or EAGAIN)? (2) allow blocking behavior... in particular, if you write() on socket s1 directed towards an association a1 with a zero rwnd, that socket should block even if there are other associations a2 through aN that have rwnd space. The user may not like being blocked, but that was part of the bargain he/she made when you chose a blocking UDP-style socket; to avoid that situation, use a non-blocking socket, or use the one-to-one model (currently called the TCP model.) Either way, it is not only a question of running out of mbufs. The interaction of UDP-style SCTP sockets with rwnd needs to be taken into account. Cheers, Phill At 06:36 AM 9/24/2002 -0500, Randall Stewart (cisco) wrote: >Hmmm... I don't think that any buffer space is consumed by >a udp send call. It is put on the wire when the call is made >and never is it added to the output socket buffer. > >The only way I can imagine it every blocking is ONLY if one chews up >all the MBUF's (say in some tcp connections) and then trys the send. I >believe >the MGET() call is setup to block in this case.... > >But of course if you chew up all the mbufs in a system things are so >sick I am >not to sure the system would survive :-0 > >R > > >La Monte Henry Piggy Yarroll wrote: > >>Of course! If you consume the buffer space available to a given UDP >>socket, it should block until the IP layer has cleared some buffer > > >WARNING: The remainder of this message has not been transferred. >The estimated size of this message is 4510 bytes. >Click on the Retrieve From Server icon above and check mail again to get the >whole thing. (If you're reading this in the preview pane, you'll need to >open the message to see the icon.) If the Retrieve From Server icon is not >showing, then this message is no longer on the server. From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Tue Sep 24 20:19:13 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15854 for ; Tue, 24 Sep 2002 20:19:13 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8P0Cj3x017845 for ; Tue, 24 Sep 2002 17:12:45 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8P0Coqu016726 for ; Tue, 24 Sep 2002 17:12:51 -0700 (PDT) Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8P0CnNS006105 for ; Tue, 24 Sep 2002 17:12:49 -0700 (PDT) Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id g8P074c10709; Tue, 24 Sep 2002 17:07:04 -0700 (PDT) Received: from renoir.ccrl.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id RAA21314; Tue, 24 Sep 2002 17:06:54 -0700 (PDT) Received: from ccrl.sj.nec.com (dhcp28 [131.241.79.228]) by renoir.ccrl.sj.nec.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06433; Tue, 24 Sep 2002 17:06:53 -0700 (PDT) Message-ID: <3D90FDF9.8040101@ccrl.sj.nec.com> Date: Tue, 24 Sep 2002 17:06:17 -0700 From: FUJITA Ken 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: ja, en-us MIME-Version: 1.0 To: Phillip Conrad , "Randall Stewart (cisco)" CC: La Monte Henry Piggy Yarroll , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> <5.1.0.14.2.20020924102156.0393b0f8@mail.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Phillip, Randy, and Folks > There are two choices: > > (1) make the socket ALWAYS non blocking, in which case a send () > directed towards an association that has a zero rwnd should return an > error (perhaps EWOULDBLOCK or EAGAIN)? > > (2) allow blocking behavior... in particular, if you write() on > socket s1 directed towards an association a1 with a zero rwnd, that > socket should block even if there are other associations a2 through aN > that have rwnd space. The user may not like being blocked, but that > was part of the bargain he/she made when you chose a blocking > UDP-style socket; to avoid that situation, use a non-blocking socket, > or use the one-to-one model (currently called the TCP model.) > Or we can use sctp_peeloff() to branch off the association into a separate socket/file descriptor. In this case, if one UDP-style association becomes blocking, I believe the other association still works without blocking. In my feeling, option 2 is better. Thanks, -- FUJITA Ken mailto:fken@ccrl.sj.nec.com Phillip Conrad wrote: > Randy, > Your question (can a UDP socket ever block on a write() ) misses an important point, and illustrates the problem with the use of the term "UDP style" socket. A true UDP socket is "many to one" (many associations, one socket). This is the main similarity with a so-called UDP-style SCTP socket. BUT that UDP socket also is unreliable and not flow controlled. > > With a *true* UDP socket, there is no flow control, and there is no guarantee of reliability. It is reasonable to say that there is really no good reason for a UDP socket to block on a write(), because if there is no buffer space left, there is no problem with just throwing the write away! (After all, the protocol is "best effort"... if there is no buffer space, oh well!) This may or may not be what real UDP implementations do, but if they did, there would be no mismatch between the API and the protocol semantics. > > But in a reliable, flow controlled protocol, such as SCTP, a write() should either block or fail if there is no rwnd() space. This is what provides backpressure to applications to let them know to stop sending when the receiver is not consuming data fast enough and is an important part of what allows the protocol to be "reliable". > > Now, of course, that is much easier to apply in the "TCP model" where you have one socket for one association, and where there is an implicit understanding that things are always reliable. > > With an SCTP "UDP-style" socket, we have a new animal: a many-to-one socket (many associations, one socket) that is also reliable and flow controlled. We cannot just apply "UDP-style" thinking here. > > There are two choices: > > (1) make the socket ALWAYS non blocking, in which case a send () directed towards an association that has a zero rwnd should return an error (perhaps EWOULDBLOCK or EAGAIN)? > > (2) allow blocking behavior... in particular, if you write() on socket s1 directed towards an association a1 with a zero rwnd, that socket should block even if there are other associations a2 through aN that have rwnd space. The user may not like being blocked, but that was part of the bargain he/she made when you chose a blocking UDP-style socket; to avoid that situation, use a non-blocking socket, or use the one-to-one model (currently called the TCP model.) > > > Either way, it is not only a question of running out of mbufs. The interaction of UDP-style SCTP sockets with rwnd needs to be taken into account. > > Cheers, > Phill > > At 06:36 AM 9/24/2002 -0500, Randall Stewart (cisco) wrote: > >>Hmmm... I don't think that any buffer space is consumed by >>a udp send call. It is put on the wire when the call is made >>and never is it added to the output socket buffer. >> >>The only way I can imagine it every blocking is ONLY if one chews up >>all the MBUF's (say in some tcp connections) and then trys the send. I >>believe >>the MGET() call is setup to block in this case.... >> >>But of course if you chew up all the mbufs in a system things are so >>sick I am >>not to sure the system would survive :-0 >> >>R >> >> >>La Monte Henry Piggy Yarroll wrote: >> >> >>>Of course! If you consume the buffer space available to a given UDP >>>socket, it should block until the IP layer has cleared some buffer >> >> >>WARNING: The remainder of this message has not been transferred. >>The estimated size of this message is 4510 bytes. >>Click on the Retrieve From Server icon above and check mail again to get the >>whole thing. (If you're reading this in the preview pane, you'll need to >>open the message to see the icon.) If the Retrieve From Server icon is not >>showing, then this message is no longer on the server. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Tue Sep 24 22:41:55 2002 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18950 for ; Tue, 24 Sep 2002 22:41:55 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8P2aKHa022987 for ; Tue, 24 Sep 2002 19:36:20 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8P2aJe8010690 for ; Tue, 24 Sep 2002 19:36:20 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8P2aHNS020526 for ; Tue, 24 Sep 2002 19:36:18 -0700 (PDT) Received: from livingroom.acm.org (pcp01480934pcs.ncstl01.de.comcast.net [68.82.70.108]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H2Z00JVO2HWA8@mtaout02.icomcast.net> for sctp-impl@external.cisco.com; Tue, 24 Sep 2002 22:20:21 -0400 (EDT) Date: Tue, 24 Sep 2002 22:20:06 -0400 From: Phillip Conrad Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: <3D90FDF9.8040101@ccrl.sj.nec.com> X-Sender: phillipconrad@mail.comcast.net To: FUJITA Ken , "Randall Stewart (cisco)" Cc: La Monte Henry Piggy Yarroll , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Message-id: <5.1.0.14.2.20020924214255.03899070@mail.earthlink.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> <5.1.0.14.2.20020924102156.0393b0f8@mail.earthlink.net> Content-Transfer-Encoding: 7BIT At 05:06 PM 9/24/2002 -0700, FUJITA Ken wrote: >Phillip, Randy, and Folks > > > There are two choices: > > > > (1) make the socket ALWAYS non blocking, in which case a send () > > directed towards an association that has a zero rwnd should return an > > error (perhaps EWOULDBLOCK or EAGAIN)? > > > > (2) allow blocking behavior... in particular, if you write() on > > socket s1 directed towards an association a1 with a zero rwnd, that > > socket should block even if there are other associations a2 through aN > > that have rwnd space. The user may not like being blocked, but that > > was part of the bargain he/she made when you chose a blocking > > UDP-style socket; to avoid that situation, use a non-blocking socket, > > or use the one-to-one model (currently called the TCP model.) > > > >Or we can use sctp_peeloff() to branch off the association into a >separate socket/file descriptor. In this case, if one UDP-style >association becomes blocking, I believe the other association still >works without blocking. I'm a little bit lost after reading this last sentence, because I generally think only in terms of UDP-style "sockets", not UDP-style "associations". But I think I *might* understand what you are saying... let me make things a little more specific, and tell me if I have understood your meaning, as well as the intent of the sockets API internet draft. Assume * there is only one UDP-style socket s1 * association a1 is active on socket s1, * other associations a2 through aN are also active on s1. * association a1 currently has a zero rwnd. If you now do a sendmsg directed towards association a1 on socket s1, then I suggest that a reasonable semantics for "blocking socket" is that sendmsg should block until there is sufficient rwnd space on association a1 for that operation to complete. If that is not the meaning of 'blocking socket' for the so-called "UDP-style syntax", then there probably shouldn't be any reason to have a blocking socket for UDP (for reasons alluded to earlier by Randy Stewart.) (Note: in my earlier message I said "write()", where I should have said sendto() or sendmsg(), I suppose... write() doesn't make much sense on a socket that has multiple associations.) Note, you can't do a sctp_peeloff until that blocked sendmsg() call returns. When you do the sctp_peeloff on socket s1 for association a1, then the result is a brand new TCP-style socket s2 for association a1, and association a1 no longer has any relationship to socket s1. Is this what you mean when you say: "In this case, if one UDP-style association becomes blocking, I believe the other association still works without blocking?" Or are you saying something different? >In my feeling, option 2 is better. On this point, I agree totally: option 2 allows the programmer the choice of non-blocking or blocking behavior. Many programmers may prefer to use non-blocking mode for a "UDP-style" SCTP socket, so that if there is no rwnd space to send some data, the sendmsg() returns immediately with EAGAIN, so that the program can go on to some other task while it is waiting for rwnd space to open up... but it really ought to be up to the programmer. There may be cases where being able to "go to sleep" (i.e. block) until a message can be sent on a particular association is the only logical course of action, and it would be nice to not HAVE TO do an sctp_peeloff() (thus moving over to the TCP-style socket) to have that option available. Come to think of it, maybe that is what you were trying to say... that if I don't allow for blocking UDP-style sockets, I can just call sctp_peeloff after getting the EAGAIN error, and then call write() or send() on my brand new TCP-style socket for the same association. But I think it would be better if this were not the only way to direct the process to "go to sleep until the rwnd opens up on association a". Cheers, Phill Conrad From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Sep 25 07:23:50 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21985 for ; Wed, 25 Sep 2002 07:23:49 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PBGw3x020047; Wed, 25 Sep 2002 04:16:58 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD83224; Wed, 25 Sep 2002 04:17:00 -0700 (PDT) Message-ID: <3D919B2B.5060300@cisco.com> Date: Wed, 25 Sep 2002 06:16:59 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Conrad CC: FUJITA Ken , La Monte Henry Piggy Yarroll , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <200209240310.g8O3A6T23418@baqaqi.chi.il.us> <5.1.0.14.2.20020924102156.0393b0f8@mail.earthlink.net> <5.1.0.14.2.20020924214255.03899070@mail.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Phil: I too am just a bit confused by what Ken is getting at here.. comments below Phillip Conrad wrote: >At 05:06 PM 9/24/2002 -0700, FUJITA Ken wrote: > > >>Phillip, Randy, and Folks >> >> >> >>> There are two choices: >>> >>> (1) make the socket ALWAYS non blocking, in which case a send () >>>directed towards an association that has a zero rwnd should return an >>>error (perhaps EWOULDBLOCK or EAGAIN)? >>> >>> (2) allow blocking behavior... in particular, if you write() on >>>socket s1 directed towards an association a1 with a zero rwnd, that >>>socket should block even if there are other associations a2 through aN >>>that have rwnd space. The user may not like being blocked, but that >>>was part of the bargain he/she made when you chose a blocking >>>UDP-style socket; to avoid that situation, use a non-blocking socket, >>>or use the one-to-one model (currently called the TCP model.) >>> >>> >>> >>Or we can use sctp_peeloff() to branch off the association into a >>separate socket/file descriptor. In this case, if one UDP-style >>association becomes blocking, I believe the other association still >>works without blocking. >> >> > >I'm a little bit lost after reading this last sentence, because I generally think only in terms of UDP-style "sockets", not UDP-style "associations". But I think I *might* understand what you are saying... let me make things a little more specific, and tell me if I have understood your meaning, as well as the intent of the sockets API internet draft. > >Assume > * there is only one UDP-style socket s1 > * association a1 is active on socket s1, > * other associations a2 through aN are also active on s1. > * association a1 currently has a zero rwnd. > >If you now do a sendmsg directed towards association a1 on socket s1, then I suggest that a reasonable semantics for "blocking socket" is that sendmsg should block until there is sufficient rwnd space on association a1 for that operation to complete. > >If that is not the meaning of 'blocking socket' for the so-called "UDP-style syntax", then there probably shouldn't be any reason to have a blocking socket for UDP (for reasons alluded to earlier by Randy Stewart.) > >(Note: in my earlier message I said "write()", where I should have said sendto() or sendmsg(), I suppose... write() doesn't make much sense on a socket that has multiple associations.) > >Note, you can't do a sctp_peeloff until that blocked sendmsg() call returns. When you do the sctp_peeloff on socket s1 for association a1, then the result is a brand new TCP-style socket s2 for association a1, and association a1 no longer has any relationship to socket s1. > >Is this what you mean when you say: "In this case, if one UDP-style association becomes blocking, I believe the other association still works without blocking?" Or are you saying something different? > > > > >>In my feeling, option 2 is better. >> >> > >On this point, I agree totally: option 2 allows the programmer the choice of non-blocking or blocking behavior. > >Many programmers may prefer to use non-blocking mode for a "UDP-style" SCTP socket, so that if there is no rwnd space to send some data, the sendmsg() returns immediately with EAGAIN, so that the program can go on to some other task while it is waiting for rwnd space to open up... but it really ought to be up to the programmer. > > One little note.. it is not just rwnd space that has to run out.. but it is also the space in the socket-buffer. TCP and SCTP allow this behavior.. i.e. when you send and the rwnd is 0 you will be able to continue to send until you hit some max associated with the socketbuffer... now note that if the peers rwnd (initially) is the same value as your socketbuffer than your statements are completely correct... but it is unlikely that this will occur. Also note, I think in past discussion with Jon Grim on some list, we have talked about a 'udp style' socket having socket buffer space allocated to it per association (not per socket)... Not sure how that all works :> and its on my to-do list.. but any way.. back to the main discussion.. >There may be cases where being able to "go to sleep" (i.e. block) until a message can be sent on a particular association is the only logical course of action, and it would be nice to not HAVE TO do an sctp_peeloff() (thus moving over to the TCP-style socket) to have that option available. > >Come to think of it, maybe that is what you were trying to say... that if I don't allow for blocking UDP-style sockets, I can just call sctp_peeloff after getting the EAGAIN error, and then call write() or send() on my brand new TCP-style socket for the same association. But I think it would be better if this were not the only way to direct the process to "go to sleep until the rwnd opens up on association a" > > > Hmm.. I am not sure either which ken meant here... A second note is that I don't think the issue Marco reported is that you can't make things blocking (this works I have tested it).. it is just the default in our implementation is not blocking... No matter which way we make it (for default) I think one must allow the app writter to make a call to toggle things blocking/non-blocking.. The point I was trying to make (and I think I did) is that things are quite the same when comparing UDP style vs UDP... since once you block in a sendto() on one assoc you may not have blocked on another assoc (as you point out) .. Also there is no way to recvfrom() on just a particular association. So a recvfrom() blocking style will return the first message up from any association (I know you realize this.. just reminding everyone else on the list). R -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Sep 25 08:18:42 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23199 for ; Wed, 25 Sep 2002 08:18:41 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PCCh1X003413 for ; Wed, 25 Sep 2002 05:12:43 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PCChiF029507 for ; Wed, 25 Sep 2002 05:12:43 -0700 (PDT) Received: from baqaqi.chi.il.us (12-249-33-191.client.attbi.com [12.249.33.191]) by proxy3.cisco.com (8.12.2/8.11.2) with ESMTP id g8PCCfwi022766 for ; Wed, 25 Sep 2002 05:12:42 -0700 (PDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id g8PC8sD29011 for ; Wed, 25 Sep 2002 07:08:54 -0500 Message-Id: <200209251208.g8PC8sD29011@baqaqi.chi.il.us> To: sctp-impl%external.cisco.com@cisco.com From: "La Monte Henry Piggy Yarroll" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: Your message of Tue, 24 Sep 2002 22:20:06 -0400. <5.1.0.14.2.20020924214255.03899070@mail.earthlink.net> Date: Wed, 25 Sep 2002 07:08:54 -0500 Sender: piggy@baqaqi.chi.il.us Phillip Conrad writes: > At 05:06 PM 9/24/2002 -0700, FUJITA Ken wrote: > >Phillip, Randy, and Folks > > > > > There are two choices: > > > > > > (1) make the socket ALWAYS non blocking, in which case a send () > > > directed towards an association that has a zero rwnd should return an > > > error (perhaps EWOULDBLOCK or EAGAIN)? > > > > > > (2) allow blocking behavior... in particular, if you write() on > > > socket s1 directed towards an association a1 with a zero rwnd, that > > > socket should block even if there are other associations a2 through aN > > > that have rwnd space. The user may not like being blocked, but that > > > was part of the bargain he/she made when you chose a blocking > > > UDP-style socket; to avoid that situation, use a non-blocking socket, > > > or use the one-to-one model (currently called the TCP model.) > > > > > > >Or we can use sctp_peeloff() to branch off the association into a > >separate socket/file descriptor. In this case, if one UDP-style > >association becomes blocking, I believe the other association still > >works without blocking. > > I'm a little bit lost after reading this last sentence, because I > generally think only in terms of UDP-style "sockets", not UDP-style > "associations". But I think I *might* understand what you are > saying... let me make things a little more specific, and tell me if > I have understood your meaning, as well as the intent of the sockets > API internet draft. > > Assume > * there is only one UDP-style socket s1 > * association a1 is active on socket s1, > * other associations a2 through aN are also active on s1. > * association a1 currently has a zero rwnd. There is an extra buffer involved--zero rwnd alone should not be sufficient to cause blocking. From socket(7): SO_SNDBUF Sets or gets the maximum socket send buffer in bytes. The default value is set by the wmem_default sysctl and the maximum allowed value is set by the wmem_max sysctl. This buffer is PER SOCKET rather than per association. Furthermore, it should feed all the associations equally. So if one association runs out of rwnd for sending more data, the socket buffer will eventually fill (with messages for that association). Once the socket buffer fills, ALL send calls should block--this is completely independant of the underlying protocol. From owner-extdom.sctp-impl@sj-msg-core-2.cisco.com Wed Sep 25 13:33:42 2002 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03913 for ; Wed, 25 Sep 2002 13:33:41 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8PH7MHa004542 for ; Wed, 25 Sep 2002 10:07:22 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PH7Lpv023107 for ; Wed, 25 Sep 2002 10:07:21 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g8PH5h6q005791 for ; Wed, 25 Sep 2002 10:05:43 -0700 (PDT) Received: from livingroom.acm.org (pcp01480934pcs.ncstl01.de.comcast.net [68.82.70.108]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0H3000C416N6AW@mtaout05.icomcast.net> for sctp-impl@external.cisco.com; Wed, 25 Sep 2002 12:47:30 -0400 (EDT) Date: Wed, 25 Sep 2002 11:26:12 -0400 From: Phillip Conrad Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode In-reply-to: <200209251206.g8PC61Q29005@baqaqi.chi.il.us> X-Sender: phillipconrad@mail.comcast.net To: La Monte Henry Piggy Yarroll Cc: FUJITA Ken , "Randall Stewart (cisco)" , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Message-id: <5.1.0.14.2.20020925100914.03638528@mail.earthlink.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <"Your message of Tue, 24 Sep 2002 22:20:06 -0400. <5.1.0.14.2.20020924214255.03899070"@mail.earthlink.net> Content-Transfer-Encoding: 7BIT La Monte and Randy raise two points that I suspected were true; I paraphrase these below (with an acknowledged "spin" that is my own, not theirs). I would argue that this calls for at least an "implemenation/usage note"in the sockets API draft. (I trust La Monte and Randy will speak up if I have misunderstood anything) (1) that there is also some extra buffering that will happen in the sockets layer after the rwnd closes... this buffering has to also be exhausted before a sendmsg"() will block because of a zero rwnd. (2) that one association's "personal problem" (i.e. a zero rwnd causing data to back up in the socket buffer) can affect the ability to send data on other associations through a shared UDP-socket. #2 is a new twist on the "fate sharing" principle that applies to UDP-style sockets, and I would suggest it is something we should either prevent (not likely to be feasible) or that users should be warned about. I suggest we just document it, because "fixing it" might require architecturally-prohibited, transport-specific mucking around in the socket layer internals (per assoication socket buffers instead of per-socket socket buffers). Randy is quick to remind me that such ugly hacks are unlikely to be accepted by the defenders of the faith (and rightly so.) So here's some suggested text for the next version of the sockets API draft (where it would go in the outline is left as an exercise to the reader.) [****start of suggested text for sockets api draft****] Implementation and Usage Note for UDP-style sockets: Implementors of the sockets API are free to implement a socket serving multiple associations (e.g., a UDP-style socket) with a single socket buffer shared across all associations. This design has consequences that users of the socket API need to take into account. When a peer advertises a zero rwnd on a particular association, further attempts to send data to that association can eventually cause the socket's output buffer to fill up. When this happens, any attempt to send data over that socket will either block, or return an error (depending on whether the socket is blocking or non-blocking). If the socket is shared across multiple associations, the inability to send further data affects all associations on that socket, not just the association with the zero rwnd. Programmers may want to consider using a single socket per association in any case where it is important to avoid a zero rwnd on one association impacting the ability to send data on another association. [****end of suggested text for sockets api draft****] Cheers, Phill PS: If this seems like too much advice for a document that is just supposed to specify a standard for an API, I can sympathize with this point of view. I don't think the sockets API should spell out "every little trap" that a programmer might fall into using SCTP. We are not in the business of teaching network programming. In particular, anything that is common to programmers experience with TCP and/or UDP is something we don't need to talk about. BUT... when SCTP opens up some entirely "new" kind of trap that no previous experience would prepare a programmer to avoid, I think we have a "duty to inform". Backpressure on a socket from a zero rwnd causing writing to block is "nothing new"... it has happened in TCP for years... but backpressure on one association/connection affecting another association/connection on the same socket is a "new animal". Nothing like this occurs with "plain old UDP" sockets, because there is no rwnd. That's why I think it deserves special mention in the draft. PPS: Here's a question: is it even necessary for there to be a closed rwnd for the socket buffer backup problem to occur? What if we are spraying data at high volume over a large number of associations, each of which is in slow start... could that also cause the socket buffer to gum up? I suppose the difference is that with slow start, as long as the rwnd doesn't fill up and the network is behaving reasonably well, within an RTT or so the buffer will eventually start emptying out at some rate. This is not true of a full rwnd on a peer that is stubbornly refusing to read, perhaps because of a bug in the receiving ULP; in that case, the backup can last indefinitely. From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Sep 25 14:35:55 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05999 for ; Wed, 25 Sep 2002 14:35:50 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PIH51X004915 for ; Wed, 25 Sep 2002 11:17:05 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PIH4fm024204 for ; Wed, 25 Sep 2002 11:17:05 -0700 (PDT) Received: from web10104.mail.yahoo.com (web10104.mail.yahoo.com [216.136.130.54]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id g8PIH1dT004192 for ; Wed, 25 Sep 2002 11:17:02 -0700 (PDT) Message-ID: <20020925181252.38261.qmail@web10104.mail.yahoo.com> Received: from [216.98.102.225] by web10104.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 11:12:52 PDT Date: Wed, 25 Sep 2002 11:12:52 -0700 (PDT) From: "K. Poon" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode To: "Randall Stewart \(cisco\)" , La Monte Henry Piggy Yarroll Cc: Marco Molteni , sctp-impl@external.cisco.com In-Reply-To: <3D904E54.5080702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- "Randall Stewart (cisco)" wrote: > Hmmm... I don't think that any buffer space is consumed by > a udp send call. It is put on the wire when the call is made > and never is it added to the output socket buffer. When the data is copied from user land to kernel land in some OS, memory is needed... > The only way I can imagine it every blocking is ONLY if one chews up > all the MBUF's (say in some tcp connections) and then trys the send. > I > believe > the MGET() call is setup to block in this case.... > > But of course if you chew up all the mbufs in a system things are so > sick I am > not to sure the system would survive :-0 Actually no. It also depends on the OS. For example, some OS can have a call like alloc (NO_WAIT) and alloc(HARDER). The semantics of the first one can be that if there is nothing in the cache (assuming there is an internal kernel memory hierarchy), just return with an error. This can be used for non-blocking socket call. The semantics of the second one can be that the kernel will ask all the subsystema to do some garbage collection and return their own memory cache to the main kernel memory pool. After the garbage collection, the kernel can return memory to the alloc(HARDER) call. The system is still running happiliy, just that the alloc(HARDER) will block for a while. As I mentioned in the earlier mail, it all depends... So I guess the easy solution is to just pick a default and live with it (-: ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Sep 25 14:43:08 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06202 for ; Wed, 25 Sep 2002 14:43:08 -0400 (EDT) Received: from mira-sjc5-2.cisco.com (IDENT:mirapoint@mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PIaZ1X016039; Wed, 25 Sep 2002 11:36:35 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD94141; Wed, 25 Sep 2002 11:36:21 -0700 (PDT) Message-ID: <3D920224.2030201@cisco.com> Date: Wed, 25 Sep 2002 13:36:20 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Conrad CC: La Monte Henry Piggy Yarroll , FUJITA Ken , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <"Your message of Tue, 24 Sep 2002 22:20:06 -0400. <5.1.0.14.2.20020924214255.03899070"@mail.earthlink.net> <5.1.0.14.2.20020925100914.03638528@mail.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Phillip Conrad wrote: >La Monte and Randy raise two points that I suspected were true; I paraphrase these below (with an acknowledged "spin" that is my own, not theirs). I would argue that this calls for at least an "implemenation/usage note"in the sockets API draft. > >(I trust La Monte and Randy will speak up if I have misunderstood anything) > >(1) that there is also some extra buffering that will happen in the sockets layer after the rwnd closes... this buffering has to also be exhausted before a sendmsg"() will block because of a zero rwnd. > >(2) that one association's "personal problem" (i.e. a zero rwnd causing data to back up in the socket buffer) can affect the ability to send data on other associations through a shared UDP-socket. > >#2 is a new twist on the "fate sharing" principle that applies to UDP-style sockets, and I would suggest it is something we should either prevent (not likely to be feasible) or that users should be warned about. > >I suggest we just document it, because "fixing it" might require architecturally-prohibited, transport-specific mucking around in the socket layer internals (per assoication socket buffers instead of per-socket socket buffers). Randy is quick to remind me that such ugly hacks are unlikely to be accepted by the defenders of the faith (and rightly so.) > >So here's some suggested text for the next version of the sockets API draft (where it would go in the outline is left as an exercise to the reader.) > Hmm I think you have it mostly right... I do want to clearify that each association usually has a socketbuffers worth of buffering.. the key is that in the blocking model if I send to assoc-a and it blocks even though assoc-b would NOT block (at that percise moment if I sent to it) I am stuck since .. I am blocked :-0 This is where the non-blocking mode would suit better... i.e. get a EAGAIN back and then one could still write to asoc-b ... > >[****start of suggested text for sockets api draft****] > > >Implementation and Usage Note for UDP-style sockets: > >Implementors of the sockets API are free to implement a socket serving multiple associations (e.g., a UDP-style socket) with a single socket buffer shared across all associations. This design has consequences that users of the socket API need to take into account. > >When a peer advertises a zero rwnd on a particular association, further attempts to send data to that association can eventually cause the socket's output buffer to fill up. When this happens, any attempt to send data over that socket will either block, or return an error (depending on whether the socket is blocking or non-blocking). If the socket is shared across multiple associations, the inability to send further data affects all associations on that socket, not just the association with the zero rwnd. > >Programmers may want to consider using a single socket per association in any case where it is important to avoid a zero rwnd on one association impacting the ability to send data on another association. > >[****end of suggested text for sockets api draft****] > > I think some mention of the NON-BLOCKING mode API as another solution would also be good here.. just saying go to a single socket per association does not do justice to the fact that there is another solution as well... aka set non-blocking... > >Cheers, >Phill > >PS: If this seems like too much advice for a document that is just supposed to specify a standard for an API, I can sympathize with this point of view. I don't think the sockets API should spell out "every little trap" that a programmer might fall into using SCTP. We are not in the business of teaching network programming. In particular, anything that is common to programmers experience with TCP and/or UDP is something we don't need to talk about. > > Somehow I knew a BUT was comming :> >BUT... when SCTP opens up some entirely "new" kind of trap that no previous experience would prepare a programmer to avoid, I think we have a "duty to inform". >Backpressure on a socket from a zero rwnd causing writing to block is "nothing new"... it has happened in TCP for years... but backpressure on one association/connection affecting another association/connection on the same socket is a "new animal". Nothing like this occurs with "plain old UDP" sockets, because there is no rwnd. That's why I think it deserves special mention in the draft. > >PPS: Here's a question: is it even necessary for there to be a closed rwnd for the socket buffer backup problem to occur? What if we are spraying data at high volume over a large number of associations, each of which is in slow start... could that also cause the socket buffer to gum up? I suppose the difference is that with slow start, as long as the rwnd doesn't fill up and the network is behaving reasonably well, within an RTT or so the buffer will eventually start emptying out at some rate. This is not true of a full rwnd on a peer that is stubbornly refusing to read, perhaps because of a bug in the receiving ULP; in that case, the backup can last indefinitely. > > > One could envision a socketbuffer being set to 2k and the rwnd being set (by the peer) to 32k. In such a situation it becomes quite easy to fill up the socket buffer at any given time... even besides your "blast" of data idea... which is also a valid way it can happen.. by the way it happens today in TCP too, even with a single connection. R > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Sep 25 14:48:43 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06401 for ; Wed, 25 Sep 2002 14:48:43 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PIXD1X014052 for ; Wed, 25 Sep 2002 11:33:13 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PIXBtx010645 for ; Wed, 25 Sep 2002 11:33:12 -0700 (PDT) Received: from web10108.mail.yahoo.com (web10108.mail.yahoo.com [216.136.130.58]) by proxy1.cisco.com (8.12.2/8.11.2) with SMTP id g8PIX7dT008447 for ; Wed, 25 Sep 2002 11:33:08 -0700 (PDT) Message-ID: <20020925182858.8341.qmail@web10108.mail.yahoo.com> Received: from [216.98.102.225] by web10108.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 11:28:58 PDT Date: Wed, 25 Sep 2002 11:28:58 -0700 (PDT) From: "K. Poon" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode To: Jon Grimm , "Randall Stewart \(cisco\)" Cc: Marco Molteni , sctp-impl@external.cisco.com, La Monte Henry Piggy Yarroll In-Reply-To: <3D906543.F32DC7F5@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Jon Grimm wrote: > Or stated in another way... will receiving an EAGAIN error from > sendto() suprise any UDP-style model in the face of SCTP output > buffers > filling up? ;-) > > Its not a clean fit either way...SCTP is so much more than UDP that > its > difficult to > get the absolute behavior of SOCK_DGRAM (Is this why SOCK_DGRAM was > not > used?) > > One thing we touched on a bit out at the Bakeoff and should probably > spin into its own thread if folks think interesting is that of the > UDP-style API itself: Is the UDP-style > API goal really towards a programming model or towards SOCK_DGRAM > transparency? > (or likely even a little of both). Some background... When the current draft was first written, only the TCP style socket mapping was designed towards compatibility. We had a somewhat "heated" phone conference about what the socket mapping should be, as I recalled... The end result was to have 2 different mappings, TCP and UDP style. I guess Randy can answer his intention behind the UDP style socket. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-1.cisco.com Wed Sep 25 15:21:42 2002 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07374 for ; Wed, 25 Sep 2002 15:21:41 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJ3Q1X001830 for ; Wed, 25 Sep 2002 12:03:26 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJ3Q8Q012164 for ; Wed, 25 Sep 2002 12:03:26 -0700 (PDT) Received: from web10104.mail.yahoo.com (web10104.mail.yahoo.com [216.136.130.54]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g8PJ2S6q023090 for ; Wed, 25 Sep 2002 12:02:29 -0700 (PDT) Message-ID: <20020925190017.47643.qmail@web10104.mail.yahoo.com> Received: from [216.98.102.225] by web10104.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 12:00:17 PDT Date: Wed, 25 Sep 2002 12:00:17 -0700 (PDT) From: "K. Poon" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode To: "Randall Stewart \(cisco\)" , Phillip Conrad Cc: FUJITA Ken , La Monte Henry Piggy Yarroll , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com In-Reply-To: <3D919B2B.5060300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- "Randall Stewart (cisco)" wrote: > One little note.. it is not just rwnd space that has to run out.. but > it > is also the space in the socket-buffer. TCP and > SCTP allow this behavior.. i.e. when you send and the rwnd is 0 you > will > be able to continue > to send until you hit some max associated with the socketbuffer... > now > note that if the peers rwnd (initially) > is the same value as your socketbuffer than your statements are > completely correct... but it is unlikely > that this will occur. > > Also note, I think in past discussion with Jon Grim on some list, we > have talked about a 'udp style' socket > having socket buffer space allocated to it per association (not per > socket)... Not sure how that all works :> > and its on my to-do list.. but any way.. back to the main > discussion.. I think we have talked about this funny socket buffer issue before, if I remember correctly... One issue with the per association socket buffer allocation with a UDP style socket is that the OS needs to have another kind of resource control. Right now, I believe all OSes impose a limit on the number of sockets a user can open, and the maximum buffer size each socket can use. This cannot control the per association socket buffer allocation scheme. Well, it is just code, but one important rationale behind the draft is that the socket layer in most OSes does not need to be fundamentally changed, if possible. > Hmm.. I am not sure either which ken meant here... A second note is > that > I don't think the > issue Marco reported is that you can't make things blocking (this > works > I have tested it).. it is > just the default in our implementation is not blocking... > > No matter which way we make it (for default) I think one must allow > the > app writter to make > a call to toggle things blocking/non-blocking.. Agree. > The point I was trying to make (and I think I did) is that things are > > quite the same when comparing > UDP style vs UDP... since once you block in a sendto() on one assoc > you > may not have blocked on > another assoc (as you point out) .. Also there is no way to > recvfrom() > on just a particular association. So > a recvfrom() blocking style will return the first message up from any > > association (I know you realize > this.. just reminding everyone else on the list). ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Wed Sep 25 15:27:16 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07620 for ; Wed, 25 Sep 2002 15:27:15 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJG83x015130 for ; Wed, 25 Sep 2002 12:16:08 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJGDin022752 for ; Wed, 25 Sep 2002 12:16:13 -0700 (PDT) Received: from web10108.mail.yahoo.com (web10108.mail.yahoo.com [216.136.130.58]) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g8PJFG6q004124 for ; Wed, 25 Sep 2002 12:15:16 -0700 (PDT) Message-ID: <20020925191348.17424.qmail@web10108.mail.yahoo.com> Received: from [216.98.102.225] by web10108.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 12:13:48 PDT Date: Wed, 25 Sep 2002 12:13:48 -0700 (PDT) From: "K. Poon" Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode To: Phillip Conrad , La Monte Henry Piggy Yarroll Cc: FUJITA Ken , "Randall Stewart \(cisco\)" , "K. Poon" , Marco Molteni , sctp-impl@external.cisco.com In-Reply-To: <5.1.0.14.2.20020925100914.03638528@mail.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Phillip Conrad wrote: [Some notes deleted.] > [****start of suggested text for sockets api draft****] > > > Implementation and Usage Note for UDP-style sockets: > > Implementors of the sockets API are free to implement a socket > serving multiple associations (e.g., a UDP-style socket) with a > single socket buffer shared across all associations. This design > has consequences that users of the socket API need to take into > account. > > When a peer advertises a zero rwnd on a particular association, > further attempts to send data to that association can eventually > cause the socket's output buffer to fill up. When this happens, > any attempt to send data over that socket will either block, or > return an error (depending on whether the socket is blocking or > non-blocking). If the socket is shared across multiple > associations, the inability to send further data affects all > associations on that socket, not just the association with the zero > rwnd. > > Programmers may want to consider using a single socket per > association in any case where it is important to avoid a zero rwnd on > one association impacting the ability to send data on another > association. > > [****end of suggested text for sockets api draft****] > > > Cheers, > Phill > > PS: If this seems like too much advice for a document that is just > supposed to specify a standard for an API, I can sympathize with this > point of view. I don't think the sockets API should spell out "every > little trap" that a programmer might fall into using SCTP. We are > not in the business of teaching network programming. In particular, > anything that is common to programmers experience with TCP and/or UDP > is something we don't need to talk about. Another thing I don't like is the mention of the internal working of an implementation and the protocol (rwnd). I think the draft should stay away from that. > BUT... when SCTP opens up some entirely "new" kind of trap that no > previous experience would prepare a programmer to avoid, I think we > have a "duty to inform". > Backpressure on a socket from a zero rwnd causing writing to block is > "nothing new"... it has happened in TCP for years... but > backpressure on one association/connection affecting another > association/connection on the same socket is a "new animal". > Nothing like this occurs with "plain old UDP" sockets, because there > is no rwnd. That's why I think it deserves special mention in the > draft. Another way is to convey this is to stress the point of blocking and non-blocking of socket call, and the return error code. This is an API draft, so we should stick to an API specification. > PPS: Here's a question: is it even necessary for there to be a > closed rwnd for the socket buffer backup problem to occur? What if > we are spraying data at high volume over a large number of > associations, each of which is in slow start... could that also cause > the socket buffer to gum up? I suppose the difference is that with > slow start, as long as the rwnd doesn't fill up and the network is > behaving reasonably well, within an RTT or so the buffer will > eventually start emptying out at some rate. This is not true of a > full rwnd on a peer that is stubbornly refusing to read, perhaps > because of a bug in the receiving ULP; in that case, the backup can > last indefinitely. Well, this is a bug in the app's protocol... I guess we cannot do anything. This can happen right now with any TCP app too. ===== K. Poon. kcpoon@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-extdom.sctp-impl@sj-msg-core-4.cisco.com Wed Sep 25 15:30:59 2002 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07720 for ; Wed, 25 Sep 2002 15:30:58 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJ5kW4016646 for ; Wed, 25 Sep 2002 12:05:46 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PJ5jpG004099 for ; Wed, 25 Sep 2002 12:05:46 -0700 (PDT) Received: from txsmtp01.texas.rr.com (smtp1.texas.rr.com [24.93.36.229]) by proxy2.cisco.com (8.12.2/8.11.2) with ESMTP id g8PJ3T6s024021 for ; Wed, 25 Sep 2002 12:04:47 -0700 (PDT) Received: from us.ibm.com (cs242715-27.austin.rr.com [24.27.15.27]) by txsmtp01.texas.rr.com (8.12.5/8.12.2) with ESMTP id g8PJ3Lss026974; Wed, 25 Sep 2002 15:03:21 -0400 (EDT) Message-ID: <3D9208A6.9030505@us.ibm.com> Date: Wed, 25 Sep 2002 14:04:06 -0500 From: Jon Grimm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "K. Poon" CC: "Randall Stewart (cisco)" , Marco Molteni , sctp-impl@external.cisco.com, La Monte Henry Piggy Yarroll Subject: Re: (SCTP) draft-ietf-tsvwg-sctpsocket-04.txt and non-blocking mode References: <20020925182858.8341.qmail@web10108.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit K. Poon wrote: > --- Jon Grimm wrote: > >>Or stated in another way... will receiving an EAGAIN error from >>sendto() suprise any UDP-style model in the face of SCTP output >>buffers >>filling up? ;-) >> >>Its not a clean fit either way...SCTP is so much more than UDP that >>its >>difficult to >>get the absolute behavior of SOCK_DGRAM (Is this why SOCK_DGRAM was >>not >>used?) >> >>One thing we touched on a bit out at the Bakeoff and should probably >>spin into its own thread if folks think interesting is that of the >>UDP-style API itself: Is the UDP-style >>API goal really towards a programming model or towards SOCK_DGRAM >>transparency? >>(or likely even a little of both). > > > Some background... > > When the current draft was first written, only the TCP style > socket mapping was designed towards compatibility. We had a > somewhat "heated" phone conference about what the socket mapping > should be, as I recalled... The end result was to have 2 different > mappings, TCP and UDP style. I guess Randy can answer his > intention behind the UDP style socket. > > Yes, this is in part how the discussion arose, I think Phil brought up that the UDP-style was really a different beast than UDP (SOCK_DGRAM) programming. One option is to change the name.. Phil had been proposing, IIRC, Explicit vs Implicit SCTP sockets, but this didn't seem needed since TCP-style really does try to have API compatibility with SOCK_STREAM/TCP, so the terminology of "Explicit" only adds to the confusion. One idea brought out at the bakeoff would be to make the default UDP-style behavior more SOCK_DGRAM application friendly: 1) Auto-listen Enabled 2) Auto-connect Enabled (already a default) 3) Events Disabled. 4) AUTO-CLOSE Enabled. Or...Another approach would be just to claim that UDP-style is a completely different beast and application writers using it must understand how and why it is different than SOCK_DGRAM programming. Having default behavior that break application compatibility helps force the application writer to come up to speed. ;-) Thanks, jon > > > ===== > K. Poon. kcpoon@yahoo.com > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com > From owner-extdom.sctp-impl@sj-msg-core-3.cisco.com Sat Sep 28 07:45:59 2002 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03590 for ; Sat, 28 Sep 2002 07:45:58 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8SBdVaW009431 for ; Sat, 28 Sep 2002 04:39:31 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8SBdbOr004424 for ; Sat, 28 Sep 2002 04:39:37 -0700 (PDT) Received: from ab97c2518.com (host-217-146-2-114.warsun.com [217.146.2.114] (may be forged)) by proxy2.cisco.com (8.12.2/8.11.2) with SMTP id g8SBbsAo026913 for ; Sat, 28 Sep 2002 04:38:09 -0700 (PDT) Message-Id: <200209281138.g8SBbsAo026913@proxy2.cisco.com> From: "Engr. Saheed Ibraheem" Reply-To: saheed_ibraheem@uymail.com To: sctp-impl@external.cisco.com Date: Sat, 28 Sep 2002 12:38:03 -0700 Subject: urgent reply 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 HAA03590 Dear Sir, Attention: I am Engineer Saheed Ibraheem, the chairman of senate House Committee on contract award. I got your address through directory of companies made available to us through our chamber of commerce. The urgency of this subject of proposal compelled me to contact you through email I have been assign by my colleagues (two of them) to seek for assistance of a reliable/trustworthy Person/company into whose account we can Transfer the sum of (US$50) Fifty million United State Dollars Only. This money is an accumulation from over-invoiced contracts which our committee awarded to two foreign firms between last year and now – for Repair and Refurbishment of Warri and Port Harcourt Oil Refineries. Having completed the contracts, and the site been commissioned, the contractors had since been paid their original contract cost; and we are now left with this excess of (US$50m) as deliberately over invoiced, for us to transfer into a suitable foreign account, this is because the Federal Government of Nigeria Prohibits all Civil Servant from operating Off-shore account(s), for obvious reasons. We have decided that when the money is confirmed in your account, you shall be entitled to 35% of the total sum, 60% for us here, while 5% shall cover for any eventual local and off-shore expenses, if needed be. The nature of your business does not affect the success of this transaction. All we require from you is your co-operation and trust; and your ability to give us a good account that shall accommodate the sum of money. You must also assure us of our own share of 60% when the money is confirmed in your account. Furthermore, this business is risk-free, as all necessary strategies have been put in place for its smoothness and success. We have already established helpful contacts in the various area and parastatals responsible for the transfer of this fund. Furthermore if you accept this proposal, I want you to send me your bank particulars as follows. The name of your bank where this money will be transferred in, and your bank particulars, account number, your phone and fax number for easy contact and security reason. This is our lifetime opportunity for both of us, don’t miss this great chance, we are now in democracy that is why we have this opportunity to transfer this money out now from the country. If therefore you are interested in my proposal Contact me at the above e-mail address the written valid up, and I shall oblige you with further information and answer any question you may ask. Finally, it is expected that the transaction will Last for 14 working days upon your cooperation, barring any delay. Best Regards, Engineer Saheed Ibraheem.