From kacheong.poon@sun.com Thu Feb 26 01:24:12 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D473A3A6BE4 for ; Thu, 26 Feb 2009 01:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPDnz7t8K18S for ; Thu, 26 Feb 2009 01:24:12 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id E0F153A685B for ; Thu, 26 Feb 2009 01:24:11 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1Q9OUcj000241; Thu, 26 Feb 2009 09:24:30 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1Q9No40274330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 01:24:25 -0800 (PST) Message-ID: <49A65FAA.8090503@sun.com> Date: Thu, 26 Feb 2009 17:23:54 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Randy Stewart References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> In-Reply-To: <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:24:12 -0000 Randy Stewart wrote: > Michael so what you are proposing is that we: > > 1) Keep the existing SCTP_EVENT's socket call. > > 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a > sctp_assoc_value structure. Where the assoc-id is the > assoc you want the notification on. And the value is the > Notification id. We would type all current notifications > with constants e.g. SCTP_DRY_NOTIFICATION FWIW, my original thinking was to have SCTP level socket options like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct sctp_assoc_value. So for each event, there is a corresponding status option. This is similar to other existing socket options, SO_REUSEADDR, SO_BROADCAST, ... > 3) I think we would want 0 to be again, future associations > and non-zero to be specific associations. > > > Now this would also mean that the existing SCTP_EVENT's would have > a slight change, which I think is ok. It would now be a short cut > equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with > the assoc-id set to 0. I.e. it would ONLY effect future assoc's. This brings up a good point. I think we need to be clear here. For options which we've defined to use assoc_id explicitly, I think the above 0 mean future is OK. This is something new. But for options, such as SO_RCVBUF, I guess the expected semantics is to affect all associations under the control of a 1-N socket. I believe this is how options like SO_RCVBUF on a SCTP socket is implemented. For SO_RCVBUF, I guess this is true in both cases when every associations has its own buffer or all the associations share the same buffer. Following this thinking, the SCTP_EVENTS option should affect all the associations under the control of a 1-N socket. And I guess this is what is implied in the current draft. So I think changing its semantics to match the individual event status option is not a good idea. And because of this, we may need to think about if it makes sense to extend the meaning on the use of assoc_id in those options. As defined currently, 0 assoc_id means future associations. There is no way to apply those options to all existing associations under a 1-N socket. In sending, we have the SCTP_SENDALL flag to do something like this. I'm not sure if this is really needed. But it is something to consider. -- K. Poon. kacheong.poon@sun.com From randall@lakerest.net Thu Feb 26 04:21:47 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231EE3A692E for ; Thu, 26 Feb 2009 04:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RnXRFsxUhsR for ; Thu, 26 Feb 2009 04:21:46 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 889513A68BD for ; Thu, 26 Feb 2009 04:21:45 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1QCMBpS000454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Feb 2009 07:22:11 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> From: Randy Stewart To: Kacheong Poon In-Reply-To: <49A65FAA.8090503@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 07:22:01 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:21:47 -0000 On Feb 26, 2009, at 4:23 AM, Kacheong Poon wrote: > Randy Stewart wrote: > >> Michael so what you are proposing is that we: >> 1) Keep the existing SCTP_EVENT's socket call. >> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >> sctp_assoc_value structure. Where the assoc-id is the >> assoc you want the notification on. And the value is the >> Notification id. We would type all current notifications >> with constants e.g. SCTP_DRY_NOTIFICATION > > > FWIW, my original thinking was to have SCTP level socket options > like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct > sctp_assoc_value. So for each event, there is a corresponding > status option. This is similar to other existing socket options, > SO_REUSEADDR, SO_BROADCAST, ... Ok, so let me see. Are you advocating using specific events with an sctp_assoc_value structure... I am find with that. We would then just create a new socket option for EACH event. Which I like better than creating another structure. The only alternative I could think of would be to "enhance" the sctp_assoc_value to be struct sctp_assoc_value { sctp_assoc_t assoc_id; union { uint32_t val32; uint16_t val16[2]; uint8_t vall8[4]; } }; Which may pose for some an ABI issue so it might not be palatable. Now in thinking about this we probably SHOULD have defined the structure that way anyway to provide utmost flexibility.. but of course thats water under the bridge. Your way works and does not venture us down the path of changing the sctp_assoc_value structure.. probably the best way... > > > >> 3) I think we would want 0 to be again, future associations >> and non-zero to be specific associations. >> Now this would also mean that the existing SCTP_EVENT's would have >> a slight change, which I think is ok. It would now be a short cut >> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. > > > This brings up a good point. I think we need to be clear here. > For options which we've defined to use assoc_id explicitly, I > think the above 0 mean future is OK. This is something new. > But for options, such as SO_RCVBUF, I guess the expected semantics > is to affect all associations under the control of a 1-N socket. > I believe this is how options like SO_RCVBUF on a SCTP socket is > implemented. For SO_RCVBUF, I guess this is true in both cases > when every associations has its own buffer or all the associations > share the same buffer. I don't think changing the SO_RCVBUF has a way of specifying a assoc_id... so this is logical. If you cannot specify a assoc, then its a global setting over the whole 1-M socket. However if you are allowed to specify an assoc_id, then 0 is for all future assoc (i.e. you are setting the default for future associations) and setting the assoc-id specifies who you want the option set on. I think its important we specify this behavior, if we don't already do so. > > > Following this thinking, the SCTP_EVENTS option should affect > all the associations under the control of a 1-N socket. And I > guess this is what is implied in the current draft. So I think > changing its semantics to match the individual event status > option is not a good idea. This is probably true. Since it does not give you the option to specify an assoc-id then it definitely implies that you have a setting on all assocs. This will be a bit more code to implement.. but that is no big deal. Probably maintaining current semantics is best :-) > > > And because of this, we may need to think about if it makes sense > to extend the meaning on the use of assoc_id in those options. As > defined currently, 0 assoc_id means future associations. There is > no way to apply those options to all existing associations under > a 1-N socket. In sending, we have the SCTP_SENDALL flag to do > something like this. I'm not sure if this is really needed. But > it is something to consider. True. So if we go the route of having options that take an assoc/value structure for each event, and future new event. Then we would in effect make the original events be able to be specified with the EVENTS option on all existing assoc's but future events (if any our defined) would not gain that ability.. I don't think this is a big deal. As I said most programs set this stuff up at the beginning and do not change it. The sender_dry_event is a special case deal for DTLS.. so I think we can probably live with this.. So are we all in agreement we should do as Kacheong specifies here.. i.e. add the SCTP_SENDER_DRY_EVENT ... SCTP_XXXX_EVENT all taking a sctp_assoc_value structure? I will agree to this Vlad, Michael, Others?? comments?? R > > > > > > > -- > > K. Poon. > kacheong.poon@sun.com > ----- Randall Stewart randall@lakerest.net From Michael.Tuexen@lurchi.franken.de Thu Feb 26 05:26:11 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3FF3A691B for ; Thu, 26 Feb 2009 05:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NijDobAB1Cf for ; Thu, 26 Feb 2009 05:26:10 -0800 (PST) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 997D03A6967 for ; Thu, 26 Feb 2009 05:26:10 -0800 (PST) Received: from [192.168.1.4] (p5481F449.dip.t-dialin.net [84.129.244.73]) by mail-n.franken.de (Postfix) with ESMTP id B9E251C0B4629; Thu, 26 Feb 2009 14:26:29 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Randy Stewart In-Reply-To: <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 14:26:28 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:26:12 -0000 On Feb 26, 2009, at 1:22 PM, Randy Stewart wrote: > > On Feb 26, 2009, at 4:23 AM, Kacheong Poon wrote: > >> Randy Stewart wrote: >> >>> Michael so what you are proposing is that we: >>> 1) Keep the existing SCTP_EVENT's socket call. >>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>> sctp_assoc_value structure. Where the assoc-id is the >>> assoc you want the notification on. And the value is the >>> Notification id. We would type all current notifications >>> with constants e.g. SCTP_DRY_NOTIFICATION >> >> >> FWIW, my original thinking was to have SCTP level socket options >> like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct >> sctp_assoc_value. So for each event, there is a corresponding >> status option. This is similar to other existing socket options, >> SO_REUSEADDR, SO_BROADCAST, ... > > Ok, so let me see. Are you advocating using specific > events with an sctp_assoc_value structure... I am find > with that. We would then just create a new socket option > for EACH event. Which I like better than creating another This sounds like a good idea. > > structure. The only alternative I could think of would > be to "enhance" the sctp_assoc_value to be > > struct sctp_assoc_value { > sctp_assoc_t assoc_id; > union { > uint32_t val32; > uint16_t val16[2]; > uint8_t vall8[4]; > } > }; I suggest to keep the old structure and use for the socket options being discussed only whether the assoc_value is 0 or not. > > > Which may pose for some an ABI issue so it might not be palatable. Now > in thinking about this we probably SHOULD have defined the structure > that way anyway to provide utmost flexibility.. but of course thats > water under the bridge. > > Your way works and does not venture us down the path of changing the > sctp_assoc_value structure.. probably the best way... I vote for Kacheongs method. > > >> >> >> >>> 3) I think we would want 0 to be again, future associations >>> and non-zero to be specific associations. >>> Now this would also mean that the existing SCTP_EVENT's would have >>> a slight change, which I think is ok. It would now be a short cut >>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >> >> >> This brings up a good point. I think we need to be clear here. >> For options which we've defined to use assoc_id explicitly, I >> think the above 0 mean future is OK. This is something new. >> But for options, such as SO_RCVBUF, I guess the expected semantics >> is to affect all associations under the control of a 1-N socket. >> I believe this is how options like SO_RCVBUF on a SCTP socket is >> implemented. For SO_RCVBUF, I guess this is true in both cases >> when every associations has its own buffer or all the associations >> share the same buffer. > > I don't think changing the SO_RCVBUF has a way of specifying > a assoc_id... so this is logical. If you cannot specify > a assoc, then its a global setting over the whole 1-M socket. > However if you are allowed to specify an assoc_id, then 0 is > for all future assoc (i.e. you are setting the default for > future associations) and setting the assoc-id specifies who > you want the option set on. > > I think its important we specify this behavior, if we don't > already do so. > >> >> >> Following this thinking, the SCTP_EVENTS option should affect >> all the associations under the control of a 1-N socket. And I >> guess this is what is implied in the current draft. So I think >> changing its semantics to match the individual event status >> option is not a good idea. > > > This is probably true. Since it does not give you the option > to specify an assoc-id then it definitely implies that you > have a setting on all assocs. This will be a bit more code > to implement.. but that is no big deal. Probably maintaining > current semantics is best :-) > >> >> >> And because of this, we may need to think about if it makes sense >> to extend the meaning on the use of assoc_id in those options. As >> defined currently, 0 assoc_id means future associations. There is >> no way to apply those options to all existing associations under >> a 1-N socket. In sending, we have the SCTP_SENDALL flag to do >> something like this. I'm not sure if this is really needed. But >> it is something to consider. > > > True. So if we go the route of having options that take an > assoc/value structure for each event, and future new event. > Then we would in effect make the original events be able to > be specified with the EVENTS option on all existing assoc's > but future events (if any our defined) would not gain that > ability.. I don't think this is a big deal. As I said > most programs set this stuff up at the beginning and do > not change it. > > The sender_dry_event is a special case deal for DTLS.. so I > think we can probably live with this.. > > So are we all in agreement we should do as Kacheong specifies here.. > i.e. > add the > > SCTP_SENDER_DRY_EVENT > ... > SCTP_XXXX_EVENT > > all taking a sctp_assoc_value structure? > > I will agree to this Vlad, Michael, Others?? comments?? > > R > > >> >> >> >> >> >> >> -- >> >> K. Poon. >> kacheong.poon@sun.com >> > > ----- > Randall Stewart > randall@lakerest.net > > > > > From vladislav.yasevich@hp.com Thu Feb 26 05:49:39 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90D13A6A2B for ; Thu, 26 Feb 2009 05:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.565 X-Spam-Level: X-Spam-Status: No, score=-105.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr0wRBGvJpIE for ; Thu, 26 Feb 2009 05:49:38 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id C69FF3A692E for ; Thu, 26 Feb 2009 05:49:38 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 7BEC33861C; Thu, 26 Feb 2009 13:49:59 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 80B6A1000B; Thu, 26 Feb 2009 13:49:58 +0000 (UTC) Message-ID: <49A69E05.8080807@hp.com> Date: Thu, 26 Feb 2009 08:49:57 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Stewart References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> In-Reply-To: <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?en?= , Kacheong Poon , =?ISO-8859-1?Q?Michael_T=FCx?=, tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:49:39 -0000 Randy Stewart wrote: > > On Feb 26, 2009, at 4:23 AM, Kacheong Poon wrote: > >> Randy Stewart wrote: >> >>> Michael so what you are proposing is that we: >>> 1) Keep the existing SCTP_EVENT's socket call. >>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>> sctp_assoc_value structure. Where the assoc-id is the >>> assoc you want the notification on. And the value is the >>> Notification id. We would type all current notifications >>> with constants e.g. SCTP_DRY_NOTIFICATION >> >> >> FWIW, my original thinking was to have SCTP level socket options >> like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct >> sctp_assoc_value. So for each event, there is a corresponding >> status option. This is similar to other existing socket options, >> SO_REUSEADDR, SO_BROADCAST, ... > > Ok, so let me see. Are you advocating using specific > events with an sctp_assoc_value structure... I am find > with that. We would then just create a new socket option > for EACH event. Which I like better than creating another > structure. The only alternative I could think of would > be to "enhance" the sctp_assoc_value to be > > struct sctp_assoc_value { > sctp_assoc_t assoc_id; > union { > uint32_t val32; > uint16_t val16[2]; > uint8_t vall8[4]; > } > }; > > Which may pose for some an ABI issue so it might not be palatable. Now > in thinking about this we probably SHOULD have defined the structure > that way anyway to provide utmost flexibility.. but of course thats > water under the bridge. > > Your way works and does not venture us down the path of changing the > sctp_assoc_value structure.. probably the best way... > >> >> >> >>> 3) I think we would want 0 to be again, future associations >>> and non-zero to be specific associations. >>> Now this would also mean that the existing SCTP_EVENT's would have >>> a slight change, which I think is ok. It would now be a short cut >>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >> >> >> This brings up a good point. I think we need to be clear here. >> For options which we've defined to use assoc_id explicitly, I >> think the above 0 mean future is OK. This is something new. >> But for options, such as SO_RCVBUF, I guess the expected semantics >> is to affect all associations under the control of a 1-N socket. >> I believe this is how options like SO_RCVBUF on a SCTP socket is >> implemented. For SO_RCVBUF, I guess this is true in both cases >> when every associations has its own buffer or all the associations >> share the same buffer. > > I don't think changing the SO_RCVBUF has a way of specifying > a assoc_id... so this is logical. If you cannot specify > a assoc, then its a global setting over the whole 1-M socket. > However if you are allowed to specify an assoc_id, then 0 is > for all future assoc (i.e. you are setting the default for > future associations) and setting the assoc-id specifies who > you want the option set on. > > I think its important we specify this behavior, if we don't > already do so. > >> >> >> Following this thinking, the SCTP_EVENTS option should affect >> all the associations under the control of a 1-N socket. And I >> guess this is what is implied in the current draft. So I think >> changing its semantics to match the individual event status >> option is not a good idea. > > > This is probably true. Since it does not give you the option > to specify an assoc-id then it definitely implies that you > have a setting on all assocs. This will be a bit more code > to implement.. but that is no big deal. Probably maintaining > current semantics is best :-) > >> >> >> And because of this, we may need to think about if it makes sense >> to extend the meaning on the use of assoc_id in those options. As >> defined currently, 0 assoc_id means future associations. There is >> no way to apply those options to all existing associations under >> a 1-N socket. In sending, we have the SCTP_SENDALL flag to do >> something like this. I'm not sure if this is really needed. But >> it is something to consider. > > > True. So if we go the route of having options that take an > assoc/value structure for each event, and future new event. > Then we would in effect make the original events be able to > be specified with the EVENTS option on all existing assoc's > but future events (if any our defined) would not gain that > ability.. I don't think this is a big deal. As I said > most programs set this stuff up at the beginning and do > not change it. > I am not sure I really like the inconsistency. What we are saying here is that SCTP_EVENTS socket option can completely overwrite a singular SCTP_EVENT option, which is supposed to be more specific that the per socket SCTP_EVENTS. I think that the new SCTP_EVENT socket option with association id of 0 should have the same semantics as SCTP_EVENTS option (which does't take association id). I think that creates a much clearer API. After all, what really started this was the ability to set a per-association event mask. So, I think that the new SCTP_EVENT with an association id of 0 should modify all associations that currently belong to the given socket. > The sender_dry_event is a special case deal for DTLS.. so I > think we can probably live with this.. > > So are we all in agreement we should do as Kacheong specifies here.. i.e. > add the > > SCTP_SENDER_DRY_EVENT > ... > SCTP_XXXX_EVENT > > all taking a sctp_assoc_value structure? I am fine with having a separate socket option per event. -vlad > > I will agree to this Vlad, Michael, Others?? comments?? > > R > > >> >> >> >> >> >> >> -- >> >> K. Poon. >> kacheong.poon@sun.com >> > > ----- > Randall Stewart > randall@lakerest.net > > > > From randall@lakerest.net Thu Feb 26 12:29:19 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E58C3A69B1 for ; Thu, 26 Feb 2009 12:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVN8SFinw+Gj for ; Thu, 26 Feb 2009 12:29:18 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id C365C3A68B8 for ; Thu, 26 Feb 2009 12:29:17 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1QKTi99019759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Feb 2009 15:29:44 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <55959D91-93E6-4D96-B892-22C3FA4942DC@lakerest.net> From: Randy Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 15:29:34 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:29:19 -0000 Works for me :-) R On Feb 26, 2009, at 8:26 AM, Michael T=FCxen wrote: > On Feb 26, 2009, at 1:22 PM, Randy Stewart wrote: > >> >> On Feb 26, 2009, at 4:23 AM, Kacheong Poon wrote: >> >>> Randy Stewart wrote: >>> >>>> Michael so what you are proposing is that we: >>>> 1) Keep the existing SCTP_EVENT's socket call. >>>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>>> sctp_assoc_value structure. Where the assoc-id is the >>>> assoc you want the notification on. And the value is the >>>> Notification id. We would type all current notifications >>>> with constants e.g. SCTP_DRY_NOTIFICATION >>> >>> >>> FWIW, my original thinking was to have SCTP level socket options >>> like SCTP_EVENT_SEND_DRY_STATUS and the option value is struct >>> sctp_assoc_value. So for each event, there is a corresponding >>> status option. This is similar to other existing socket options, >>> SO_REUSEADDR, SO_BROADCAST, ... >> >> Ok, so let me see. Are you advocating using specific >> events with an sctp_assoc_value structure... I am find >> with that. We would then just create a new socket option >> for EACH event. Which I like better than creating another > This sounds like a good idea. >> >> structure. The only alternative I could think of would >> be to "enhance" the sctp_assoc_value to be >> >> struct sctp_assoc_value { >> sctp_assoc_t assoc_id; >> union { >> uint32_t val32; >> uint16_t val16[2]; >> uint8_t vall8[4]; >> } >> }; > I suggest to keep the old structure and use for the > socket options being discussed only whether the assoc_value > is 0 or not. >> >> >> Which may pose for some an ABI issue so it might not be palatable. =20= >> Now >> in thinking about this we probably SHOULD have defined the structure >> that way anyway to provide utmost flexibility.. but of course thats >> water under the bridge. >> >> Your way works and does not venture us down the path of changing the >> sctp_assoc_value structure.. probably the best way... > I vote for Kacheongs method. >> >> >>> >>> >>> >>>> 3) I think we would want 0 to be again, future associations >>>> and non-zero to be specific associations. >>>> Now this would also mean that the existing SCTP_EVENT's would have >>>> a slight change, which I think is ok. It would now be a short cut >>>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >>> >>> >>> This brings up a good point. I think we need to be clear here. >>> For options which we've defined to use assoc_id explicitly, I >>> think the above 0 mean future is OK. This is something new. >>> But for options, such as SO_RCVBUF, I guess the expected semantics >>> is to affect all associations under the control of a 1-N socket. >>> I believe this is how options like SO_RCVBUF on a SCTP socket is >>> implemented. For SO_RCVBUF, I guess this is true in both cases >>> when every associations has its own buffer or all the associations >>> share the same buffer. >> >> I don't think changing the SO_RCVBUF has a way of specifying >> a assoc_id... so this is logical. If you cannot specify >> a assoc, then its a global setting over the whole 1-M socket. >> However if you are allowed to specify an assoc_id, then 0 is >> for all future assoc (i.e. you are setting the default for >> future associations) and setting the assoc-id specifies who >> you want the option set on. >> >> I think its important we specify this behavior, if we don't >> already do so. >> >>> >>> >>> Following this thinking, the SCTP_EVENTS option should affect >>> all the associations under the control of a 1-N socket. And I >>> guess this is what is implied in the current draft. So I think >>> changing its semantics to match the individual event status >>> option is not a good idea. >> >> >> This is probably true. Since it does not give you the option >> to specify an assoc-id then it definitely implies that you >> have a setting on all assocs. This will be a bit more code >> to implement.. but that is no big deal. Probably maintaining >> current semantics is best :-) >> >>> >>> >>> And because of this, we may need to think about if it makes sense >>> to extend the meaning on the use of assoc_id in those options. As >>> defined currently, 0 assoc_id means future associations. There is >>> no way to apply those options to all existing associations under >>> a 1-N socket. In sending, we have the SCTP_SENDALL flag to do >>> something like this. I'm not sure if this is really needed. But >>> it is something to consider. >> >> >> True. So if we go the route of having options that take an >> assoc/value structure for each event, and future new event. >> Then we would in effect make the original events be able to >> be specified with the EVENTS option on all existing assoc's >> but future events (if any our defined) would not gain that >> ability.. I don't think this is a big deal. As I said >> most programs set this stuff up at the beginning and do >> not change it. >> >> The sender_dry_event is a special case deal for DTLS.. so I >> think we can probably live with this.. >> >> So are we all in agreement we should do as Kacheong specifies =20 >> here.. i.e. >> add the >> >> SCTP_SENDER_DRY_EVENT >> ... >> SCTP_XXXX_EVENT >> >> all taking a sctp_assoc_value structure? >> >> I will agree to this Vlad, Michael, Others?? comments?? >> >> R >> >> >>> >>> >>> >>> >>> >>> >>> --=20 >>> >>> K. Poon. >>> kacheong.poon@sun.com >>> >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> >> > ----- Randall Stewart randall@lakerest.net From jmpolk@cisco.com Thu Feb 26 12:47:13 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E47428C22A for ; Thu, 26 Feb 2009 12:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q2uDBd5JM7v for ; Thu, 26 Feb 2009 12:47:12 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A0693A680E for ; Thu, 26 Feb 2009 12:47:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,273,1233532800"; d="scan'208";a="257696718" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2009 20:47:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1QKlYI3030299 for ; Thu, 26 Feb 2009 12:47:34 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1QKlYnI006943 for ; Thu, 26 Feb 2009 20:47:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 12:47:34 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.23.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 12:47:34 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Feb 2009 14:47:33 -0600 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Feb 2009 20:47:34.0179 (UTC) FILETIME=[735A8730:01C99853] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1458; t=1235681254; x=1236545254; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Fwd=3A=20Initial=20Version=20I-D=20Submission=2 0Deadline=20Extended=20to=20March=0A=20=204,=202009 |Sender:=20; bh=qioSQ5pGd2ZC3rnHvriqh1HeOU/ySyUaVzFpR/UxyAk=; b=SUN9QMPI5AY75Ikyd5wGJuuYP8amBEll78oVM1f3K9mQ9L8FTV8Sbvnz1n Zp12wf3NU71S9QBOknYbRao3LuBvIe1vm/ah+pV2P5Pa8GfFoMDRgza7kufk oaFl+HDVLo; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Tsvwg] Fwd: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:47:13 -0000 FYI to ID writers "Initial Version I-D Submission Deadline Extended to (Wednesday) March 4, 2009" this is a one time only deadline shift due to the RFC 5378 (pain in the @%$) which has just been approved. James TSVWG Chair >From: Alexa Morris >To: ietf-announce@ietf.org, ietf@ietf.org, wgchairs@ietf.org >Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 >Date: Thu, 26 Feb 2009 11:27:35 -0800 > >The IESG has extended the deadline for initial version (00) >submissions of Internet Drafts by 2 days (48 hours). The new deadline >is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) >and the extension is for IETF 74 only. The deadline has been extended >due to the copyright legend text alternative being recently finalized, >approved and implemented. > >Please note that the date for updated I-D versions has NOT been >extended, and is still March 9, 2009. > >Regards, >Alexa > >----------- >Alexa Morris / Executive Director / IETF >48377 Fremont Blvd., Suite 117, Fremont, CA 94538 >Phone: +1.510.492.4089 / Fax: +1.510.492.4001 >Email: amorris@amsl.com > >Managed by Association Management Solutions (AMS) >Forum Management, Meeting and Event Planning >www.amsl.com > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From kacheong.poon@sun.com Fri Feb 27 01:56:48 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7EB28C251 for ; Fri, 27 Feb 2009 01:56:48 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C3 hex): CC: ...i.franken.de>, "Michael T\303\274x"@core3.amsl.[...] X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0+-c0+01QSp for ; Fri, 27 Feb 2009 01:56:47 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id AA2603A6BAA for ; Fri, 27 Feb 2009 01:56:47 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1R9uukp003392; Fri, 27 Feb 2009 09:56:56 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1R9urlk136859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 01:56:54 -0800 (PST) Message-ID: <49A7B8E4.5010606@sun.com> Date: Fri, 27 Feb 2009 17:56:52 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Vlad Yasevich References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> In-Reply-To: <49A69E05.8080807@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: en , "Michael Tüx"@core3.amsl.com, tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 09:56:48 -0000 Vlad Yasevich wrote: > I am not sure I really like the inconsistency. What we are saying > here is that SCTP_EVENTS socket option can completely > overwrite a singular SCTP_EVENT option, which is supposed to > be more specific that the per socket SCTP_EVENTS. If we are going to have separate option per event, I guess the SCTP_EVENTS will be obsoleted. So I think they, SCTP_EVENTS and the per event options, won't be used at the same time in a new program. So from the programming point of view, I think this is OK. But I guess this is not your point. > I think that the new SCTP_EVENT socket option with association id of 0 > should have the same semantics as SCTP_EVENTS option (which does't take > association id). I think that creates a much clearer API. After all, > what really started this was the ability to set a per-association event > mask. > > So, I think that the new SCTP_EVENT with an association id of 0 should > modify all associations that currently belong to the given socket. Understood. But then we also need to be consistent with other options which use assoc_id 0 to mean future associations. I think it is more important to use assoc_id 0 consistently than to provide the same functionality as the current SCTP_EVENTS. But if possible, I also think that we need to explore the ability to set options for all associations under 1-N socket. One possible solution to make things consistent (assoc_id 0 means the same thing for every options) and provide the aforementioned ability is to make assoc_id 0 mean all and future associations. Is there another option? If not, do we want to make this change? -- K. Poon. kacheong.poon@sun.com From Michael.Tuexen@lurchi.franken.de Fri Feb 27 02:13:47 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729B328C2DB for ; Fri, 27 Feb 2009 02:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Level: * X-Spam-Status: No, score=1.69 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vto5ZTL3sw+s for ; Fri, 27 Feb 2009 02:13:46 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 1AFDC28C2B4 for ; Fri, 27 Feb 2009 02:13:45 -0800 (PST) Received: from [192.168.1.4] (p5481D48A.dip.t-dialin.net [84.129.212.138]) by mail-n.franken.de (Postfix) with ESMTP id F22941C0C0BC0; Fri, 27 Feb 2009 11:14:04 +0100 (CET) Message-Id: <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Kacheong Poon In-Reply-To: <49A7B8E4.5010606@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 11:14:03 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:13:47 -0000 On Feb 27, 2009, at 10:56 AM, Kacheong Poon wrote: > Vlad Yasevich wrote: > >> I am not sure I really like the inconsistency. What we are saying >> here is that SCTP_EVENTS socket option can completely >> overwrite a singular SCTP_EVENT option, which is supposed to >> be more specific that the per socket SCTP_EVENTS. > > > If we are going to have separate option per event, I guess the > SCTP_EVENTS will be obsoleted. So I think they, SCTP_EVENTS I hope so. We can even put text in the ID to make this clear. > > and the per event options, won't be used at the same time in a > new program. So from the programming point of view, I think > this is OK. But I guess this is not your point. > > >> I think that the new SCTP_EVENT socket option with association id >> of 0 >> should have the same semantics as SCTP_EVENTS option (which does't >> take >> association id). I think that creates a much clearer API. After >> all, >> what really started this was the ability to set a per-association >> event >> mask. >> So, I think that the new SCTP_EVENT with an association id of 0 >> should >> modify all associations that currently belong to the given socket. > > > Understood. But then we also need to be consistent with other > options which use assoc_id 0 to mean future associations. I > think it is more important to use assoc_id 0 consistently than > to provide the same functionality as the current SCTP_EVENTS. I agree completely. assoc_id 0 should mean future assocs. > > But if possible, I also think that we need to explore the > ability to set options for all associations under 1-N socket. > One possible solution to make things consistent (assoc_id 0 > means the same thing for every options) and provide the > aforementioned ability is to make assoc_id 0 mean all and future > associations. Is there another option? If not, do we want > to make this change? What about abstracting from 0? We could use something like #define SCTP_FUTURE_ASSOCIATIONS 0 #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff or whatever constants you want. The type is sctp_associd_t anyway. This even improves readability of the code... > > > > > -- > > K. Poon. > kacheong.poon@sun.com > > From kacheong.poon@sun.com Fri Feb 27 02:24:32 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E13C28C134 for ; Fri, 27 Feb 2009 02:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbEDUtp8A1y2 for ; Fri, 27 Feb 2009 02:24:32 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id DF97928C110 for ; Fri, 27 Feb 2009 02:24:31 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1RAOq0M004075; Fri, 27 Feb 2009 10:24:53 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1RAOoSX138590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 02:24:51 -0800 (PST) Message-ID: <49A7BF71.3000707@sun.com> Date: Fri, 27 Feb 2009 18:24:49 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> In-Reply-To: <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:24:32 -0000 Michael Tüxen wrote: > What about abstracting from 0? > We could use something like > #define SCTP_FUTURE_ASSOCIATIONS 0 > #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff SCTP_ALL_ASSOC? > or whatever constants you want. The type is sctp_associd_t > anyway. > This even improves readability of the code... I guess this is OK for most stacks, as I don't think there can be that many associations at the same time. Making it one less is fine. -- K. Poon. kacheong.poon@sun.com From randall@lakerest.net Fri Feb 27 02:26:18 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAA73A6ABB for ; Fri, 27 Feb 2009 02:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TteUQXvcTiSq for ; Fri, 27 Feb 2009 02:26:17 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 8099B3A682C for ; Fri, 27 Feb 2009 02:26:16 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RAQgaY050592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 05:26:43 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <2205DEAD-E753-4AE1-8062-9084A2202277@lakerest.net> From: Randy Stewart To: Kacheong Poon In-Reply-To: <49A7B8E4.5010606@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 05:26:32 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Michael Tuexen , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:26:18 -0000 On Feb 27, 2009, at 4:56 AM, Kacheong Poon wrote: > Vlad Yasevich wrote: > >> I am not sure I really like the inconsistency. What we are saying >> here is that SCTP_EVENTS socket option can completely >> overwrite a singular SCTP_EVENT option, which is supposed to >> be more specific that the per socket SCTP_EVENTS. > > > If we are going to have separate option per event, I guess the > SCTP_EVENTS will be obsoleted. So I think they, SCTP_EVENTS > and the per event options, won't be used at the same time in a > new program. So from the programming point of view, I think > this is OK. But I guess this is not your point. > > >> I think that the new SCTP_EVENT socket option with association id >> of 0 >> should have the same semantics as SCTP_EVENTS option (which does't >> take >> association id). I think that creates a much clearer API. After >> all, >> what really started this was the ability to set a per-association >> event >> mask. >> So, I think that the new SCTP_EVENT with an association id of 0 >> should >> modify all associations that currently belong to the given socket. > > > Understood. But then we also need to be consistent with other > options which use assoc_id 0 to mean future associations. I > think it is more important to use assoc_id 0 consistently than > to provide the same functionality as the current SCTP_EVENTS. > But if possible, I also think that we need to explore the > ability to set options for all associations under 1-N socket. > One possible solution to make things consistent (assoc_id 0 > means the same thing for every options) and provide the > aforementioned ability is to make assoc_id 0 mean all and future > associations. Is there another option? If not, do we want > to make this change? > > I am not sure your question here Kacheong, are you asking if there are other options that 0 means future assocs? The answer is yes, I can go dig them out if you want... In general we have always done 0 == future assoc where an assoc id was given. I also agree with you that the two things will be not often used together. However I can see the utility of doing SCTP_EVENTS option at the beginning of my program.. and then say do SCTP_SENDER_DRY_EVENTS on A association... then turn it back off. This saves me adding multiple socket calls if there are several I want to turn on all at once. I can also see the point Vlad is making.. there is no option IMO that this would apply to, but I can build a scenario for a situation that mixing the two could be confusing... Suppose I do what I would normally do SCTP_EVENTS(...) on all the options I want at the beginning of a program. Then later I specifically pick another specific event and turn it on. If I then later for some reason call SCTP_EVENTS() I could by accident turn off the option I just turned on. I think this is an unlikely scenario ... I think here is how we resolve it. 1) We specify that SCTP_EVENTS is obsoleted and discourage use. 2) We specify that if you are using SCTP_EVENTS you should only do so BEFORE associations are are established (at the beginning of your program after the socket call). 3) We specify that if you do use SCTP_EVENTS later on then the behavior is unspecified as to if it effects future assoc OR also ones already in progress. 4) We recommend using the specific EVENTS (described in a separate section) going forward. Now as for me. Here is how I will implement it since it makes sense to me this way. A) XXX_EVENT will turn on/off per association or if == 0 future associations. B) SCTP_EVENTS will work, but if done someplace else in the middle of the program it will only effect future associations. I feel this is much more consistent in how the API works even if its a slight tweak to SCTP_EVENTS... R > > -- > > K. Poon. > kacheong.poon@sun.com > ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Fri Feb 27 02:28:36 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA033A6ABE for ; Fri, 27 Feb 2009 02:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UISuqKNR7Ozx for ; Fri, 27 Feb 2009 02:28:36 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 734733A6ABB for ; Fri, 27 Feb 2009 02:28:35 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RAT3Sl050679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 05:29:03 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: From: Randy Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 05:28:53 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:28:37 -0000 On Feb 27, 2009, at 5:14 AM, Michael T=FCxen wrote: > On Feb 27, 2009, at 10:56 AM, Kacheong Poon wrote: > >> Vlad Yasevich wrote: >> >>> I am not sure I really like the inconsistency. What we are saying >>> here is that SCTP_EVENTS socket option can completely >>> overwrite a singular SCTP_EVENT option, which is supposed to >>> be more specific that the per socket SCTP_EVENTS. >> >> >> If we are going to have separate option per event, I guess the >> SCTP_EVENTS will be obsoleted. So I think they, SCTP_EVENTS > I hope so. We can even put text in the ID to make this clear. >> >> and the per event options, won't be used at the same time in a >> new program. So from the programming point of view, I think >> this is OK. But I guess this is not your point. >> >> >>> I think that the new SCTP_EVENT socket option with association id =20= >>> of 0 >>> should have the same semantics as SCTP_EVENTS option (which does't =20= >>> take >>> association id). I think that creates a much clearer API. After =20= >>> all, >>> what really started this was the ability to set a per-association =20= >>> event >>> mask. >>> So, I think that the new SCTP_EVENT with an association id of 0 =20 >>> should >>> modify all associations that currently belong to the given socket. >> >> >> Understood. But then we also need to be consistent with other >> options which use assoc_id 0 to mean future associations. I >> think it is more important to use assoc_id 0 consistently than >> to provide the same functionality as the current SCTP_EVENTS. > I agree completely. assoc_id 0 should mean future assocs. >> >> But if possible, I also think that we need to explore the >> ability to set options for all associations under 1-N socket. >> One possible solution to make things consistent (assoc_id 0 >> means the same thing for every options) and provide the >> aforementioned ability is to make assoc_id 0 mean all and future >> associations. Is there another option? If not, do we want >> to make this change? > What about abstracting from 0? > We could use something like > #define SCTP_FUTURE_ASSOCIATIONS 0 > #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff > or whatever constants you want. The type is sctp_associd_t > anyway. > This even improves readability of the code... I guess I would be fine with that except for one issue I have. 0xffffffff can be an association id (at least in BSD). Yes I know its unlikely.. but this means I need to take yet another exception and remove it when generating asoc-id's.. Hmm come to think of this it does not matter anymore.. We changed all that so that we no longer correlate the assoc-id and the vtag.. So yeah, this works for me.. Lets do it that way.. R > >> >> >> >> >> --=20 >> >> K. Poon. >> kacheong.poon@sun.com >> >> > ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Fri Feb 27 02:31:34 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB233A6AC0 for ; Fri, 27 Feb 2009 02:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lalJ0CaRrG1 for ; Fri, 27 Feb 2009 02:31:34 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 77F2E3A6ABB for ; Fri, 27 Feb 2009 02:31:33 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RAW1VB050823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 05:32:01 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <60166B3A-3C6A-4123-A303-449D190CA06A@lakerest.net> From: Randy Stewart To: Kacheong Poon In-Reply-To: <49A7BF71.3000707@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 05:31:52 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> <49A7BF71.3000707@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:31:34 -0000 I am happy with this.. so we now only allow 4billion -2 I think that is safely big enough... but if we ever really run in to a situation where it is not.. there is an easy way here. Just like time_t is a type on its own... what BSD did is in 32 bit machines time_t =3D=3D 32 bits and on 64 bit machines time_t =3D=3D 64 bits. We could follow that pattern when folks want more than 4billion-2 assoc on a socket.. i.e. you need to be on a 64 bit machine so assoc_id's just move to 64 bit values... (I won't hold my breath for that to happen either :-D) R On Feb 27, 2009, at 5:24 AM, Kacheong Poon wrote: > Michael T=FCxen wrote: > >> What about abstracting from 0? >> We could use something like >> #define SCTP_FUTURE_ASSOCIATIONS 0 >> #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff > > > SCTP_ALL_ASSOC? > > >> or whatever constants you want. The type is sctp_associd_t >> anyway. >> This even improves readability of the code... > > > I guess this is OK for most stacks, as I don't think there > can be that many associations at the same time. Making it > one less is fine. > > > --=20 > > K. Poon. > kacheong.poon@sun.com > ----- Randall Stewart randall@lakerest.net From Michael.Tuexen@lurchi.franken.de Fri Feb 27 02:38:56 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6D13A682C for ; Fri, 27 Feb 2009 02:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDAuFV6AxRLO for ; Fri, 27 Feb 2009 02:38:55 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4A73B3A6803 for ; Fri, 27 Feb 2009 02:38:55 -0800 (PST) Received: from [192.168.1.4] (p5481D48A.dip.t-dialin.net [84.129.212.138]) by mail-n.franken.de (Postfix) with ESMTP id 5644E1C0C0BC0; Fri, 27 Feb 2009 11:39:14 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Kacheong Poon In-Reply-To: <49A7BF71.3000707@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 11:39:10 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> <49A7BF71.3000707@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:38:56 -0000 On Feb 27, 2009, at 11:24 AM, Kacheong Poon wrote: > Michael T=FCxen wrote: > >> What about abstracting from 0? >> We could use something like >> #define SCTP_FUTURE_ASSOCIATIONS 0 >> #define SCTP_FUTURE_AND_CURRENT_ASSOCIATIONS 0xffffffff > > > SCTP_ALL_ASSOC? I do not care that much about the name... So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC? > > >> or whatever constants you want. The type is sctp_associd_t >> anyway. >> This even improves readability of the code... > > > I guess this is OK for most stacks, as I don't think there > can be that many associations at the same time. Making it > one less is fine. > > > --=20 > > K. Poon. > kacheong.poon@sun.com > > From kacheong.poon@sun.com Fri Feb 27 02:39:16 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302C228C117 for ; Fri, 27 Feb 2009 02:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc3wSI7usPi4 for ; Fri, 27 Feb 2009 02:39:15 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 6D2BA28B56A for ; Fri, 27 Feb 2009 02:39:15 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1RAdbZ7027938; Fri, 27 Feb 2009 10:39:37 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1RAdY53139628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 02:39:36 -0800 (PST) Message-ID: <49A7C2E6.2080305@sun.com> Date: Fri, 27 Feb 2009 18:39:34 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Randy Stewart References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <2205DEAD-E753-4AE1-8062-9084A2202277@lakerest.net> In-Reply-To: <2205DEAD-E753-4AE1-8062-9084A2202277@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vlad Yasevich , Michael Tuexen , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:39:16 -0000 Randy Stewart wrote: > 1) We specify that SCTP_EVENTS is obsoleted and discourage use. > 2) We specify that if you are using SCTP_EVENTS you should only > do so BEFORE associations are are established (at the beginning > of your program after the socket call). > 3) We specify that if you do use SCTP_EVENTS later on then the behavior > is unspecified as to if it effects future assoc OR also ones already > in progress. I'd like to keep the existing semantics of SCTP_EVENTS, which means all and future so existing apps will have no problem. And there should be no restriction on when it can be called, as specified in the current draft. > 4) We recommend using the specific EVENTS (described in a separate > section) going > forward. -- K. Poon. kacheong.poon@sun.com From Michael.Tuexen@lurchi.franken.de Fri Feb 27 02:41:31 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF543A682C for ; Fri, 27 Feb 2009 02:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.806 X-Spam-Level: * X-Spam-Status: No, score=1.806 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOUFz0GZ1TpN for ; Fri, 27 Feb 2009 02:41:31 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id C6A733A6803 for ; Fri, 27 Feb 2009 02:41:30 -0800 (PST) Received: from [192.168.1.4] (p5481D48A.dip.t-dialin.net [84.129.212.138]) by mail-n.franken.de (Postfix) with ESMTP id 0EDD61C0C0BC0; Fri, 27 Feb 2009 11:41:50 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Kacheong Poon In-Reply-To: <49A7C2E6.2080305@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 11:41:49 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <2205DEAD-E753-4AE1-8062-9084A2202277@lakerest.net> <49A7C2E6.2080305@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:41:31 -0000 On Feb 27, 2009, at 11:39 AM, Kacheong Poon wrote: > Randy Stewart wrote: > >> 1) We specify that SCTP_EVENTS is obsoleted and discourage use. >> 2) We specify that if you are using SCTP_EVENTS you should only >> do so BEFORE associations are are established (at the beginning >> of your program after the socket call). >> 3) We specify that if you do use SCTP_EVENTS later on then the >> behavior >> is unspecified as to if it effects future assoc OR also ones >> already >> in progress. > > > I'd like to keep the existing semantics of SCTP_EVENTS, which > means all and future so existing apps will have no problem. > And there should be no restriction on when it can be called, > as specified in the current draft. I agree. Maybe we should add a note that this socket options will be obsoleted in the future? > > > >> 4) We recommend using the specific EVENTS (described in a separate >> section) going >> forward. > > > > > -- > > K. Poon. > kacheong.poon@sun.com > > From kacheong.poon@sun.com Fri Feb 27 02:45:23 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D153A6C16 for ; Fri, 27 Feb 2009 02:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFoG7pQQJKaz for ; Fri, 27 Feb 2009 02:45:23 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 0364F3A6C09 for ; Fri, 27 Feb 2009 02:45:23 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1RAjg68015485; Fri, 27 Feb 2009 10:45:42 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1RAjdQW140400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 02:45:40 -0800 (PST) Message-ID: <49A7C452.6080102@sun.com> Date: Fri, 27 Feb 2009 18:45:38 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> <49A7BF71.3000707@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:45:23 -0000 Michael Tüxen wrote: > I do not care that much about the name... > So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC? They are fine. -- K. Poon. kacheong.poon@sun.com From avkonst@gmail.com Fri Feb 27 03:44:37 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B472728C251 for ; Fri, 27 Feb 2009 03:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lOXGBM93e4P for ; Fri, 27 Feb 2009 03:44:37 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 900E228C163 for ; Fri, 27 Feb 2009 03:44:36 -0800 (PST) Received: by ewy25 with SMTP id 25so1147234ewy.37 for ; Fri, 27 Feb 2009 03:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=mAQw+X8tKFsygJq1FQeCOeNGrFawGK5J3eiBZdiubuQ=; b=bz9xFwN0SKnMOZPGM2zD6m7bgTBBOfl7okmpJubedjPNeBN5oUA8YTit/kW4LUT3fp E3ql0TZb7WUdwjL21+jroZhORV3ZCWq3MuI68lODRRq5o/YFwZTs4aqprXOv8Pg7dOEK G8EudKt6lkXyGPF3VaRfThy5IM8vkuahO6cEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=wuVI+dcxyiCt7ayhQeYWHiw1jv+5w/zD4AlZLEXYPICVBxPvLRSDk9LWlQTydDwa46 pjVFgPzPQQEFrxIXz96GcHcBaGOuHS9UA4wKVZ4IKpacBnFeE+QHwdjDxTqOsPDRLaMY wZmMLaugV3Sxzl+IFWdb7CsFkEg7nIcca9B4E= MIME-Version: 1.0 Received: by 10.210.76.4 with SMTP id y4mr597767eba.12.1235735098035; Fri, 27 Feb 2009 03:44:58 -0800 (PST) Date: Fri, 27 Feb 2009 14:44:58 +0300 Message-ID: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> From: Andrey Konstantinov To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:44:37 -0000 Hi, Could you help me to interpret the rule from RFC4960 correctly? There is a rule: A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender. Let me consider the example: Initial ARWND = 400; Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP Local SCTP has inflight 100 bytes after SACK processing: 200 (RWND) - 100 (inflight) = 100 bytes can be sent Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid transmission, 100 - 90 = 10 bytes left Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 bytes left, not send more Is the last transmission valid? Can local SCTP transmit it? OR it is not alllowed? Thanks in advance, Andrey Konstantinov From randall@lakerest.net Fri Feb 27 04:20:12 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92723A680F for ; Fri, 27 Feb 2009 04:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcbeTHXYaJln for ; Fri, 27 Feb 2009 04:20:10 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 0AD443A6358 for ; Fri, 27 Feb 2009 04:20:09 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RCKbMM054874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 07:20:37 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: From: Randy Stewart To: Andrey Konstantinov In-Reply-To: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 07:20:27 -0500 References: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:20:12 -0000 On Feb 27, 2009, at 6:44 AM, Andrey Konstantinov wrote: > Hi, > > Could you help me to interpret the rule from RFC4960 correctly? > > There is a rule: > A) At any given time, the data sender MUST NOT transmit new data to > any destination transport address if its peer's rwnd indicates > that the peer has no buffer space (i.e., rwnd is 0; see Section > 6.2.1). However, regardless of the value of rwnd (including if > it > is 0), the data sender can always have one DATA chunk in flight > to > the receiver if allowed by cwnd (see rule B, below). This rule > allows the sender to probe for a change in rwnd that the sender > missed due to the SACK's having been lost in transit from the > data > receiver to the data sender. > > Let me consider the example: > > Initial ARWND = 400; > Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP > Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP > Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP > Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP > Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP > Local SCTP has inflight 100 bytes after SACK processing: 200 (RWND) - > 100 (inflight) = 100 bytes can be sent > Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid > transmission, 100 - 90 = 10 bytes left > Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 bytes > left, not send more > > Is the last transmission valid? Can local SCTP transmit it? OR it is > not alllowed? Hmm.. interesting point. In the case of TCP, TCP would just send 10 bytes. In the case of SCTP this is not possible (although TCP would most likely NOT send it anyway due to SWS avoidance). I think one should take the more conservative approach here and NOT send it. That send would put you over the receivers rwnd so its likely the receiver will discard it. You have data in flight, so why send it. As long as there is a TSN in flight then you WILL get an update eventually... i.e. <-----SACK(TSN5, rwnd=XXX) Should be coming shortly. You must also remember, most implementations also implement a silly window syndrome avoidance.. in the case of BSD we do this .. and if you do that this situation would not arise.. i.e. you would not even think about sending 10 bytes. Can't remember the RFC that talks about SWS but it is something you should look at too. Basically you subtract a bit extra off of the rwnd (its a bit more than that and I would suggest you look through the RFC's and find the details they escape me at the moment :D )... R > > > Thanks in advance, > Andrey Konstantinov > ----- Randall Stewart randall@lakerest.net From avkonst@gmail.com Fri Feb 27 05:37:14 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E623F3A68F7 for ; Fri, 27 Feb 2009 05:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3XyK2wyEq7R for ; Fri, 27 Feb 2009 05:37:14 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 965093A67D7 for ; Fri, 27 Feb 2009 05:37:13 -0800 (PST) Received: by ewy25 with SMTP id 25so1178170ewy.37 for ; Fri, 27 Feb 2009 05:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=lOuKuahk4sC7EuVLkYSpuYn/yD/3yU5zI4Xvxxg0smY=; b=kFEjXxEHl5xLMLZ0q/9usLlxgoY1psxYYKt8cmHSa3r2No0J+UyayjQTbvzklMB0LL ar3h2qAzmxgYOS91yuhtPmm37xxkbhJAXSQ0tg/iB/Wg8yKNqYy1c/3SK/RVTSTkv8ei wme8CFhmW4QsL9VdOfpgiQcO5xVld7WQFmygk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=CQyNSbahZpfjL2KDBQR622XMOTxJZirgBd1czSY8mby6FlmDxuSjfI+0vNLwG70eBS 5KLNNyr38sULsEHe1hqIYoVrHKYU16qmkww6JKn2hbnkvXy2y+oYoi2HZHAtu4v0UFDG dZjYBq+rXVY6Wg48nZWsKboBGUhg+RAEVbl+8= MIME-Version: 1.0 Received: by 10.210.105.20 with SMTP id d20mr1967706ebc.99.1235741855284; Fri, 27 Feb 2009 05:37:35 -0800 (PST) In-Reply-To: References: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> Date: Fri, 27 Feb 2009 16:37:35 +0300 Message-ID: <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> From: Andrey Konstantinov To: Randy Stewart , tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:37:15 -0000 Hi, Thanks for your answer. Our SCTP implementation supports SWS. It adjusts RWND when reports it in SACK: it reports zero OR nonzero value which is much more than PMTU. Also, it adjusts RWND received from remote side in SACK: it zeros received ARWND if it is too small OR it keeps unchanged if it is much more than PMTU The question is about sending DATA chunk when ARWND is almost consumed and there is small bytes left. Of course, 10 bytes will not be sent if the next outgoing chunk is 90 bytes (as it is in my example), i.e. new chunk (10 bytes) will not be fragmented from already created chunk (90 bytes)... The question is how to consider RWND threshold: is it allowed to transmit more bytes than RWND value which is declared by remote side in last received SACK? For example (cwnd and SWS are not considered here): 1. Reported RWND is 200 bytes 2. There is 100 bytes inflight after SACK procesing 3. SCTP can send 90 bytes because RWND threshold has not been reached OR exceeded: [90 (new data) < 200 (RWND) - 100 (inflight)]. But can SCTP send TWO data chunks (both with 90 bytes of ULP data) in these conditions? 90 < 100 - the first chunk is sent 180 > 100 - the second chunk is sent, stop sending due to RWND exceeded Thanks in advance, Andrey Konstantinov 2009/2/27 Randy Stewart : > > On Feb 27, 2009, at 6:44 AM, Andrey Konstantinov wrote: > >> Hi, >> >> Could you help me to interpret the rule from RFC4960 correctly? >> >> There is a rule: >> =A0A) At any given time, the data sender MUST NOT transmit new data to >> =A0 =A0 any destination transport address if its peer's rwnd indicates >> =A0 =A0 that the peer has no buffer space (i.e., rwnd is 0; see Section >> =A0 =A0 6.2.1). =A0However, regardless of the value of rwnd (including i= f it >> =A0 =A0 is 0), the data sender can always have one DATA chunk in flight = to >> =A0 =A0 the receiver if allowed by cwnd (see rule B, below). =A0This rul= e >> =A0 =A0 allows the sender to probe for a change in rwnd that the sender >> =A0 =A0 missed due to the SACK's having been lost in transit from the da= ta >> =A0 =A0 receiver to the data sender. >> >> Let me consider the example: >> >> Initial ARWND =3D 400; >> Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP >> Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP >> Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP >> Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP >> Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP >> Local SCTP has inflight 100 bytes after SACK processing: 200 (RWND) - >> 100 (inflight) =3D 100 bytes can be sent >> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid >> transmission, 100 - 90 =3D 10 bytes left >> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 bytes >> left, not send more >> >> Is the last transmission valid? Can local SCTP transmit it? OR it is >> not alllowed? > > Hmm.. interesting point. In the case of TCP, TCP would just > send 10 bytes. In the case of SCTP this is not possible (although > TCP would most likely NOT send it anyway due to SWS avoidance). > > I think one should take the more conservative approach here > and NOT send it. That send would put you over the receivers > rwnd so its likely the receiver will discard it. You have > data in flight, so why send it. > > As long as there is a TSN in flight then you WILL get an > update eventually... i.e. > > <-----SACK(TSN5, rwnd=3DXXX) > > Should be coming shortly. > > > You must also remember, most implementations also implement a silly windo= w > syndrome avoidance.. in the case of BSD we do this .. and if you do that > this situation would not arise.. i.e. you would not even think about > sending 10 bytes. Can't remember the RFC that talks about SWS but it > is something you should look at too. Basically you subtract a bit > extra off of the rwnd (its a bit more than that and I would suggest > you look through the RFC's and find the details they escape me > at the moment :D )... > > R > > >> >> >> Thanks in advance, >> Andrey Konstantinov >> > > ----- > Randall Stewart > randall@lakerest.net > > > > > From randall@lakerest.net Fri Feb 27 05:43:13 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC41F3A694E for ; Fri, 27 Feb 2009 05:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQK0vSoc9Wbk for ; Fri, 27 Feb 2009 05:43:13 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 4D8043A67A4 for ; Fri, 27 Feb 2009 05:43:12 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RDhehN058109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 08:43:40 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <9B627304-699E-4C6C-B018-BF516EED169E@lakerest.net> From: Randy Stewart To: Andrey Konstantinov In-Reply-To: <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 08:43:30 -0500 References: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:43:13 -0000 I think the strict answer is NO you cannot transmit in that situation. Again, because MOST LIKELY the peer will discard your packet. R On Feb 27, 2009, at 8:37 AM, Andrey Konstantinov wrote: > Hi, > > Thanks for your answer. > > Our SCTP implementation supports SWS. > It adjusts RWND when reports it in SACK: it reports zero OR nonzero > value which is much more than PMTU. > Also, it adjusts RWND received from remote side in SACK: it zeros > received ARWND if it is too small OR it keeps unchanged if it is much > more than PMTU > > The question is about sending DATA chunk when ARWND is almost consumed > and there is small bytes left. > Of course, 10 bytes will not be sent if the next outgoing chunk is > 90 bytes (as it is in my example), i.e. new chunk (10 bytes) will not > be fragmented from already created chunk (90 bytes)... > The question is how to consider RWND threshold: is it allowed to > transmit more bytes than RWND value which is declared by remote side > in last received SACK? > > For example (cwnd and SWS are not considered here): > 1. Reported RWND is 200 bytes > 2. There is 100 bytes inflight after SACK procesing > 3. SCTP can send 90 bytes because RWND threshold has not been reached > OR exceeded: [90 (new data) < 200 (RWND) - 100 (inflight)]. But can > SCTP send TWO data chunks (both with 90 bytes of ULP data) in these > conditions? > 90 < 100 - the first chunk is sent > 180 > 100 - the second chunk is sent, stop sending due to RWND > exceeded > > Thanks in advance, > Andrey Konstantinov > > > 2009/2/27 Randy Stewart : >> >> On Feb 27, 2009, at 6:44 AM, Andrey Konstantinov wrote: >> >>> Hi, >>> >>> Could you help me to interpret the rule from RFC4960 correctly? >>> >>> There is a rule: >>> A) At any given time, the data sender MUST NOT transmit new data to >>> any destination transport address if its peer's rwnd indicates >>> that the peer has no buffer space (i.e., rwnd is 0; see Section >>> 6.2.1). However, regardless of the value of rwnd (including >>> if it >>> is 0), the data sender can always have one DATA chunk in >>> flight to >>> the receiver if allowed by cwnd (see rule B, below). This rule >>> allows the sender to probe for a change in rwnd that the sender >>> missed due to the SACK's having been lost in transit from the >>> data >>> receiver to the data sender. >>> >>> Let me consider the example: >>> >>> Initial ARWND = 400; >>> Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP >>> Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP >>> Local SCTP has inflight 100 bytes after SACK processing: 200 >>> (RWND) - >>> 100 (inflight) = 100 bytes can be sent >>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid >>> transmission, 100 - 90 = 10 bytes left >>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 >>> bytes >>> left, not send more >>> >>> Is the last transmission valid? Can local SCTP transmit it? OR it is >>> not alllowed? >> >> Hmm.. interesting point. In the case of TCP, TCP would just >> send 10 bytes. In the case of SCTP this is not possible (although >> TCP would most likely NOT send it anyway due to SWS avoidance). >> >> I think one should take the more conservative approach here >> and NOT send it. That send would put you over the receivers >> rwnd so its likely the receiver will discard it. You have >> data in flight, so why send it. >> >> As long as there is a TSN in flight then you WILL get an >> update eventually... i.e. >> >> <-----SACK(TSN5, rwnd=XXX) >> >> Should be coming shortly. >> >> >> You must also remember, most implementations also implement a silly >> window >> syndrome avoidance.. in the case of BSD we do this .. and if you do >> that >> this situation would not arise.. i.e. you would not even think about >> sending 10 bytes. Can't remember the RFC that talks about SWS but it >> is something you should look at too. Basically you subtract a bit >> extra off of the rwnd (its a bit more than that and I would suggest >> you look through the RFC's and find the details they escape me >> at the moment :D )... >> >> R >> >> >>> >>> >>> Thanks in advance, >>> Andrey Konstantinov >>> >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> >> > ----- Randall Stewart randall@lakerest.net From avkonst@gmail.com Fri Feb 27 05:43:14 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827AF3A67A4 for ; Fri, 27 Feb 2009 05:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps8EVQVjnN23 for ; Fri, 27 Feb 2009 05:43:13 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 8094B3A6907 for ; Fri, 27 Feb 2009 05:43:12 -0800 (PST) Received: by ewy25 with SMTP id 25so1180771ewy.37 for ; Fri, 27 Feb 2009 05:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7Z+DWp1Gj7QOxlml/FzAeicNY5GyTgj5jV5ateTp8Qs=; b=m7huH+MFpbOW0MK9W+Gm51LbP7vpyVJopH2q77p1iVmrpmjrWVl8k6/twOT+3YDTYN bVI5dLrojCH00aYMVNi1mUfsCbIp2DbID2P6RLmq1zqO1ayHyQYUUIkSrc3fab6fE03l oHYr5/XMqGXZsJts7fMCN6OSQM0W21zz5WpT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=A1N0PzH9jnXauBXB87aww0W9LS7EM6wHzqOMWCvJZiwWJ9S8ixia8z32652lofUKdj Bj6PU4R91cjFDPKFd6lwqPmY/dO0rarO+hUhj0KB1WUv3fnWLlYsPEPjA0T6h+7Bx+HE H2vIJjujRekzxp1x+UPomQUUEezk4CKWY0vrw= MIME-Version: 1.0 Received: by 10.210.136.10 with SMTP id j10mr456734ebd.59.1235742214330; Fri, 27 Feb 2009 05:43:34 -0800 (PST) In-Reply-To: <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> References: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> Date: Fri, 27 Feb 2009 16:43:34 +0300 Message-ID: <296afac70902270543l64d1fc66l3d4817643d633dea@mail.gmail.com> From: Andrey Konstantinov To: Randy Stewart , tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:43:14 -0000 Just a comment. According to your answer it is RECOMMENDED not to send the second chunk. BUT is it prohibited (MUST NOT) or recommended (SHOULD NOT) by RFC4960? 2009/2/27 Andrey Konstantinov : > Hi, > > Thanks for your answer. > > Our SCTP implementation supports SWS. > =A0 It adjusts RWND when reports it in SACK: it reports zero OR nonzero > value which is much more than PMTU. > =A0 Also, it adjusts RWND received from remote side in SACK: it zeros > received ARWND if it is too small OR it keeps unchanged if it is much > more than PMTU > > The question is about sending DATA chunk when ARWND is almost consumed > and there is small bytes left. > =A0Of course, 10 bytes will not be sent if the next outgoing chunk is > 90 bytes (as it is in my example), i.e. new chunk (10 bytes) will not > be fragmented from already created chunk (90 bytes)... > The question is how to consider RWND threshold: is it allowed to > transmit more bytes than RWND value which is declared by remote side > in last received SACK? > > For example (cwnd and SWS are not considered here): > 1. Reported RWND is 200 bytes > 2. There is 100 bytes inflight after SACK procesing > 3. SCTP can send 90 bytes because RWND threshold has not been reached > OR exceeded: [90 (new data) < 200 (RWND) - 100 (inflight)]. But can > SCTP send TWO data chunks (both with 90 bytes of ULP data) in these > conditions? > 90 < 100 =A0- the first chunk is sent > 180 > 100 - the second chunk is sent, stop sending due to RWND exceeded > > Thanks in advance, > Andrey Konstantinov > > > 2009/2/27 Randy Stewart : >> >> On Feb 27, 2009, at 6:44 AM, Andrey Konstantinov wrote: >> >>> Hi, >>> >>> Could you help me to interpret the rule from RFC4960 correctly? >>> >>> There is a rule: >>> =A0A) At any given time, the data sender MUST NOT transmit new data to >>> =A0 =A0 any destination transport address if its peer's rwnd indicates >>> =A0 =A0 that the peer has no buffer space (i.e., rwnd is 0; see Section >>> =A0 =A0 6.2.1). =A0However, regardless of the value of rwnd (including = if it >>> =A0 =A0 is 0), the data sender can always have one DATA chunk in flight= to >>> =A0 =A0 the receiver if allowed by cwnd (see rule B, below). =A0This ru= le >>> =A0 =A0 allows the sender to probe for a change in rwnd that the sender >>> =A0 =A0 missed due to the SACK's having been lost in transit from the d= ata >>> =A0 =A0 receiver to the data sender. >>> >>> Let me consider the example: >>> >>> Initial ARWND =3D 400; >>> Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP >>> Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP >>> Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP >>> Local SCTP has inflight 100 bytes after SACK processing: 200 (RWND) - >>> 100 (inflight) =3D 100 bytes can be sent >>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid >>> transmission, 100 - 90 =3D 10 bytes left >>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 bytes >>> left, not send more >>> >>> Is the last transmission valid? Can local SCTP transmit it? OR it is >>> not alllowed? >> >> Hmm.. interesting point. In the case of TCP, TCP would just >> send 10 bytes. In the case of SCTP this is not possible (although >> TCP would most likely NOT send it anyway due to SWS avoidance). >> >> I think one should take the more conservative approach here >> and NOT send it. That send would put you over the receivers >> rwnd so its likely the receiver will discard it. You have >> data in flight, so why send it. >> >> As long as there is a TSN in flight then you WILL get an >> update eventually... i.e. >> >> <-----SACK(TSN5, rwnd=3DXXX) >> >> Should be coming shortly. >> >> >> You must also remember, most implementations also implement a silly wind= ow >> syndrome avoidance.. in the case of BSD we do this .. and if you do that >> this situation would not arise.. i.e. you would not even think about >> sending 10 bytes. Can't remember the RFC that talks about SWS but it >> is something you should look at too. Basically you subtract a bit >> extra off of the rwnd (its a bit more than that and I would suggest >> you look through the RFC's and find the details they escape me >> at the moment :D )... >> >> R >> >> >>> >>> >>> Thanks in advance, >>> Andrey Konstantinov >>> >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> >> > From randall@lakerest.net Fri Feb 27 06:09:12 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68DEE3A6BD9 for ; Fri, 27 Feb 2009 06:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEPUC2-Ktzcq for ; Fri, 27 Feb 2009 06:09:11 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id B19243A69FF for ; Fri, 27 Feb 2009 06:09:10 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1RE9cnX059470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Feb 2009 09:09:39 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <66C107C8-1AE4-430D-B1A0-2A9A8484808A@lakerest.net> From: Randy Stewart To: Andrey Konstantinov In-Reply-To: <296afac70902270543l64d1fc66l3d4817643d633dea@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 09:09:29 -0500 References: <296afac70902270344p1b2ba5n522e5848cfde868@mail.gmail.com> <296afac70902270537i454d3606rbbad3e71a10a09c2@mail.gmail.com> <296afac70902270543l64d1fc66l3d4817643d633dea@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] RFC4960 chapter 6.2.1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:09:12 -0000 Hmm.. well if you want to be legalistic. It does say: A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicate that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). Now the qualification in the second part (one chunk in flight) is true.. i.e in your example TSN 4 is still in flight. If you send the next 90 bytes TSN 5, then you WILL have MORE than the peers rwnd in flight. This violates the MUST NOT. So I would say its a violation of the spec.. R On Feb 27, 2009, at 8:43 AM, Andrey Konstantinov wrote: > Just a comment. > According to your answer it is RECOMMENDED not to send the second > chunk. > BUT is it prohibited (MUST NOT) or recommended (SHOULD NOT) by > RFC4960? > > 2009/2/27 Andrey Konstantinov : >> Hi, >> >> Thanks for your answer. >> >> Our SCTP implementation supports SWS. >> It adjusts RWND when reports it in SACK: it reports zero OR nonzero >> value which is much more than PMTU. >> Also, it adjusts RWND received from remote side in SACK: it zeros >> received ARWND if it is too small OR it keeps unchanged if it is much >> more than PMTU >> >> The question is about sending DATA chunk when ARWND is almost >> consumed >> and there is small bytes left. >> Of course, 10 bytes will not be sent if the next outgoing chunk is >> 90 bytes (as it is in my example), i.e. new chunk (10 bytes) will not >> be fragmented from already created chunk (90 bytes)... >> The question is how to consider RWND threshold: is it allowed to >> transmit more bytes than RWND value which is declared by remote side >> in last received SACK? >> >> For example (cwnd and SWS are not considered here): >> 1. Reported RWND is 200 bytes >> 2. There is 100 bytes inflight after SACK procesing >> 3. SCTP can send 90 bytes because RWND threshold has not been reached >> OR exceeded: [90 (new data) < 200 (RWND) - 100 (inflight)]. But can >> SCTP send TWO data chunks (both with 90 bytes of ULP data) in these >> conditions? >> 90 < 100 - the first chunk is sent >> 180 > 100 - the second chunk is sent, stop sending due to RWND >> exceeded >> >> Thanks in advance, >> Andrey Konstantinov >> >> >> 2009/2/27 Randy Stewart : >>> >>> On Feb 27, 2009, at 6:44 AM, Andrey Konstantinov wrote: >>> >>>> Hi, >>>> >>>> Could you help me to interpret the rule from RFC4960 correctly? >>>> >>>> There is a rule: >>>> A) At any given time, the data sender MUST NOT transmit new data >>>> to >>>> any destination transport address if its peer's rwnd indicates >>>> that the peer has no buffer space (i.e., rwnd is 0; see Section >>>> 6.2.1). However, regardless of the value of rwnd (including >>>> if it >>>> is 0), the data sender can always have one DATA chunk in >>>> flight to >>>> the receiver if allowed by cwnd (see rule B, below). This rule >>>> allows the sender to probe for a change in rwnd that the sender >>>> missed due to the SACK's having been lost in transit from the >>>> data >>>> receiver to the data sender. >>>> >>>> Let me consider the example: >>>> >>>> Initial ARWND = 400; >>>> Local SCTP --> DATA(100 bytes, TSN1) --> Remote SCTP >>>> Local SCTP --> DATA(100 bytes, TSN2) --> Remote SCTP >>>> Local SCTP --> DATA(100 bytes, TSN3) --> Remote SCTP >>>> Local SCTP --> DATA(100 bytes, TSN4) --> Remote SCTP >>>> Local SCTP <-- SACK(Acknowledges TSN3, RWND is 200) <-- Remote SCTP >>>> Local SCTP has inflight 100 bytes after SACK processing: 200 >>>> (RWND) - >>>> 100 (inflight) = 100 bytes can be sent >>>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ valid >>>> transmission, 100 - 90 = 10 bytes left >>>> Local SCTP --> DATA(90 bytes, TSN5) --> Remote SCTP ------ ?, 0 >>>> bytes >>>> left, not send more >>>> >>>> Is the last transmission valid? Can local SCTP transmit it? OR it >>>> is >>>> not alllowed? >>> >>> Hmm.. interesting point. In the case of TCP, TCP would just >>> send 10 bytes. In the case of SCTP this is not possible (although >>> TCP would most likely NOT send it anyway due to SWS avoidance). >>> >>> I think one should take the more conservative approach here >>> and NOT send it. That send would put you over the receivers >>> rwnd so its likely the receiver will discard it. You have >>> data in flight, so why send it. >>> >>> As long as there is a TSN in flight then you WILL get an >>> update eventually... i.e. >>> >>> <-----SACK(TSN5, rwnd=XXX) >>> >>> Should be coming shortly. >>> >>> >>> You must also remember, most implementations also implement a >>> silly window >>> syndrome avoidance.. in the case of BSD we do this .. and if you >>> do that >>> this situation would not arise.. i.e. you would not even think about >>> sending 10 bytes. Can't remember the RFC that talks about SWS but it >>> is something you should look at too. Basically you subtract a bit >>> extra off of the rwnd (its a bit more than that and I would suggest >>> you look through the RFC's and find the details they escape me >>> at the moment :D )... >>> >>> R >>> >>> >>>> >>>> >>>> Thanks in advance, >>>> Andrey Konstantinov >>>> >>> >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>> >>> >>> >>> >>> >> > ----- Randall Stewart randall@lakerest.net From magnus.westerlund@ericsson.com Fri Feb 27 09:48:10 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D5228C33D for ; Fri, 27 Feb 2009 09:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+Hbz7Mc6jbf for ; Fri, 27 Feb 2009 09:48:09 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8ADA628C350 for ; Fri, 27 Feb 2009 09:48:02 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n1RHtAE6021843 for ; Fri, 27 Feb 2009 11:55:25 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 11:48:17 -0600 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 11:48:17 -0600 Received: from esealmw126.eemea.ericsson.se ([130.100.184.161]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 18:48:15 +0100 Received: from [147.214.183.107] ([147.214.183.107]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 18:47:21 +0100 Message-ID: <49A82729.7080801@ericsson.com> Date: Fri, 27 Feb 2009 18:47:21 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: tsvwg X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Feb 2009 17:47:21.0949 (UTC) FILETIME=[712CE8D0:01C99903] Subject: [Tsvwg] Status of draft-ietf-tsvwg-emergency-rsvp X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:48:10 -0000 WG, This is to make you all aware of the following. The RSVP-Emergency draft has been with the IESG for a while. However, the document has 6 abstain ballots. Despite discussion this has not been resolved and it was requested that I do follow the procedure for when a draft becomes deadlocked, namely to send it back to the WG. This is according to IESG balloting procedures: http://www.ietf.org/u/ietfchair/voting-procedures.txt The reasons is a bit varied but mostly are operational and security related. This is the closest the IESG can do to say No to a document. Which means it needs to be very clear that the WG has resolved the fundamental issues before bringing it back to the IESG, if at all. The authors will discuss privately with the abstainers to get some clarification on what the issues are. Based on these we can decide what the next steps are. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jmpolk@cisco.com Fri Feb 27 10:29:44 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB5428C1BF for ; Fri, 27 Feb 2009 10:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCMCbtdcJOM8 for ; Fri, 27 Feb 2009 10:29:43 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 73EC628C151 for ; Fri, 27 Feb 2009 10:29:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233532800"; d="scan'208";a="138114788" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2009 18:30:06 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1RIU65g016506; Fri, 27 Feb 2009 10:30:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n1RIU6vQ025689; Fri, 27 Feb 2009 18:30:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 10:30:06 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.21.13]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 10:30:05 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Feb 2009 12:30:04 -0600 To: Magnus Westerlund , tsvwg From: "James M. Polk" In-Reply-To: <49A82729.7080801@ericsson.com> References: <49A82729.7080801@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 27 Feb 2009 18:30:05.0548 (UTC) FILETIME=[693312C0:01C99909] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4292; t=1235759406; x=1236623406; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Tsvwg]=20Status=20of=20draft-ietf-tsvw g-emergency-rsvp |Sender:=20; bh=p9zUyamoYoukFSzoBij/DJ7uDXBmCuHTu/neRUlRylU=; b=H4orEkswHwby1nY8eCJa9NOJToP/d1ajfWI3nZtY3187k1Dyh0cc2oKzob CEEvJkkz+cli5mUPeM1srjIjgxlYujceTjLyuB3ov6M+lcbVa1bH/pRh1NtK VoP0bxI1+e; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Tsvwg] Status of draft-ietf-tsvwg-emergency-rsvp X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:29:44 -0000 I, as an author, do not need to be as polite as Magnus is below. One of the complaints by the IESG is that with=20 this extension, RSVP will have to work - and=20 misbehave - around the world, when this document=20 clearly scopes its usage to within one=20 administrative domain -- so there is a=20 disagreement between what's written in the ID and=20 what the IESG is imagining will be the scope of usage. I even added a diagram that illustrates this=20 concept that it works between nodes within the=20 same domain, and not between domains (because of=20 the SBCs peering between domains). Another complaint is that this effort (RSVP based=20 obviously) is inappropriately in this WG=20 (remember, TSVWG is chartered with doing RSVP=20 extensions and maintenance), one member of the=20 IESG even saying TSVWG accepting this ID as a WG=20 item was an "end-run around" (their words) from=20 the real WG that this ID should have been brought to, namely ECRIT. Now, for those of you that do not know this,=20 ECRIT handles, exclusively, 911 and 112 and 999=20 type of local emergency calling. Our ID does not=20 apply to these environments - and applies to=20 environments more like MLPP and GETS/GTPS=20 scenarios. This fact seems to elude the IESG,=20 even when we say this to them face-to-face. No=20 reasonable person would say that every=20 911/112/999 call has to be authorized to get=20 answered, yet this seems to be the case the IESG is thinking we're saying. Interestingly, not a single mention of anything=20 wrong with the mechanism as defined and created,=20 but a lot to say about scoping, preventing=20 leakage of this authorization-token (in RSVP=20 only) into other domains, and the fact that ECRIT=20 is the chartered WG to handle this effort. The ECRIT charter sez: "no GETS, no MLPP" here in=20 their WG... see this from the ECRIT charter: http://www.ietf.org/html.charters/ecrit-charter.html "Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements." Needless to say - I'm rather beside myself wrt=20 each of these issues as they are (and I can prove=20 it for the scope/operational issue) a moving=20 target, with a dose of insanity/unreasonableness=20 applied, so I ask the WG, how do we tell the IESG: - we are the proper WG for this work (and not ECRIT, which is in the RAI= Area) - how this document says this is for within a=20 single domain, and not the open Internet (where=20 RSVP doesn't work anyway, so they have nothing to fear) - this document is scoped properly ? James At 11:47 AM 2/27/2009, Magnus Westerlund wrote: >WG, > >This is to make you all aware of the following. The RSVP-Emergency draft >has been with the IESG for a while. However, the document has 6 abstain >ballots. Despite discussion this has not been resolved and it was >requested that I do follow the procedure for when a draft becomes >deadlocked, namely to send it back to the WG. > >This is according to IESG balloting procedures: >http://www.ietf.org/u/ietfchair/voting-procedures.txt > >The reasons is a bit varied but mostly are operational and security >related. > >This is the closest the IESG can do to say No to a document. Which means >it needs to be very clear that the WG has resolved the fundamental >issues before bringing it back to the IESG, if at all. > >The authors will discuss privately with the abstainers to get some >clarification on what the issues are. Based on these we can decide what >the next steps are. > >Cheers > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- From vladislav.yasevich@hp.com Fri Feb 27 13:12:10 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE403A6832 for ; Fri, 27 Feb 2009 13:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.771 X-Spam-Level: X-Spam-Status: No, score=-105.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yer7wMpI0cE0 for ; Fri, 27 Feb 2009 13:12:09 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id AEE9D3A67F3 for ; Fri, 27 Feb 2009 13:12:09 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 36B002424D; Fri, 27 Feb 2009 21:12:32 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 5BDBA1001B; Fri, 27 Feb 2009 21:12:31 +0000 (UTC) Message-ID: <49A8573E.7000602@hp.com> Date: Fri, 27 Feb 2009 16:12:30 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Kacheong Poon References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> <49A7BF71.3000707@sun.com> <49A7C452.6080102@sun.com> In-Reply-To: <49A7C452.6080102@sun.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:12:10 -0000 Kacheong Poon wrote: > Michael Tüxen wrote: > >> I do not care that much about the name... >> So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC? > > > They are fine. > > Fine with me as well. -vlad From vladislav.yasevich@hp.com Fri Feb 27 13:15:22 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4AF3A68E8 for ; Fri, 27 Feb 2009 13:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.759 X-Spam-Level: X-Spam-Status: No, score=-105.759 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A5elHZptqN5 for ; Fri, 27 Feb 2009 13:15:22 -0800 (PST) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id 1FFAD3A68AB for ; Fri, 27 Feb 2009 13:15:22 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 71FB0C080; Fri, 27 Feb 2009 21:15:44 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id BE0A910004; Fri, 27 Feb 2009 21:15:43 +0000 (UTC) Message-ID: <49A857FE.3010800@hp.com> Date: Fri, 27 Feb 2009 16:15:42 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <2205DEAD-E753-4AE1-8062-9084A2202277@lakerest.net> <49A7C2E6.2080305@sun.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Kacheong Poon , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:15:22 -0000 Michael Tüxen wrote: > On Feb 27, 2009, at 11:39 AM, Kacheong Poon wrote: > >> Randy Stewart wrote: >> >>> 1) We specify that SCTP_EVENTS is obsoleted and discourage use. >>> 2) We specify that if you are using SCTP_EVENTS you should only >>> do so BEFORE associations are are established (at the beginning >>> of your program after the socket call). >>> 3) We specify that if you do use SCTP_EVENTS later on then the behavior >>> is unspecified as to if it effects future assoc OR also ones already >>> in progress. >> >> >> I'd like to keep the existing semantics of SCTP_EVENTS, which >> means all and future so existing apps will have no problem. >> And there should be no restriction on when it can be called, >> as specified in the current draft. > I agree. Maybe we should add a note that this socket options > will be obsoleted in the future? That certain seems like where we are going with this. I am fine if this option is obsoleted/deprecated and we can warn people. Once that's done, anyone using the old option in combination with the new is doing so at their own risk. I just thought to bring up this possibility to make sure it was addressed. Thanks -vlad From cbenson@adax.com Fri Feb 27 13:26:36 2009 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D893A67B6 for ; Fri, 27 Feb 2009 13:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai8ZrdHnqf4z for ; Fri, 27 Feb 2009 13:26:35 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 9BE513A6403 for ; Fri, 27 Feb 2009 13:26:35 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id EB415120992; Fri, 27 Feb 2009 13:26:57 -0800 (PST) Received: by adax (Postfix, from userid 243) id 3C4775AED5; Fri, 27 Feb 2009 13:28:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 32CBC5EE9A; Fri, 27 Feb 2009 13:28:34 -0800 (PST) Date: Fri, 27 Feb 2009 13:28:34 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Vlad Yasevich In-Reply-To: <49A8573E.7000602@hp.com> Message-ID: References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A65FAA.8090503@sun.com> <4132CB76-26B8-4F1E-A06B-2C09B0A2E305@lakerest.net> <49A69E05.8080807@hp.com> <49A7B8E4.5010606@sun.com> <49BE83D3-B6A7-4FEF-9328-5FE492A6757B@lurchi.franken.de> <49A7BF71.3000707@sun.com> <49A7C452.6080102@sun.com> <49A8573E.7000602@hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , Kacheong Poon , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:26:36 -0000 Vlad (and Kacheong and Michael), > [...] suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC Please pluralize the macro names though ... SCTP_ALL_ASSOCS and SCTP_FUTURE_ASSOCS :-D Chris Benson, Adax inc. On Fri, 27 Feb 2009, Vlad Yasevich wrote: >> Date: Fri, 27 Feb 2009 16:12:30 -0500 >> From: Vlad Yasevich >> To: Kacheong Poon >> Cc: Michael T?xen , >> tsvwg , Randy Stewart >> Subject: Re: [Tsvwg] Event Notifications >> >> > >> >> I do not care that much about the name... >> >> So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC? >> > >> > >> > They are fine. >> > >> > >> >> Fine with me as well. >> >> -vlad >> Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AE928C229 for ; Thu, 5 Feb 2009 03:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8se8ERhllx8 for ; Thu, 5 Feb 2009 03:40:44 -0800 (PST) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 6D7093A6940 for ; Thu, 5 Feb 2009 03:40:44 -0800 (PST) Received: from [192.168.1.4] (p5481F450.dip.t-dialin.net [84.129.244.80]) by mail-n.franken.de (Postfix) with ESMTP id B5E821C0B4621; Thu, 5 Feb 2009 12:40:18 +0100 (CET) Message-Id: <5272FCE0-9471-46B0-92CD-E4BFB40AC06B@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: tsvwg Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 12:40:17 +0100 X-Mailer: Apple Mail (2.930.3) Cc: Robin Seggelmann Subject: [Tsvwg] DTLS interop server available on interop.fh-muenster.de X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 11:40:54 -0000 Dear all, Robin and myself have setup an DTLS interop server at interop.fh-muenster.de (195.37.125.98). It runs an echo and discard server for DTLS/UDP and DTLS/SCTP. The DTLS implementation use is the one from OpenSSL with Robins bug fixes available at http://sctp.fh-muenster.de If you have comments, questions, found bugs or anything else related to the above interop testing, please send an e-mail to seggelmann@fh-muenster.de or tuexen@fh-muenster.de. Best regards Michael Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60AD3A6AFE for ; Thu, 5 Feb 2009 06:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R2NUYg10WzU for ; Thu, 5 Feb 2009 06:32:51 -0800 (PST) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by core3.amsl.com (Postfix) with ESMTP id 438263A698E for ; Thu, 5 Feb 2009 06:32:51 -0800 (PST) Received: (qmail 25602 invoked from network); 5 Feb 2009 14:32:31 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Feb 2009 14:32:31 -0000 Message-ID: <498AF87F.5060609@asomi.com> Date: Thu, 05 Feb 2009 06:32:31 -0800 From: Caitlin Bestler User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Transport WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Tsvwg] draft-ietf-sctpsocket-18: sinfo_context and successful sendmsg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 14:32:52 -0000 This is a repost - the original went astray. -------------------------------------------- In the current draft the sinfo_context is only specified to be returned "back to the upper layer if an error occurs" [page 25]. RDMA interfaces typically have an option where transmit requests will generate an explicit completion even if the operation completes successfully. When iWARP is implemented over SCTP sockets it would be useful to have an option where the sinfo_context would be returned for a specific SCTP message even when no error occurs. I would propose that an additional sendmsg() flag be defined for this option. The same completion mechanism as used for errors could be used, just with a "no error" error code. Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF47A3A6985; Mon, 9 Feb 2009 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090209151501.BF47A3A6985@core3.amsl.com> Date: Mon, 9 Feb 2009 07:15:01 -0800 (PST) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 15:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-emergency-rsvp-10.txt Pages : 37 Date : 2009-02-09 An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. The mechanisms defined in this document are applicable to controlled environments formed by either a single administrative domain or a set of administrative domains that closely coordinate their network policy and network design. The mechanisms defined in this document can be used for a session whose path spans over such a controlled environment in order to elevate the session establishment probability through the controlled environment (thereby elevating the end to end session establishment probability). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-emergency-rsvp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-09070953.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E31A23A6ACE; Mon, 16 Feb 2009 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090216141501.E31A23A6ACE@core3.amsl.com> Date: Mon, 16 Feb 2009 06:15:01 -0800 (PST) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-sctpsocket-19.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpsocket-19.txt Pages : 87 Date : 2009-02-16 This document describes a mapping of the Stream Control Transmission Protocol SCTP into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-16061418.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1C8E63A6917; Wed, 18 Feb 2009 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090218191502.1C8E63A6917@core3.amsl.com> Date: Wed, 18 Feb 2009 11:15:02 -0800 (PST) Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-emergency-rsvp-11.txt Pages : 37 Date : 2009-02-18 An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. The mechanisms defined in this document are applicable to controlled environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-emergency-rsvp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-18111459.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DC63A689C for ; Mon, 23 Feb 2009 13:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv3ePJhDKtwS for ; Mon, 23 Feb 2009 13:05:18 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id D1DDF3A6833 for ; Mon, 23 Feb 2009 13:05:18 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 719D8381D0; Mon, 23 Feb 2009 21:05:36 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id BBF8E1001D; Mon, 23 Feb 2009 21:05:35 +0000 (UTC) Message-ID: <49A30F9E.90504@hp.com> Date: Mon, 23 Feb 2009 16:05:34 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Michael Tuexen , Randall Stewart , Kacheong Poon X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg Subject: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:05:19 -0000 Hi All I've recently been asked about SCTP_EXPLICIT_EOF support on linux. After re-rereading the spec, I realized that the text is rather sparse. The first question that came to mind was whether this should be limited to 1-1 sockets (as it appears to be), or should it also be available for 1-many sockets? If the later, the API needs to change to include the association id. The other thing is that we need to explain the limitation of this option wrt. to multi-streaming. I've had to explain to a few users already this limitation and it considerable changed their plans. Additionally, since there is no signaling mechanism that lets a peer know that this API is in use, there needs to some guidance here as well. As it stands right now, when the sender uses this option, the receiver needs to reset its partial deliver point so that data gets delivered instead of waiting to be fully reassembled, which may be a very long time. -vlad Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498603A6858 for ; Tue, 24 Feb 2009 01:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucRI3bua6uCp for ; Tue, 24 Feb 2009 01:37:20 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id C6C373A6942 for ; Tue, 24 Feb 2009 01:37:19 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1O9bVvD067517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2009 04:37:42 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: From: Randy Stewart To: Vlad Yasevich In-Reply-To: <49A30F9E.90504@hp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 04:37:21 -0500 References: <49A30F9E.90504@hp.com> X-Mailer: Apple Mail (2.930.3) Cc: Michael Tuexen , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 09:37:21 -0000 On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote: > Hi All > > I've recently been asked about SCTP_EXPLICIT_EOF support on linux. > After re-rereading the spec, I realized that the text is rather > sparse. > > The first question that came to mind was whether this should be > limited > to 1-1 sockets (as it appears to be), or should it also be available > for 1-many sockets? If the later, the API needs to change to include > the association id. Hmm if you get that impression it is INCORRECT. the explicit EOR mode should work no matter if you are one-2-one or one-2-many. If you are on a 1-2-m socket then once you do a EOR mode on that assoc whenever you write to that one association, until you explicitly say "EOR" you are sending to that same stream. In fact the BSD implementation will give you an error if you try to change the stream number. So for example I could do socketopt(12msd, set EOR mode, assoc1); send("msgpart1", assoc1, stream-1); send("mspart2", assoc1, stream-1) send("entire msg", assoc2, stream-8); send("mspart3", assoc1, stream-1); If I tried send ("msgforanotherstream", assoc1, stream-5); // ERRROR return Until I finally do send ("msgfinalpart", assoc1, stream-1, "EEOR"); Now once this last one is done I can send again to some other stream send ("newmsg", assoc1, stream-N); For that matter I could send just like EEOR mode was off if I did: send ("newmsg", assoc1, stream-N, "EEOR"); I should have lots of time after March 4th to look at the i-d I will see if I can't tighten up the wording a bit :-) > > > The other thing is that we need to explain the limitation of this > option wrt. to multi-streaming. I've had to explain to a few users > already this limitation and it considerable changed their plans. Yes, it needs to stated explicitly if you start sending to stream-x until you do EOR you must send to stream-x... at least thats the way I envisioned it. If you will until you indicate EEOR the connection becomes no different than a TCP connection... i.e. a stream of bytes. Hmm.. I wonder if we could lift this restriction.. I will have to think about that... > > > Additionally, since there is no signaling mechanism that lets a peer > know that this API is in use, there needs to some guidance here as > well. > As it stands right now, when the sender uses this option, the > receiver > needs to reset its partial deliver point so that data gets delivered > instead > of waiting to be fully reassembled, which may be a very long time. Yep, the only reasonable way to use this is to set the PD-API point to 1. This way you will not be stuck waiting for data without being aware of it :-) I am sure we need to add a bit of text here :-) R > > > -vlad > > > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8424B3A6874 for ; Tue, 24 Feb 2009 05:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.605 X-Spam-Level: X-Spam-Status: No, score=-104.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea6a1g0Y79Gg for ; Tue, 24 Feb 2009 05:23:55 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 8BD393A6839 for ; Tue, 24 Feb 2009 05:23:55 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 3A4E1240DF; Tue, 24 Feb 2009 13:24:14 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 4F7FE10007; Tue, 24 Feb 2009 13:24:13 +0000 (UTC) Message-ID: <49A3F4FC.8010803@hp.com> Date: Tue, 24 Feb 2009 08:24:12 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Stewart References: <49A30F9E.90504@hp.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Tuexen , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:23:56 -0000 Randy Stewart wrote: > > On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote: > >> Hi All >> >> I've recently been asked about SCTP_EXPLICIT_EOF support on linux. >> After re-rereading the spec, I realized that the text is rather sparse. >> >> The first question that came to mind was whether this should be limited >> to 1-1 sockets (as it appears to be), or should it also be available >> for 1-many sockets? If the later, the API needs to change to include >> the association id. > > Hmm if you get that impression it is INCORRECT. the explicit EOR mode > should work no matter if you are one-2-one or one-2-many. I get this "impression" because the is no way to turn on explicit EOR on an association. The interface doesn't allow one to pass the association id to the kernel. Thus, it's really a per-socket value, meaning that every association on a 1-many socket would use explicit EOR mode. If we want to offer full support for 1-many api, we need change the option api to be able to take association id, just like most other API already specified. > > If you are on a 1-2-m socket then once you do a EOR mode on > that assoc whenever you write to that one association, until > you explicitly say "EOR" you are sending to that same stream. In > fact the BSD implementation will give you an error if you try > to change the stream number. So for example I could do > > socketopt(12msd, set EOR mode, assoc1); But you can't with the api. Generic setsockopt doesn't take assoc id. Thanks -vlad > send("msgpart1", assoc1, stream-1); > send("mspart2", assoc1, stream-1) > send("entire msg", assoc2, stream-8); > send("mspart3", assoc1, stream-1); > > If I tried > send ("msgforanotherstream", assoc1, stream-5); // ERRROR return > > Until I finally do > > send ("msgfinalpart", assoc1, stream-1, "EEOR"); > > Now once this last one is done I can send again to some > other stream > > send ("newmsg", assoc1, stream-N); > > For that matter I could send just like EEOR mode was off if I did: > > send ("newmsg", assoc1, stream-N, "EEOR"); > > I should have lots of time after March 4th to look at the i-d I will > see if I can't tighten up the wording a bit :-) > >> >> >> The other thing is that we need to explain the limitation of this >> option wrt. to multi-streaming. I've had to explain to a few users >> already this limitation and it considerable changed their plans. > > Yes, it needs to stated explicitly if you start sending to stream-x > until you do EOR you must send to stream-x... at least thats > the way I envisioned it. If you will until you indicate EEOR > the connection becomes no different than a TCP connection... i.e. > a stream of bytes. Hmm.. I wonder if we could lift this restriction.. > I will have to think about that... > >> >> >> Additionally, since there is no signaling mechanism that lets a peer >> know that this API is in use, there needs to some guidance here as well. >> As it stands right now, when the sender uses this option, the receiver >> needs to reset its partial deliver point so that data gets delivered >> instead >> of waiting to be fully reassembled, which may be a very long time. > > Yep, the only reasonable way to use this is to set the PD-API point to > 1. This > way you will not be stuck waiting for data without being aware of it :-) > > I am sure we need to add a bit of text here :-) > > R > >> >> >> -vlad >> >> >> > > ----- > Randall Stewart > randall@lakerest.net > > > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C719E28C244 for ; Tue, 24 Feb 2009 10:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1quGcschA0Br for ; Tue, 24 Feb 2009 10:29:28 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id A178028C168 for ; Tue, 24 Feb 2009 10:29:28 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 852003825E; Tue, 24 Feb 2009 18:29:47 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id AD9E610020; Tue, 24 Feb 2009 18:29:46 +0000 (UTC) Message-ID: <49A43C99.90500@hp.com> Date: Tue, 24 Feb 2009 13:29:45 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> In-Reply-To: <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Kacheong Poon , tsvwg , Randy Stewart Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:29:31 -0000 Michael Tüxen wrote: > Hi Vlad, > > comments in-line. > > Best regards > Michael > > On Feb 24, 2009, at 2:24 PM, Vlad Yasevich wrote: > >> Randy Stewart wrote: >>> >>> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote: >>> >>>> Hi All >>>> >>>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux. >>>> After re-rereading the spec, I realized that the text is rather sparse. >>>> >>>> The first question that came to mind was whether this should be limited >>>> to 1-1 sockets (as it appears to be), or should it also be available >>>> for 1-many sockets? If the later, the API needs to change to include >>>> the association id. >>> >>> Hmm if you get that impression it is INCORRECT. the explicit EOR mode >>> should work no matter if you are one-2-one or one-2-many. >> >> I get this "impression" because the is no way to turn on explicit EOR on >> an association. The interface doesn't allow one to pass the association >> id to the kernel. Thus, it's really a per-socket value, meaning that >> every >> association on a 1-many socket would use explicit EOR mode. If we want >> to offer full support for 1-many api, we need change the option api to >> be able to take association id, just like most other API already >> specified. > We could use > > struct sctp_assoc_value { > sctp_assoc_t assoc_id; > uint32_t assoc_value; > }; > > instead of an int and use assoc_value to enable/disable if we want > to be able to control this on a per association base, which makes sense > for me. > Kacheong, what do you think? Hi Michael That would work. If assoc_id is set to 0, option applies to socket and future associations. >> >>> >>> If you are on a 1-2-m socket then once you do a EOR mode on >>> that assoc whenever you write to that one association, until >>> you explicitly say "EOR" you are sending to that same stream. In >>> fact the BSD implementation will give you an error if you try >>> to change the stream number. So for example I could do >>> >>> socketopt(12msd, set EOR mode, assoc1); >> >> But you can't with the api. Generic setsockopt doesn't take assoc id. > Correct. We can't do this for socket options. And we can't enable > notifications on a per association base. Should we change that too? Hmm.. That's an interesting question. Is it a possible scenario where an application decides to change event subscription of an association after it's established? I can't see a reason right now, but that doesn't mean it doesn't exist. On the other hand, I see an application wanting to temporarily enable EEOR, to transfer a very large message, and then turn EEOR off again. It's simple on the 1-1 socket, but on a 1-many you can change the setting for a single association without peeling it off. Thanks -vlad >> >> >> Thanks >> -vlad >> >>> send("msgpart1", assoc1, stream-1); >>> send("mspart2", assoc1, stream-1) >>> send("entire msg", assoc2, stream-8); >>> send("mspart3", assoc1, stream-1); >>> >>> If I tried >>> send ("msgforanotherstream", assoc1, stream-5); // ERRROR return >>> >>> Until I finally do >>> >>> send ("msgfinalpart", assoc1, stream-1, "EEOR"); >>> >>> Now once this last one is done I can send again to some >>> other stream >>> >>> send ("newmsg", assoc1, stream-N); >>> >>> For that matter I could send just like EEOR mode was off if I did: >>> >>> send ("newmsg", assoc1, stream-N, "EEOR"); >>> >>> I should have lots of time after March 4th to look at the i-d I will >>> see if I can't tighten up the wording a bit :-) >>> >>>> >>>> >>>> The other thing is that we need to explain the limitation of this >>>> option wrt. to multi-streaming. I've had to explain to a few users >>>> already this limitation and it considerable changed their plans. >>> >>> Yes, it needs to stated explicitly if you start sending to stream-x >>> until you do EOR you must send to stream-x... at least thats >>> the way I envisioned it. If you will until you indicate EEOR >>> the connection becomes no different than a TCP connection... i.e. >>> a stream of bytes. Hmm.. I wonder if we could lift this restriction.. >>> I will have to think about that... >>> >>>> >>>> >>>> Additionally, since there is no signaling mechanism that lets a peer >>>> know that this API is in use, there needs to some guidance here as >>>> well. >>>> As it stands right now, when the sender uses this option, the receiver >>>> needs to reset its partial deliver point so that data gets delivered >>>> instead >>>> of waiting to be fully reassembled, which may be a very long time. >>> >>> Yep, the only reasonable way to use this is to set the PD-API point to >>> 1. This >>> way you will not be stuck waiting for data without being aware of it :-) >>> >>> I am sure we need to add a bit of text here :-) >>> >>> R >>> >>>> >>>> >>>> -vlad >>>> >>>> >>>> >>> >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>> >>> >>> >>> >> >> > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C8D3A6928 for ; Tue, 24 Feb 2009 19:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiZRyciCWKMP for ; Tue, 24 Feb 2009 19:33:12 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 194903A680A for ; Tue, 24 Feb 2009 19:33:12 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P3XT7O015125; Wed, 25 Feb 2009 03:33:30 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1P3XOIX782072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 19:33:26 -0800 (PST) Message-ID: <49A4BC05.5040502@sun.com> Date: Wed, 25 Feb 2009 11:33:25 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Vlad Yasevich References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> In-Reply-To: <49A43C99.90500@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg , Randy Stewart Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:33:13 -0000 Vlad Yasevich wrote: > Michael Tüxen wrote: ... >> We could use >> >> struct sctp_assoc_value { >> sctp_assoc_t assoc_id; >> uint32_t assoc_value; >> }; >> >> instead of an int and use assoc_value to enable/disable if we want >> to be able to control this on a per association base, which makes sense >> for me. >> Kacheong, what do you think? > > Hi Michael > > That would work. If assoc_id is set to 0, option applies to socket > and future associations. This is fine. >> Correct. We can't do this for socket options. And we can't enable >> notifications on a per association base. Should we change that too? > > Hmm.. That's an interesting question. Is it a possible scenario where > an application decides to change event subscription of an association after > it's established? I can't see a reason right now, but that doesn't mean it > doesn't exist. I am also not sure if it is worthwhile to do that. -- K. Poon. kacheong.poon@sun.com Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EBC3A6928 for ; Tue, 24 Feb 2009 19:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XZ7CCMlHjmK for ; Tue, 24 Feb 2009 19:46:40 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 1DFDD3A67B2 for ; Tue, 24 Feb 2009 19:46:40 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P3krsQ022147; Wed, 25 Feb 2009 03:46:53 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1P3kmPN784527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 19:46:50 -0800 (PST) Message-ID: <49A4BF2A.7030400@sun.com> Date: Wed, 25 Feb 2009 11:46:50 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> In-Reply-To: <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Vlad Yasevich , tsvwg , Randy Stewart Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:46:41 -0000 Michael Tüxen wrote: > On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: ... >> Hmm.. That's an interesting question. Is it a possible scenario where >> an application decides to change event subscription of an association >> after >> it's established? I can't see a reason right now, but that doesn't >> mean it >> doesn't exist. > We do this for the DRY event since we are only interested in it > during some specific states in DTLS (during renegotiations). If we want to explore this, I'd suggest we retire (just keep it there for backward compatibility) the sctp_event_subscribe. It is not extensible. Just use sctp_assoc_value. An app can subscribe/unsubscribe each event one by one. BTW, I guess it should not cause a problem if the DRY event is enabled for all associations controlled by one socket all the time. -- K. Poon. kacheong.poon@sun.com Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F9D3A68E4 for ; Wed, 25 Feb 2009 00:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHayVpG96JHR for ; Wed, 25 Feb 2009 00:22:57 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 79E093A6B56 for ; Wed, 25 Feb 2009 00:22:56 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1P8NKdj036364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 03:23:21 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <44B22863-BB85-4B9A-BCB3-2D34FCB3BB7C@lakerest.net> From: Randy Stewart To: Kacheong Poon In-Reply-To: <49A4BC05.5040502@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 03:23:10 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <49A4BC05.5040502@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:22:59 -0000 On Feb 24, 2009, at 10:33 PM, Kacheong Poon wrote: > Vlad Yasevich wrote: >> Michael T=FCxen wrote: > ... >>> We could use >>> >>> struct sctp_assoc_value { >>> sctp_assoc_t assoc_id; >>> uint32_t assoc_value; >>> }; >>> >>> instead of an int and use assoc_value to enable/disable if we want >>> to be able to control this on a per association base, which makes =20= >>> sense >>> for me. >>> Kacheong, what do you think? >> Hi Michael >> That would work. If assoc_id is set to 0, option applies to socket >> and future associations. > > > This is fine. Yeah, I agree here.. and I had missed the fact that I forgot to add on/off EOR mode for per assoc... good catch lets add this (and I will fix my code too :-D) > > > >>> Correct. We can't do this for socket options. And we can't enable >>> notifications on a per association base. Should we change that too? >> Hmm.. That's an interesting question. Is it a possible scenario =20 >> where >> an application decides to change event subscription of an =20 >> association after >> it's established? I can't see a reason right now, but that doesn't =20= >> mean it >> doesn't exist. > > > I am also not sure if it is worthwhile to do that. I agree here too.. I don't see the value in notifications on a per assoc basis... R > > > > --=20 > > K. Poon. > kacheong.poon@sun.com > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035533A6B62 for ; Wed, 25 Feb 2009 00:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6NJuNs-NfdM for ; Wed, 25 Feb 2009 00:32:28 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 3FC4F3A6951 for ; Wed, 25 Feb 2009 00:32:27 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1P8WsuM036700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 03:32:54 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> From: Randy Stewart To: Kacheong Poon In-Reply-To: <49A4BF2A.7030400@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 03:32:44 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:32:30 -0000 On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: > Michael T=FCxen wrote: >> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: > ... >>> Hmm.. That's an interesting question. Is it a possible scenario =20= >>> where >>> an application decides to change event subscription of an =20 >>> association after >>> it's established? I can't see a reason right now, but that =20 >>> doesn't mean it >>> doesn't exist. >> We do this for the DRY event since we are only interested in it >> during some specific states in DTLS (during renegotiations). > > > If we want to explore this, I'd suggest we retire (just keep > it there for backward compatibility) the sctp_event_subscribe. > It is not extensible. Just use sctp_assoc_value. An app can > subscribe/unsubscribe each event one by one. > > BTW, I guess it should not cause a problem if the DRY event is > enabled for all associations controlled by one socket all the > time. > Hmm so let me summarize what I think we have agreed to so far 1) We will add support for using the sctp_assoc_value structure to turn on/off EEOR mode on a per assoc basis. 2) If the value of the assoc is 0, then the entire socket (1-2many or =20= 1-1) is set to EEOR mode this includes future and all existing sockets. On the events... I am not convinced a per-assoc subscription is needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many socket .. you know if you are sending and can turn it off as soon as the dry-event occurs. If you get a dry event on another association, you can pretty easily ignore it. It might be nice to have per-association on/off of some events. But I am mixed on how useful that is. I do agree with Kacheong here though, if we have to go this route we need a new structure.. i.e. one that includes an assoc id.. and then do the thing that says if the assoc-id=3D=3D0 its to future associations or the entire socket... vs just changing a single association. I would also think we want to make it more extensible and as Kacheong said just retire the old SCTP_EVENTS... i.e. support for backward =20 compatibility but move to the new structure for future things.. But again, is this really worth it? I am not convinced it is yet.. R > > --=20 > > K. Poon. > kacheong.poon@sun.com > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9863A686C for ; Wed, 25 Feb 2009 01:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.032 X-Spam-Level: **** X-Spam-Status: No, score=4.032 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSsZAZ-GQcdK for ; Wed, 25 Feb 2009 01:35:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A3C0D3A6781 for ; Wed, 25 Feb 2009 01:35:26 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 313271C0B4620; Wed, 25 Feb 2009 10:35:41 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Randy Stewart In-Reply-To: <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 10:35:40 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 09:35:28 -0000 On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: > > On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: > >> Michael T=FCxen wrote: >>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >> ... >>>> Hmm.. That's an interesting question. Is it a possible scenario =20= >>>> where >>>> an application decides to change event subscription of an =20 >>>> association after >>>> it's established? I can't see a reason right now, but that =20 >>>> doesn't mean it >>>> doesn't exist. >>> We do this for the DRY event since we are only interested in it >>> during some specific states in DTLS (during renegotiations). >> >> >> If we want to explore this, I'd suggest we retire (just keep >> it there for backward compatibility) the sctp_event_subscribe. >> It is not extensible. Just use sctp_assoc_value. An app can >> subscribe/unsubscribe each event one by one. >> >> BTW, I guess it should not cause a problem if the DRY event is >> enabled for all associations controlled by one socket all the >> time. >> > > Hmm so let me summarize what I think we have agreed to so far > > 1) We will add support for using the sctp_assoc_value structure > to turn on/off EEOR mode on a per assoc basis. > 2) If the value of the assoc is 0, then the entire socket (1-2many =20 > or 1-1) is > set to EEOR mode this includes future and all existing sockets. > > > On the events... I am not convinced a per-assoc subscription is > needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many > socket .. you know if you are sending and can turn it off as soon > as the dry-event occurs. If you get a dry event on another > association, you can pretty easily ignore it. It might be nice > to have per-association on/off of some events. But I am mixed > on how useful that is. > > I do agree with Kacheong here though, if we have to go this route we > need a new structure.. i.e. one that includes an assoc id.. and then > do the thing that says if the assoc-id=3D=3D0 its to future = associations > or the entire socket... vs just changing a single association. I would > also think we want to make it more extensible and as Kacheong said > just retire the old SCTP_EVENTS... i.e. support for backward =20 > compatibility > but move to the new structure for future things.. > > But again, is this really worth it? I am not convinced it is yet.. There are two points here specific to the DRY event: 1. Performance: I might be interested only in the events for one particular association, but I get them for all. Of course I can ignore them for all associations I'm not interested in, but this means the kernel is going to generate a lot of =20 notifications I'm not interested in. This is just waisted cycles and mbufs. 2. The DRY event is generated when it is enabled and the the association is dry. So assume I have N associations (being dry), I'm interested in one. Now I enable it. The kernel has to generate N notifications instantly. This might be a resource problem (on Mac OS X I ran into it), because you need N mbufs at about the same time. There is also no "flow control" for notifications. That is why I implemented this currently only for 1-to-1 style =20 sockets. But I think we should be more future proof here. I like Kacheongs idea to use the assoc_value structs: 1. This allows it to control it on an association base. No limitation here. 2. It can be used with any future notification. It is just adding a new constant, not changing a structure which might break ABI =20 compatibility. 3. It is simple. I think we should add this. > > R > > > >> >> --=20 >> >> K. Poon. >> kacheong.poon@sun.com >> > > ----- > Randall Stewart > randall@lakerest.net > > > > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D90528C154 for ; Wed, 25 Feb 2009 03:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsfG2XAlNNOp for ; Wed, 25 Feb 2009 03:26:52 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id A8DFB28C152 for ; Wed, 25 Feb 2009 03:26:51 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1PBRF1U043328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 06:27:16 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <05F77D7F-958B-4726-9E9F-A3889245228C@lakerest.net> From: Randy Stewart To: Randy Stewart In-Reply-To: <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 06:27:06 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , =?ISO-8859-1?Q?Michael_T=FCxen?= , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] EXPLICIT_EOR api X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:26:53 -0000 Let me reply to myself :-) Since I had no coffee when I wrote this (never answer email at 3am when you first wakeup without coffee :-D): > > > Hmm so let me summarize what I think we have agreed to so far > > 1) We will add support for using the sctp_assoc_value structure > to turn on/off EEOR mode on a per assoc basis. > 2) If the value of the assoc is 0, then the entire socket (1-2many > or 1-1) is > set to EEOR mode this includes future and all existing sockets. > > I think the above needs to be reworded.. to be consistent with what we do in the rest of the api: 1) We will add support for using the sctp_assoc_value structure to turn on/off EEOR mode on a per assoc basis. This is fine ;-) but 2 should be: 2) if the value of the assoc is 0, then all FUTURE sockets only are setup to be EEOR mode. Not existing assoc's.. I realized this AM that we are pretty consistent that when we do an assoc-id ==0 on some setting then the change only effects "future" assoc's. I will reply separately on the sender-dry event since this is a separate thread I think. Lets keep the two things separate please :-) R ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3FE3A6A18 for ; Wed, 25 Feb 2009 03:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTTEMNwhKcN0 for ; Wed, 25 Feb 2009 03:34:32 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 4552D3A6843 for ; Wed, 25 Feb 2009 03:34:30 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1PBYuAs043588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 06:34:57 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> From: Randy Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 06:34:47 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:34:33 -0000 On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: > On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: > >> >> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >> >>> Michael T=FCxen wrote: >>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>> ... >>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>> scenario where >>>>> an application decides to change event subscription of an =20 >>>>> association after >>>>> it's established? I can't see a reason right now, but that =20 >>>>> doesn't mean it >>>>> doesn't exist. >>>> We do this for the DRY event since we are only interested in it >>>> during some specific states in DTLS (during renegotiations). >>> >>> >>> If we want to explore this, I'd suggest we retire (just keep >>> it there for backward compatibility) the sctp_event_subscribe. >>> It is not extensible. Just use sctp_assoc_value. An app can >>> subscribe/unsubscribe each event one by one. >>> >>> BTW, I guess it should not cause a problem if the DRY event is >>> enabled for all associations controlled by one socket all the >>> time. >>> >> >> Hmm so let me summarize what I think we have agreed to so far >> >> 1) We will add support for using the sctp_assoc_value structure >> to turn on/off EEOR mode on a per assoc basis. >> 2) If the value of the assoc is 0, then the entire socket (1-2many =20= >> or 1-1) is >> set to EEOR mode this includes future and all existing sockets. >> >> >> On the events... I am not convinced a per-assoc subscription is >> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many >> socket .. you know if you are sending and can turn it off as soon >> as the dry-event occurs. If you get a dry event on another >> association, you can pretty easily ignore it. It might be nice >> to have per-association on/off of some events. But I am mixed >> on how useful that is. >> >> I do agree with Kacheong here though, if we have to go this route we >> need a new structure.. i.e. one that includes an assoc id.. and then >> do the thing that says if the assoc-id=3D=3D0 its to future = associations >> or the entire socket... vs just changing a single association. I =20 >> would >> also think we want to make it more extensible and as Kacheong said >> just retire the old SCTP_EVENTS... i.e. support for backward =20 >> compatibility >> but move to the new structure for future things.. >> >> But again, is this really worth it? I am not convinced it is yet.. > There are two points here specific to the DRY event: > > 1. Performance: I might be interested only in the events for one > particular association, but I get them for all. Of course I > can ignore them for all associations I'm not interested in, > but this means the kernel is going to generate a lot of =20 > notifications > I'm not interested in. This is just waisted cycles and mbufs. > > 2. The DRY event is generated when it is enabled and the the =20 > association > is dry. So assume I have N associations (being dry), I'm interested > in one. Now I enable it. The kernel has to generate N notifications > instantly. This might be a resource problem (on Mac OS X I ran into > it), because you need N mbufs at about the same time. There is also > no "flow control" for notifications. > That is why I implemented this currently only for 1-to-1 style =20 > sockets. > > But I think we should be more future proof here. > I like Kacheongs idea to use the assoc_value structs: > 1. This allows it to control it on an association base. No limitation > here. > 2. It can be used with any future notification. It is just adding a > new constant, not changing a structure which might break ABI =20 > compatibility. > 3. It is simple. > > I think we should add this. Michael so what you are proposing is that we: 1) Keep the existing SCTP_EVENT's socket call. 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a sctp_assoc_value structure. Where the assoc-id is the assoc you want the notification on. And the value is the Notification id. We would type all current notifications with constants e.g. SCTP_DRY_NOTIFICATION 3) I think we would want 0 to be again, future associations and non-zero to be specific associations. Now this would also mean that the existing SCTP_EVENT's would have a slight change, which I think is ok. It would now be a short cut equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with the assoc-id set to 0. I.e. it would ONLY effect future assoc's. This is a subtle difference but one we should document well. I think its ok, since most folks using the SCTP_EVENT's do not change things in the middle. They basically open a socket, set the events they may want... and then never touch it again. I do agree this would then add a nice extensible mechanism to add future events as well. As long as Kacheong and Vlad are ok with this I am too... I can see it will at least be useful for the sender-dry-event. Not sure about other ones but you never know. Kacheong, Vlad, -- thoughts.. if you agree I will start making changes in BSD and the ID.. R ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663CB3A6997 for ; Wed, 25 Feb 2009 03:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.367 X-Spam-Level: *** X-Spam-Status: No, score=3.367 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BEOTmBLnvHp for ; Wed, 25 Feb 2009 03:54:24 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 6E4023A699C for ; Wed, 25 Feb 2009 03:54:23 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id F06681C0E9633; Wed, 25 Feb 2009 12:54:40 +0100 (CET) Message-Id: <0C01E701-380F-4976-9BDF-A168B3859B49@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Randy Stewart In-Reply-To: <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 12:54:39 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:54:25 -0000 On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote: > > On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: > >> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >> >>> >>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>> >>>> Michael T=FCxen wrote: >>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>> ... >>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>> scenario where >>>>>> an application decides to change event subscription of an =20 >>>>>> association after >>>>>> it's established? I can't see a reason right now, but that =20 >>>>>> doesn't mean it >>>>>> doesn't exist. >>>>> We do this for the DRY event since we are only interested in it >>>>> during some specific states in DTLS (during renegotiations). >>>> >>>> >>>> If we want to explore this, I'd suggest we retire (just keep >>>> it there for backward compatibility) the sctp_event_subscribe. >>>> It is not extensible. Just use sctp_assoc_value. An app can >>>> subscribe/unsubscribe each event one by one. >>>> >>>> BTW, I guess it should not cause a problem if the DRY event is >>>> enabled for all associations controlled by one socket all the >>>> time. >>>> >>> >>> Hmm so let me summarize what I think we have agreed to so far >>> >>> 1) We will add support for using the sctp_assoc_value structure >>> to turn on/off EEOR mode on a per assoc basis. >>> 2) If the value of the assoc is 0, then the entire socket (1-2many =20= >>> or 1-1) is >>> set to EEOR mode this includes future and all existing sockets. >>> >>> >>> On the events... I am not convinced a per-assoc subscription is >>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many >>> socket .. you know if you are sending and can turn it off as soon >>> as the dry-event occurs. If you get a dry event on another >>> association, you can pretty easily ignore it. It might be nice >>> to have per-association on/off of some events. But I am mixed >>> on how useful that is. >>> >>> I do agree with Kacheong here though, if we have to go this route we >>> need a new structure.. i.e. one that includes an assoc id.. and then >>> do the thing that says if the assoc-id=3D=3D0 its to future = associations >>> or the entire socket... vs just changing a single association. I =20 >>> would >>> also think we want to make it more extensible and as Kacheong said >>> just retire the old SCTP_EVENTS... i.e. support for backward =20 >>> compatibility >>> but move to the new structure for future things.. >>> >>> But again, is this really worth it? I am not convinced it is yet.. >> There are two points here specific to the DRY event: >> >> 1. Performance: I might be interested only in the events for one >> particular association, but I get them for all. Of course I >> can ignore them for all associations I'm not interested in, >> but this means the kernel is going to generate a lot of =20 >> notifications >> I'm not interested in. This is just waisted cycles and mbufs. >> >> 2. The DRY event is generated when it is enabled and the the =20 >> association >> is dry. So assume I have N associations (being dry), I'm interested >> in one. Now I enable it. The kernel has to generate N notifications >> instantly. This might be a resource problem (on Mac OS X I ran into >> it), because you need N mbufs at about the same time. There is also >> no "flow control" for notifications. >> That is why I implemented this currently only for 1-to-1 style =20 >> sockets. >> >> But I think we should be more future proof here. >> I like Kacheongs idea to use the assoc_value structs: >> 1. This allows it to control it on an association base. No limitation >> here. >> 2. It can be used with any future notification. It is just adding a >> new constant, not changing a structure which might break ABI =20 >> compatibility. >> 3. It is simple. >> >> I think we should add this. > > > Michael so what you are proposing is that we: > > 1) Keep the existing SCTP_EVENT's socket call. The socket option is called SCTP_EVENTS. I suggest to keep it. > > > > 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a > sctp_assoc_value structure. Where the assoc-id is the > assoc you want the notification on. And the value is the > Notification id. We would type all current notifications > with constants e.g. SCTP_DRY_NOTIFICATION What about SCTP_EVENT (no S, so singular)? This would use struct sctp_assoc_value. > > > 3) I think we would want 0 to be again, future associations > and non-zero to be specific associations. Correct. And ignore for 1-to-1 style sockets. > > > > Now this would also mean that the existing SCTP_EVENT's would have > a slight change, which I think is ok. It would now be a short cut Why do you want to change that? I would suggest to keep it at it is. > > equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with > the assoc-id set to 0. I.e. it would ONLY effect future assoc's. > > This is a subtle difference but one we should document well. I think > its ok, since most folks using the SCTP_EVENT's do not change > things in the middle. They basically open a socket, set the events > they may want... and then never touch it again. > > I do agree this would then add a nice extensible mechanism to add > future events as well. > > As long as Kacheong and Vlad are ok with this I am too... I can see > it will at least be useful for the sender-dry-event. Not sure about > other ones but you never know. > > Kacheong, Vlad, -- thoughts.. if you agree I will start making > changes in BSD and the ID.. > > R > > ----- > Randall Stewart > randall@lakerest.net > > > > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C86B28C14B for ; Wed, 25 Feb 2009 04:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLHXo2IjhQz9 for ; Wed, 25 Feb 2009 04:02:11 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 39EBF3A6AB7 for ; Wed, 25 Feb 2009 04:02:09 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1PC2Y6n044686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 07:02:35 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <153C9FB2-39DD-4CC8-92F6-21E6B71DD025@lakerest.net> From: Randy Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <0C01E701-380F-4976-9BDF-A168B3859B49@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 07:02:24 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <0C01E701-380F-4976-9BDF-A168B3859B49@lurchi.franken.de> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:02:12 -0000 On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote: > On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote: > >> >> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >> >>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>> >>>> >>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>> >>>>> Michael T=FCxen wrote: >>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>> ... >>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>> scenario where >>>>>>> an application decides to change event subscription of an =20 >>>>>>> association after >>>>>>> it's established? I can't see a reason right now, but that =20 >>>>>>> doesn't mean it >>>>>>> doesn't exist. >>>>>> We do this for the DRY event since we are only interested in it >>>>>> during some specific states in DTLS (during renegotiations). >>>>> >>>>> >>>>> If we want to explore this, I'd suggest we retire (just keep >>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>> subscribe/unsubscribe each event one by one. >>>>> >>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>> enabled for all associations controlled by one socket all the >>>>> time. >>>>> >>>> >>>> Hmm so let me summarize what I think we have agreed to so far >>>> >>>> 1) We will add support for using the sctp_assoc_value structure >>>> to turn on/off EEOR mode on a per assoc basis. >>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>> (1-2many or 1-1) is >>>> set to EEOR mode this includes future and all existing sockets. >>>> >>>> >>>> On the events... I am not convinced a per-assoc subscription is >>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20 >>>> many >>>> socket .. you know if you are sending and can turn it off as soon >>>> as the dry-event occurs. If you get a dry event on another >>>> association, you can pretty easily ignore it. It might be nice >>>> to have per-association on/off of some events. But I am mixed >>>> on how useful that is. >>>> >>>> I do agree with Kacheong here though, if we have to go this route =20= >>>> we >>>> need a new structure.. i.e. one that includes an assoc id.. and =20 >>>> then >>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>> associations >>>> or the entire socket... vs just changing a single association. I =20= >>>> would >>>> also think we want to make it more extensible and as Kacheong said >>>> just retire the old SCTP_EVENTS... i.e. support for backward =20 >>>> compatibility >>>> but move to the new structure for future things.. >>>> >>>> But again, is this really worth it? I am not convinced it is yet.. >>> There are two points here specific to the DRY event: >>> >>> 1. Performance: I might be interested only in the events for one >>> particular association, but I get them for all. Of course I >>> can ignore them for all associations I'm not interested in, >>> but this means the kernel is going to generate a lot of =20 >>> notifications >>> I'm not interested in. This is just waisted cycles and mbufs. >>> >>> 2. The DRY event is generated when it is enabled and the the =20 >>> association >>> is dry. So assume I have N associations (being dry), I'm interested >>> in one. Now I enable it. The kernel has to generate N notifications >>> instantly. This might be a resource problem (on Mac OS X I ran into >>> it), because you need N mbufs at about the same time. There is also >>> no "flow control" for notifications. >>> That is why I implemented this currently only for 1-to-1 style =20 >>> sockets. >>> >>> But I think we should be more future proof here. >>> I like Kacheongs idea to use the assoc_value structs: >>> 1. This allows it to control it on an association base. No =20 >>> limitation >>> here. >>> 2. It can be used with any future notification. It is just adding a >>> new constant, not changing a structure which might break ABI =20 >>> compatibility. >>> 3. It is simple. >>> >>> I think we should add this. >> >> >> Michael so what you are proposing is that we: >> >> 1) Keep the existing SCTP_EVENT's socket call. > The socket option is called SCTP_EVENTS. I suggest to keep it. Opps.. you are right so I did not go look at the header file :-) > >> >> >> >> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >> sctp_assoc_value structure. Where the assoc-id is the >> assoc you want the notification on. And the value is the >> Notification id. We would type all current notifications >> with constants e.g. SCTP_DRY_NOTIFICATION > What about SCTP_EVENT (no S, so singular)? This would use > struct sctp_assoc_value. Thats fine with me.. > >> >> >> 3) I think we would want 0 to be again, future associations >> and non-zero to be specific associations. > Correct. And ignore for 1-to-1 style sockets. Not if you are a listener.. A listening 1-on-1 socket would be setting up for its future "accepted" associations. > >> >> >> >> Now this would also mean that the existing SCTP_EVENT's would have >> a slight change, which I think is ok. It would now be a short cut > Why do you want to change that? I would suggest to keep it at it is. I guess we could.. but it will really be the first socket option that digs through a 1-M socket and grabs each assoc and applies some settings. Which in my mind kinda makes it inconsistent. The current events are set socket wide.. so at an implementation level we are discussing moving the events onto the actual "assoc structure" not the "socket level structure". Which in my mind changes the semantics of the way the thing is manipulated. Inside the API we have been pretty consistent. If its a over-reaching socket level thing it of course effects everything when you change it. However if its something ON an association changes at the socket level effect future associations vs changes on a specific assoc... This concerns me somewhat.. but I guess for compatibility reasons it would be ok... But honestly other than this new sender-dry event of yours most everyone I have ever taught the API too or worked with on it sets up the SCTP_EVENTS once and only once.. and then never touches it again. R > >> >> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >> >> This is a subtle difference but one we should document well. I think >> its ok, since most folks using the SCTP_EVENT's do not change >> things in the middle. They basically open a socket, set the events >> they may want... and then never touch it again. >> >> I do agree this would then add a nice extensible mechanism to add >> future events as well. >> >> As long as Kacheong and Vlad are ok with this I am too... I can see >> it will at least be useful for the sender-dry-event. Not sure about >> other ones but you never know. >> >> Kacheong, Vlad, -- thoughts.. if you agree I will start making >> changes in BSD and the ID.. >> >> R >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> >> > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF043A6AA4 for ; Wed, 25 Feb 2009 05:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.836 X-Spam-Level: ** X-Spam-Status: No, score=2.836 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RIBVecqkh4R for ; Wed, 25 Feb 2009 05:31:47 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 50F1F3A67D6 for ; Wed, 25 Feb 2009 05:31:46 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id EF8EE1C0E9633; Wed, 25 Feb 2009 14:32:02 +0100 (CET) Message-Id: <58E7CE04-4E30-4AFA-97E9-56B915559630@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Randy Stewart In-Reply-To: <153C9FB2-39DD-4CC8-92F6-21E6B71DD025@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 14:32:01 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <0C01E701-380F-4976-9BDF-A168B3859B49@lurchi.franken.de> <153C9FB2-39DD-4CC8-92F6-21E6B71DD025@lakerest.net> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:31:48 -0000 On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote: > > On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote: > >> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote: >> >>> >>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >>> >>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>>> >>>>> >>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>>> >>>>>> Michael T=FCxen wrote: >>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>>> ... >>>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>>> scenario where >>>>>>>> an application decides to change event subscription of an =20 >>>>>>>> association after >>>>>>>> it's established? I can't see a reason right now, but that =20 >>>>>>>> doesn't mean it >>>>>>>> doesn't exist. >>>>>>> We do this for the DRY event since we are only interested in it >>>>>>> during some specific states in DTLS (during renegotiations). >>>>>> >>>>>> >>>>>> If we want to explore this, I'd suggest we retire (just keep >>>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>>> subscribe/unsubscribe each event one by one. >>>>>> >>>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>>> enabled for all associations controlled by one socket all the >>>>>> time. >>>>>> >>>>> >>>>> Hmm so let me summarize what I think we have agreed to so far >>>>> >>>>> 1) We will add support for using the sctp_assoc_value structure >>>>> to turn on/off EEOR mode on a per assoc basis. >>>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>>> (1-2many or 1-1) is >>>>> set to EEOR mode this includes future and all existing sockets. >>>>> >>>>> >>>>> On the events... I am not convinced a per-assoc subscription is >>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20= >>>>> many >>>>> socket .. you know if you are sending and can turn it off as soon >>>>> as the dry-event occurs. If you get a dry event on another >>>>> association, you can pretty easily ignore it. It might be nice >>>>> to have per-association on/off of some events. But I am mixed >>>>> on how useful that is. >>>>> >>>>> I do agree with Kacheong here though, if we have to go this =20 >>>>> route we >>>>> need a new structure.. i.e. one that includes an assoc id.. and =20= >>>>> then >>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>>> associations >>>>> or the entire socket... vs just changing a single association. I =20= >>>>> would >>>>> also think we want to make it more extensible and as Kacheong said >>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20 >>>>> compatibility >>>>> but move to the new structure for future things.. >>>>> >>>>> But again, is this really worth it? I am not convinced it is yet.. >>>> There are two points here specific to the DRY event: >>>> >>>> 1. Performance: I might be interested only in the events for one >>>> particular association, but I get them for all. Of course I >>>> can ignore them for all associations I'm not interested in, >>>> but this means the kernel is going to generate a lot of =20 >>>> notifications >>>> I'm not interested in. This is just waisted cycles and mbufs. >>>> >>>> 2. The DRY event is generated when it is enabled and the the =20 >>>> association >>>> is dry. So assume I have N associations (being dry), I'm =20 >>>> interested >>>> in one. Now I enable it. The kernel has to generate N notifications >>>> instantly. This might be a resource problem (on Mac OS X I ran into >>>> it), because you need N mbufs at about the same time. There is also >>>> no "flow control" for notifications. >>>> That is why I implemented this currently only for 1-to-1 style =20 >>>> sockets. >>>> >>>> But I think we should be more future proof here. >>>> I like Kacheongs idea to use the assoc_value structs: >>>> 1. This allows it to control it on an association base. No =20 >>>> limitation >>>> here. >>>> 2. It can be used with any future notification. It is just adding a >>>> new constant, not changing a structure which might break ABI =20 >>>> compatibility. >>>> 3. It is simple. >>>> >>>> I think we should add this. >>> >>> >>> Michael so what you are proposing is that we: >>> >>> 1) Keep the existing SCTP_EVENT's socket call. >> The socket option is called SCTP_EVENTS. I suggest to keep it. > > Opps.. you are right so I did not go look at the header file :-) > >> >>> >>> >>> >>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>> sctp_assoc_value structure. Where the assoc-id is the >>> assoc you want the notification on. And the value is the >>> Notification id. We would type all current notifications >>> with constants e.g. SCTP_DRY_NOTIFICATION >> What about SCTP_EVENT (no S, so singular)? This would use >> struct sctp_assoc_value. > > Thats fine with me.. > >> >>> >>> >>> 3) I think we would want 0 to be again, future associations >>> and non-zero to be specific associations. >> Correct. And ignore for 1-to-1 style sockets. > > Not if you are a listener.. A listening 1-on-1 socket would > be setting up for its future "accepted" associations. I meant: Ignore the association ID on the 1-to-1 style sockets. On a listener, it is for future association, on a non listener, it is for the specific one belonging to the socket. > > >> >>> >>> >>> >>> Now this would also mean that the existing SCTP_EVENT's would have >>> a slight change, which I think is ok. It would now be a short cut >> Why do you want to change that? I would suggest to keep it at it is. > > I guess we could.. but it will really be the first socket > option that digs through a 1-M socket and grabs each > assoc and applies some settings. Which in my mind kinda makes > it inconsistent. > > The current events are set socket wide.. so at an implementation > level we are discussing moving the events onto the actual > "assoc structure" not the "socket level structure". Which in my > mind changes the semantics of the way the thing is manipulated. I see what you mean... However, this means that some applications might break since we are changing the semantics. But I think it is worth the price. Anyway: I think the best would be anyway to put a note in the text that people should use the new API (SCTP_EVENT) instead of the old one (SCTP_EVENTS). This way they can better use additional features (Stream Reset comes to my mind...) > > > Inside the API we have been pretty consistent. If its a over-reaching > socket level thing it of course effects everything when you change > it. However if its something ON an association changes at > the socket level effect future associations vs changes on a specific > assoc... > > This concerns me somewhat.. but I guess for compatibility reasons it > would be ok... > > But honestly other than this new sender-dry event of yours most =20 > everyone > I have ever taught the API too or worked with on it sets up the > SCTP_EVENTS once and only once.. and then never touches it again. I vote for changing the semantic! > > > R > >> >>> >>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >>> >>> This is a subtle difference but one we should document well. I think >>> its ok, since most folks using the SCTP_EVENT's do not change >>> things in the middle. They basically open a socket, set the events >>> they may want... and then never touch it again. >>> >>> I do agree this would then add a nice extensible mechanism to add >>> future events as well. >>> >>> As long as Kacheong and Vlad are ok with this I am too... I can see >>> it will at least be useful for the sender-dry-event. Not sure about >>> other ones but you never know. >>> >>> Kacheong, Vlad, -- thoughts.. if you agree I will start making >>> changes in BSD and the ID.. >>> >>> R >>> >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>> >>> >>> >>> >>> >> > > ----- > Randall Stewart > randall@lakerest.net > > > > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596603A686D for ; Wed, 25 Feb 2009 06:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI40CDSY51Ih for ; Wed, 25 Feb 2009 06:42:46 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 4B1C93A6841 for ; Wed, 25 Feb 2009 06:42:44 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1PEh7M7051088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 09:43:07 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: <848D92E4-1EB2-4B90-BF96-173035D73365@lakerest.net> From: Randy Stewart To: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <58E7CE04-4E30-4AFA-97E9-56B915559630@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 09:42:57 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <0C01E701-380F-4976-9BDF-A168B3859B49@lurchi.franken.de> <153C9FB2-39DD-4CC8-92F6-21E6B71DD025@lakerest.net> <58E7CE04-4E30-4AFA-97E9-56B915559630@lurchi.franken.de> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 14:42:47 -0000 I will go with whatever one else wants... I really don't have much of an opinion.. the SCTP_EVENT is fine and to the semantic changes... I will listen to whatever Kacheong says on this.. since of all the co-authors I think he is closest to being the semantic police :-) R On Feb 25, 2009, at 8:32 AM, Michael T=FCxen wrote: > > On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote: > >> >> On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote: >> >>> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote: >>> >>>> >>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >>>> >>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>>>> >>>>>> >>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>>>> >>>>>>> Michael T=FCxen wrote: >>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>>>> ... >>>>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>>>> scenario where >>>>>>>>> an application decides to change event subscription of an =20 >>>>>>>>> association after >>>>>>>>> it's established? I can't see a reason right now, but that =20= >>>>>>>>> doesn't mean it >>>>>>>>> doesn't exist. >>>>>>>> We do this for the DRY event since we are only interested in it >>>>>>>> during some specific states in DTLS (during renegotiations). >>>>>>> >>>>>>> >>>>>>> If we want to explore this, I'd suggest we retire (just keep >>>>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>>>> subscribe/unsubscribe each event one by one. >>>>>>> >>>>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>>>> enabled for all associations controlled by one socket all the >>>>>>> time. >>>>>>> >>>>>> >>>>>> Hmm so let me summarize what I think we have agreed to so far >>>>>> >>>>>> 1) We will add support for using the sctp_assoc_value structure >>>>>> to turn on/off EEOR mode on a per assoc basis. >>>>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>>>> (1-2many or 1-1) is >>>>>> set to EEOR mode this includes future and all existing sockets. >>>>>> >>>>>> >>>>>> On the events... I am not convinced a per-assoc subscription is >>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20= >>>>>> many >>>>>> socket .. you know if you are sending and can turn it off as soon >>>>>> as the dry-event occurs. If you get a dry event on another >>>>>> association, you can pretty easily ignore it. It might be nice >>>>>> to have per-association on/off of some events. But I am mixed >>>>>> on how useful that is. >>>>>> >>>>>> I do agree with Kacheong here though, if we have to go this =20 >>>>>> route we >>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20= >>>>>> then >>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>>>> associations >>>>>> or the entire socket... vs just changing a single association. =20= >>>>>> I would >>>>>> also think we want to make it more extensible and as Kacheong =20 >>>>>> said >>>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20 >>>>>> compatibility >>>>>> but move to the new structure for future things.. >>>>>> >>>>>> But again, is this really worth it? I am not convinced it is =20 >>>>>> yet.. >>>>> There are two points here specific to the DRY event: >>>>> >>>>> 1. Performance: I might be interested only in the events for one >>>>> particular association, but I get them for all. Of course I >>>>> can ignore them for all associations I'm not interested in, >>>>> but this means the kernel is going to generate a lot of =20 >>>>> notifications >>>>> I'm not interested in. This is just waisted cycles and mbufs. >>>>> >>>>> 2. The DRY event is generated when it is enabled and the the =20 >>>>> association >>>>> is dry. So assume I have N associations (being dry), I'm =20 >>>>> interested >>>>> in one. Now I enable it. The kernel has to generate N =20 >>>>> notifications >>>>> instantly. This might be a resource problem (on Mac OS X I ran =20 >>>>> into >>>>> it), because you need N mbufs at about the same time. There is =20 >>>>> also >>>>> no "flow control" for notifications. >>>>> That is why I implemented this currently only for 1-to-1 style =20 >>>>> sockets. >>>>> >>>>> But I think we should be more future proof here. >>>>> I like Kacheongs idea to use the assoc_value structs: >>>>> 1. This allows it to control it on an association base. No =20 >>>>> limitation >>>>> here. >>>>> 2. It can be used with any future notification. It is just =20 >>>>> adding a >>>>> new constant, not changing a structure which might break ABI =20 >>>>> compatibility. >>>>> 3. It is simple. >>>>> >>>>> I think we should add this. >>>> >>>> >>>> Michael so what you are proposing is that we: >>>> >>>> 1) Keep the existing SCTP_EVENT's socket call. >>> The socket option is called SCTP_EVENTS. I suggest to keep it. >> >> Opps.. you are right so I did not go look at the header file :-) >> >>> >>>> >>>> >>>> >>>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>>> sctp_assoc_value structure. Where the assoc-id is the >>>> assoc you want the notification on. And the value is the >>>> Notification id. We would type all current notifications >>>> with constants e.g. SCTP_DRY_NOTIFICATION >>> What about SCTP_EVENT (no S, so singular)? This would use >>> struct sctp_assoc_value. >> >> Thats fine with me.. >> >>> >>>> >>>> >>>> 3) I think we would want 0 to be again, future associations >>>> and non-zero to be specific associations. >>> Correct. And ignore for 1-to-1 style sockets. >> >> Not if you are a listener.. A listening 1-on-1 socket would >> be setting up for its future "accepted" associations. > I meant: Ignore the association ID on the 1-to-1 style sockets. > On a listener, it is for future association, on a non listener, > it is for the specific one belonging to the socket. >> >> >>> >>>> >>>> >>>> >>>> Now this would also mean that the existing SCTP_EVENT's would have >>>> a slight change, which I think is ok. It would now be a short cut >>> Why do you want to change that? I would suggest to keep it at it is. >> >> I guess we could.. but it will really be the first socket >> option that digs through a 1-M socket and grabs each >> assoc and applies some settings. Which in my mind kinda makes >> it inconsistent. >> >> The current events are set socket wide.. so at an implementation >> level we are discussing moving the events onto the actual >> "assoc structure" not the "socket level structure". Which in my >> mind changes the semantics of the way the thing is manipulated. > I see what you mean... However, this means that some applications > might break since we are changing the semantics. But I think > it is worth the price. > > Anyway: I think the best would be anyway to put a note in the > text that people should use the new API (SCTP_EVENT) instead > of the old one (SCTP_EVENTS). This way they can better use > additional features (Stream Reset comes to my mind...) >> >> >> Inside the API we have been pretty consistent. If its a over-reaching >> socket level thing it of course effects everything when you change >> it. However if its something ON an association changes at >> the socket level effect future associations vs changes on a specific >> assoc... >> >> This concerns me somewhat.. but I guess for compatibility reasons it >> would be ok... >> >> But honestly other than this new sender-dry event of yours most =20 >> everyone >> I have ever taught the API too or worked with on it sets up the >> SCTP_EVENTS once and only once.. and then never touches it again. > I vote for changing the semantic! >> >> >> R >> >>> >>>> >>>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >>>> >>>> This is a subtle difference but one we should document well. I =20 >>>> think >>>> its ok, since most folks using the SCTP_EVENT's do not change >>>> things in the middle. They basically open a socket, set the events >>>> they may want... and then never touch it again. >>>> >>>> I do agree this would then add a nice extensible mechanism to add >>>> future events as well. >>>> >>>> As long as Kacheong and Vlad are ok with this I am too... I can see >>>> it will at least be useful for the sender-dry-event. Not sure about >>>> other ones but you never know. >>>> >>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making >>>> changes in BSD and the ID.. >>>> >>>> R >>>> >>>> ----- >>>> Randall Stewart >>>> randall@lakerest.net >>>> >>>> >>>> >>>> >>>> >>> >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> >> > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B343A6ACA for ; Wed, 25 Feb 2009 06:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.22 X-Spam-Level: X-Spam-Status: No, score=-105.22 tagged_above=-999 required=5 tests=[AWL=1.379, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asOb6SQ+HkL2 for ; Wed, 25 Feb 2009 06:42:47 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id C99B03A6841 for ; Wed, 25 Feb 2009 06:42:47 -0800 (PST) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 94408384B1; Wed, 25 Feb 2009 14:43:07 +0000 (UTC) Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id B8B1610005; Wed, 25 Feb 2009 14:43:06 +0000 (UTC) Message-ID: <49A558F9.9040700@hp.com> Date: Wed, 25 Feb 2009 09:43:05 -0500 From: Vlad Yasevich User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Randy Stewart References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> In-Reply-To: <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 14:42:49 -0000 Randy Stewart wrote: > > On Feb 25, 2009, at 4:35 AM, Michael Tüxen wrote: > >> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >> >>> >>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>> >>>> Michael Tüxen wrote: >>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>> ... >>>>>> Hmm.. That's an interesting question. Is it a possible scenario >>>>>> where >>>>>> an application decides to change event subscription of an >>>>>> association after >>>>>> it's established? I can't see a reason right now, but that >>>>>> doesn't mean it >>>>>> doesn't exist. >>>>> We do this for the DRY event since we are only interested in it >>>>> during some specific states in DTLS (during renegotiations). >>>> >>>> >>>> If we want to explore this, I'd suggest we retire (just keep >>>> it there for backward compatibility) the sctp_event_subscribe. >>>> It is not extensible. Just use sctp_assoc_value. An app can >>>> subscribe/unsubscribe each event one by one. >>>> >>>> BTW, I guess it should not cause a problem if the DRY event is >>>> enabled for all associations controlled by one socket all the >>>> time. >>>> >>> >>> Hmm so let me summarize what I think we have agreed to so far >>> >>> 1) We will add support for using the sctp_assoc_value structure >>> to turn on/off EEOR mode on a per assoc basis. >>> 2) If the value of the assoc is 0, then the entire socket (1-2many or >>> 1-1) is >>> set to EEOR mode this includes future and all existing sockets. >>> >>> >>> On the events... I am not convinced a per-assoc subscription is >>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many >>> socket .. you know if you are sending and can turn it off as soon >>> as the dry-event occurs. If you get a dry event on another >>> association, you can pretty easily ignore it. It might be nice >>> to have per-association on/off of some events. But I am mixed >>> on how useful that is. >>> >>> I do agree with Kacheong here though, if we have to go this route we >>> need a new structure.. i.e. one that includes an assoc id.. and then >>> do the thing that says if the assoc-id==0 its to future associations >>> or the entire socket... vs just changing a single association. I would >>> also think we want to make it more extensible and as Kacheong said >>> just retire the old SCTP_EVENTS... i.e. support for backward >>> compatibility >>> but move to the new structure for future things.. >>> >>> But again, is this really worth it? I am not convinced it is yet.. >> There are two points here specific to the DRY event: >> >> 1. Performance: I might be interested only in the events for one >> particular association, but I get them for all. Of course I >> can ignore them for all associations I'm not interested in, >> but this means the kernel is going to generate a lot of notifications >> I'm not interested in. This is just waisted cycles and mbufs. >> >> 2. The DRY event is generated when it is enabled and the the association >> is dry. So assume I have N associations (being dry), I'm interested >> in one. Now I enable it. The kernel has to generate N notifications >> instantly. This might be a resource problem (on Mac OS X I ran into >> it), because you need N mbufs at about the same time. There is also >> no "flow control" for notifications. >> That is why I implemented this currently only for 1-to-1 style sockets. >> >> But I think we should be more future proof here. >> I like Kacheongs idea to use the assoc_value structs: >> 1. This allows it to control it on an association base. No limitation >> here. >> 2. It can be used with any future notification. It is just adding a >> new constant, not changing a structure which might break ABI >> compatibility. >> 3. It is simple. >> >> I think we should add this. > > > Michael so what you are proposing is that we: > > 1) Keep the existing SCTP_EVENT's socket call. > > 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a > sctp_assoc_value structure. Where the assoc-id is the > assoc you want the notification on. And the value is the > Notification id. We would type all current notifications > with constants e.g. SCTP_DRY_NOTIFICATION So, this option could only be used to turn something on, not turn it off? Seems one-sided. :) > > 3) I think we would want 0 to be again, future associations > and non-zero to be specific associations. > > > Now this would also mean that the existing SCTP_EVENT's would have > a slight change, which I think is ok. It would now be a short cut > equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with > the assoc-id set to 0. I.e. it would ONLY effect future assoc's. > > This is a subtle difference but one we should document well. I think > its ok, since most folks using the SCTP_EVENT's do not change > things in the middle. They basically open a socket, set the events > they may want... and then never touch it again. > > I do agree this would then add a nice extensible mechanism to add > future events as well. > Yes, this is something that would be good to have. It also gives applications a very fine control over what they can request and that's generally a good thing. -vlad > As long as Kacheong and Vlad are ok with this I am too... I can see > it will at least be useful for the sender-dry-event. Not sure about > other ones but you never know. > > Kacheong, Vlad, -- thoughts.. if you agree I will start making > changes in BSD and the ID.. > > R > > ----- > Randall Stewart > randall@lakerest.net > > > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0EB3A6963 for ; Wed, 25 Feb 2009 07:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqiFzc78ffqA for ; Wed, 25 Feb 2009 07:09:23 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 780653A68E4 for ; Wed, 25 Feb 2009 07:09:22 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n1PF9mTe052095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 10:09:48 -0500 (EST) (envelope-from randall@lakerest.net) Message-Id: From: Randy Stewart To: Vlad Yasevich In-Reply-To: <49A558F9.9040700@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 10:09:38 -0500 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A558F9.9040700@hp.com> X-Mailer: Apple Mail (2.930.3) Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:09:24 -0000 On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote: > Randy Stewart wrote: >> >> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >> >>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>> >>>> >>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>> >>>>> Michael T=FCxen wrote: >>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>> ... >>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>> scenario >>>>>>> where >>>>>>> an application decides to change event subscription of an >>>>>>> association after >>>>>>> it's established? I can't see a reason right now, but that >>>>>>> doesn't mean it >>>>>>> doesn't exist. >>>>>> We do this for the DRY event since we are only interested in it >>>>>> during some specific states in DTLS (during renegotiations). >>>>> >>>>> >>>>> If we want to explore this, I'd suggest we retire (just keep >>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>> subscribe/unsubscribe each event one by one. >>>>> >>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>> enabled for all associations controlled by one socket all the >>>>> time. >>>>> >>>> >>>> Hmm so let me summarize what I think we have agreed to so far >>>> >>>> 1) We will add support for using the sctp_assoc_value structure >>>> to turn on/off EEOR mode on a per assoc basis. >>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>> (1-2many or >>>> 1-1) is >>>> set to EEOR mode this includes future and all existing sockets. >>>> >>>> >>>> On the events... I am not convinced a per-assoc subscription is >>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20 >>>> many >>>> socket .. you know if you are sending and can turn it off as soon >>>> as the dry-event occurs. If you get a dry event on another >>>> association, you can pretty easily ignore it. It might be nice >>>> to have per-association on/off of some events. But I am mixed >>>> on how useful that is. >>>> >>>> I do agree with Kacheong here though, if we have to go this route =20= >>>> we >>>> need a new structure.. i.e. one that includes an assoc id.. and =20 >>>> then >>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>> associations >>>> or the entire socket... vs just changing a single association. I =20= >>>> would >>>> also think we want to make it more extensible and as Kacheong said >>>> just retire the old SCTP_EVENTS... i.e. support for backward >>>> compatibility >>>> but move to the new structure for future things.. >>>> >>>> But again, is this really worth it? I am not convinced it is yet.. >>> There are two points here specific to the DRY event: >>> >>> 1. Performance: I might be interested only in the events for one >>> particular association, but I get them for all. Of course I >>> can ignore them for all associations I'm not interested in, >>> but this means the kernel is going to generate a lot of =20 >>> notifications >>> I'm not interested in. This is just waisted cycles and mbufs. >>> >>> 2. The DRY event is generated when it is enabled and the the =20 >>> association >>> is dry. So assume I have N associations (being dry), I'm =20 >>> interested >>> in one. Now I enable it. The kernel has to generate N notifications >>> instantly. This might be a resource problem (on Mac OS X I ran into >>> it), because you need N mbufs at about the same time. There is also >>> no "flow control" for notifications. >>> That is why I implemented this currently only for 1-to-1 style =20 >>> sockets. >>> >>> But I think we should be more future proof here. >>> I like Kacheongs idea to use the assoc_value structs: >>> 1. This allows it to control it on an association base. No =20 >>> limitation >>> here. >>> 2. It can be used with any future notification. It is just adding a >>> new constant, not changing a structure which might break ABI >>> compatibility. >>> 3. It is simple. >>> >>> I think we should add this. >> >> >> Michael so what you are proposing is that we: >> >> 1) Keep the existing SCTP_EVENT's socket call. >> >> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >> sctp_assoc_value structure. Where the assoc-id is the >> assoc you want the notification on. And the value is the >> Notification id. We would type all current notifications >> with constants e.g. SCTP_DRY_NOTIFICATION > > So, this option could only be used to turn something on, not turn > it off? Seems one-sided. :) Hmm.. yeah you are right here. You would have to define two contants I guess.. SCTP_DRY_NOTIFICATION_ON SCTP_DRY_NOTIFICATION_OFF Since its a 32 bit number space in the value it would probably be =20 extensible enough (2 billion possibilities) :-) > > >> >> 3) I think we would want 0 to be again, future associations >> and non-zero to be specific associations. >> >> >> Now this would also mean that the existing SCTP_EVENT's would have >> a slight change, which I think is ok. It would now be a short cut >> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >> >> This is a subtle difference but one we should document well. I think >> its ok, since most folks using the SCTP_EVENT's do not change >> things in the middle. They basically open a socket, set the events >> they may want... and then never touch it again. >> >> I do agree this would then add a nice extensible mechanism to add >> future events as well. >> > > Yes, this is something that would be good to have. It also gives > applications a very fine control over what they can request and that's > generally a good thing. True R > > > -vlad > >> As long as Kacheong and Vlad are ok with this I am too... I can see >> it will at least be useful for the sender-dry-event. Not sure about >> other ones but you never know. >> >> Kacheong, Vlad, -- thoughts.. if you agree I will start making >> changes in BSD and the ID.. >> >> R >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> > ----- Randall Stewart randall@lakerest.net Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55FF3A6870 for ; Wed, 25 Feb 2009 07:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.697 X-Spam-Level: **** X-Spam-Status: No, score=4.697 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, FRT_STOCK2=3.988, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFUBBm0ZZYtE for ; Wed, 25 Feb 2009 07:18:45 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9114C3A686D for ; Wed, 25 Feb 2009 07:18:44 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 723481C0E9633; Wed, 25 Feb 2009 16:19:02 +0100 (CET) Message-Id: <097F6D7A-FAD2-47F4-AB01-872DA0F8D8A5@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Vlad Yasevich In-Reply-To: <49A558F9.9040700@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 16:19:01 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A558F9.9040700@hp.com> X-Mailer: Apple Mail (2.930.3) Cc: Kacheong Poon , tsvwg , Randy Stewart Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:18:46 -0000 On Feb 25, 2009, at 3:43 PM, Vlad Yasevich wrote: > Randy Stewart wrote: >> >> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >> >>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>> >>>> >>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>> >>>>> Michael T=FCxen wrote: >>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>> ... >>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>> scenario >>>>>>> where >>>>>>> an application decides to change event subscription of an >>>>>>> association after >>>>>>> it's established? I can't see a reason right now, but that >>>>>>> doesn't mean it >>>>>>> doesn't exist. >>>>>> We do this for the DRY event since we are only interested in it >>>>>> during some specific states in DTLS (during renegotiations). >>>>> >>>>> >>>>> If we want to explore this, I'd suggest we retire (just keep >>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>> subscribe/unsubscribe each event one by one. >>>>> >>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>> enabled for all associations controlled by one socket all the >>>>> time. >>>>> >>>> >>>> Hmm so let me summarize what I think we have agreed to so far >>>> >>>> 1) We will add support for using the sctp_assoc_value structure >>>> to turn on/off EEOR mode on a per assoc basis. >>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>> (1-2many or >>>> 1-1) is >>>> set to EEOR mode this includes future and all existing sockets. >>>> >>>> >>>> On the events... I am not convinced a per-assoc subscription is >>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20 >>>> many >>>> socket .. you know if you are sending and can turn it off as soon >>>> as the dry-event occurs. If you get a dry event on another >>>> association, you can pretty easily ignore it. It might be nice >>>> to have per-association on/off of some events. But I am mixed >>>> on how useful that is. >>>> >>>> I do agree with Kacheong here though, if we have to go this route =20= >>>> we >>>> need a new structure.. i.e. one that includes an assoc id.. and =20 >>>> then >>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>> associations >>>> or the entire socket... vs just changing a single association. I =20= >>>> would >>>> also think we want to make it more extensible and as Kacheong said >>>> just retire the old SCTP_EVENTS... i.e. support for backward >>>> compatibility >>>> but move to the new structure for future things.. >>>> >>>> But again, is this really worth it? I am not convinced it is yet.. >>> There are two points here specific to the DRY event: >>> >>> 1. Performance: I might be interested only in the events for one >>> particular association, but I get them for all. Of course I >>> can ignore them for all associations I'm not interested in, >>> but this means the kernel is going to generate a lot of =20 >>> notifications >>> I'm not interested in. This is just waisted cycles and mbufs. >>> >>> 2. The DRY event is generated when it is enabled and the the =20 >>> association >>> is dry. So assume I have N associations (being dry), I'm =20 >>> interested >>> in one. Now I enable it. The kernel has to generate N notifications >>> instantly. This might be a resource problem (on Mac OS X I ran into >>> it), because you need N mbufs at about the same time. There is also >>> no "flow control" for notifications. >>> That is why I implemented this currently only for 1-to-1 style =20 >>> sockets. >>> >>> But I think we should be more future proof here. >>> I like Kacheongs idea to use the assoc_value structs: >>> 1. This allows it to control it on an association base. No =20 >>> limitation >>> here. >>> 2. It can be used with any future notification. It is just adding a >>> new constant, not changing a structure which might break ABI >>> compatibility. >>> 3. It is simple. >>> >>> I think we should add this. >> >> >> Michael so what you are proposing is that we: >> >> 1) Keep the existing SCTP_EVENT's socket call. >> >> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >> sctp_assoc_value structure. Where the assoc-id is the >> assoc you want the notification on. And the value is the >> Notification id. We would type all current notifications >> with constants e.g. SCTP_DRY_NOTIFICATION > > So, this option could only be used to turn something on, not turn > it off? Seems one-sided. :) Good point. So I think we need something like struct sctp_event { sctp_assoc_t assoc_id; uint32_t event; uint8_t enable; } Using enable!=3D0, you can enable it, using enable=3D0, you can disable = it =20 when you use setsockopt(). For getsockopt(), you provie the assoc_id and the event and get back =20 whether it is enabled or not. > > >> >> 3) I think we would want 0 to be again, future associations >> and non-zero to be specific associations. >> >> >> Now this would also mean that the existing SCTP_EVENT's would have >> a slight change, which I think is ok. It would now be a short cut >> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >> >> This is a subtle difference but one we should document well. I think >> its ok, since most folks using the SCTP_EVENT's do not change >> things in the middle. They basically open a socket, set the events >> they may want... and then never touch it again. >> >> I do agree this would then add a nice extensible mechanism to add >> future events as well. >> > > Yes, this is something that would be good to have. It also gives > applications a very fine control over what they can request and that's > generally a good thing. > > -vlad > >> As long as Kacheong and Vlad are ok with this I am too... I can see >> it will at least be useful for the sender-dry-event. Not sure about >> other ones but you never know. >> >> Kacheong, Vlad, -- thoughts.. if you agree I will start making >> changes in BSD and the ID.. >> >> R >> >> ----- >> Randall Stewart >> randall@lakerest.net >> >> >> >> > > Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CECA3A694F for ; Wed, 25 Feb 2009 07:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.893 X-Spam-Level: ** X-Spam-Status: No, score=2.893 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjnGlLU-I-qQ for ; Wed, 25 Feb 2009 07:19:41 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id B25573A6866 for ; Wed, 25 Feb 2009 07:19:40 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 8C6371C0E9633; Wed, 25 Feb 2009 16:19:58 +0100 (CET) Message-Id: <927995A4-91DB-412D-B883-80BD652A2F9F@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Randy Stewart In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 16:19:56 +0100 References: <49A30F9E.90504@hp.com> <49A3F4FC.8010803@hp.com> <879730EA-BFAC-407F-922A-A2F6D00CE86F@lurchi.franken.de> <49A43C99.90500@hp.com> <6C6A8DE3-2AAF-4911-8514-951128E8C7C8@lurchi.franken.de> <49A4BF2A.7030400@sun.com> <14AF35DB-B38E-4611-BC58-5ED0BC8FA971@lakerest.net> <955B17C0-C412-4B2B-973C-52F061721D66@lakerest.net> <49A558F9.9040700@hp.com> X-Mailer: Apple Mail (2.930.3) Cc: Vlad Yasevich , Kacheong Poon , tsvwg Subject: Re: [Tsvwg] Event Notifications X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:19:42 -0000 On Feb 25, 2009, at 4:09 PM, Randy Stewart wrote: > > On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote: > >> Randy Stewart wrote: >>> >>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote: >>> >>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote: >>>> >>>>> >>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote: >>>>> >>>>>> Michael T=FCxen wrote: >>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote: >>>>>> ... >>>>>>>> Hmm.. That's an interesting question. Is it a possible =20 >>>>>>>> scenario >>>>>>>> where >>>>>>>> an application decides to change event subscription of an >>>>>>>> association after >>>>>>>> it's established? I can't see a reason right now, but that >>>>>>>> doesn't mean it >>>>>>>> doesn't exist. >>>>>>> We do this for the DRY event since we are only interested in it >>>>>>> during some specific states in DTLS (during renegotiations). >>>>>> >>>>>> >>>>>> If we want to explore this, I'd suggest we retire (just keep >>>>>> it there for backward compatibility) the sctp_event_subscribe. >>>>>> It is not extensible. Just use sctp_assoc_value. An app can >>>>>> subscribe/unsubscribe each event one by one. >>>>>> >>>>>> BTW, I guess it should not cause a problem if the DRY event is >>>>>> enabled for all associations controlled by one socket all the >>>>>> time. >>>>>> >>>>> >>>>> Hmm so let me summarize what I think we have agreed to so far >>>>> >>>>> 1) We will add support for using the sctp_assoc_value structure >>>>> to turn on/off EEOR mode on a per assoc basis. >>>>> 2) If the value of the assoc is 0, then the entire socket =20 >>>>> (1-2many or >>>>> 1-1) is >>>>> set to EEOR mode this includes future and all existing sockets. >>>>> >>>>> >>>>> On the events... I am not convinced a per-assoc subscription is >>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20= >>>>> many >>>>> socket .. you know if you are sending and can turn it off as soon >>>>> as the dry-event occurs. If you get a dry event on another >>>>> association, you can pretty easily ignore it. It might be nice >>>>> to have per-association on/off of some events. But I am mixed >>>>> on how useful that is. >>>>> >>>>> I do agree with Kacheong here though, if we have to go this =20 >>>>> route we >>>>> need a new structure.. i.e. one that includes an assoc id.. and =20= >>>>> then >>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20 >>>>> associations >>>>> or the entire socket... vs just changing a single association. I =20= >>>>> would >>>>> also think we want to make it more extensible and as Kacheong said >>>>> just retire the old SCTP_EVENTS... i.e. support for backward >>>>> compatibility >>>>> but move to the new structure for future things.. >>>>> >>>>> But again, is this really worth it? I am not convinced it is yet.. >>>> There are two points here specific to the DRY event: >>>> >>>> 1. Performance: I might be interested only in the events for one >>>> particular association, but I get them for all. Of course I >>>> can ignore them for all associations I'm not interested in, >>>> but this means the kernel is going to generate a lot of =20 >>>> notifications >>>> I'm not interested in. This is just waisted cycles and mbufs. >>>> >>>> 2. The DRY event is generated when it is enabled and the the =20 >>>> association >>>> is dry. So assume I have N associations (being dry), I'm =20 >>>> interested >>>> in one. Now I enable it. The kernel has to generate N notifications >>>> instantly. This might be a resource problem (on Mac OS X I ran into >>>> it), because you need N mbufs at about the same time. There is also >>>> no "flow control" for notifications. >>>> That is why I implemented this currently only for 1-to-1 style =20 >>>> sockets. >>>> >>>> But I think we should be more future proof here. >>>> I like Kacheongs idea to use the assoc_value structs: >>>> 1. This allows it to control it on an association base. No =20 >>>> limitation >>>> here. >>>> 2. It can be used with any future notification. It is just adding a >>>> new constant, not changing a structure which might break ABI >>>> compatibility. >>>> 3. It is simple. >>>> >>>> I think we should add this. >>> >>> >>> Michael so what you are proposing is that we: >>> >>> 1) Keep the existing SCTP_EVENT's socket call. >>> >>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a >>> sctp_assoc_value structure. Where the assoc-id is the >>> assoc you want the notification on. And the value is the >>> Notification id. We would type all current notifications >>> with constants e.g. SCTP_DRY_NOTIFICATION >> >> So, this option could only be used to turn something on, not turn >> it off? Seems one-sided. :) > > > Hmm.. yeah you are right here. You would have to define two contants > I guess.. > > SCTP_DRY_NOTIFICATION_ON > SCTP_DRY_NOTIFICATION_OFF This does not help for getsockopt()... Se my suggestion in my previous =20= mail. > > > Since its a 32 bit number space in the value it would probably be =20 > extensible > enough (2 billion possibilities) :-) > >> >> >>> >>> 3) I think we would want 0 to be again, future associations >>> and non-zero to be specific associations. >>> >>> >>> Now this would also mean that the existing SCTP_EVENT's would have >>> a slight change, which I think is ok. It would now be a short cut >>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with >>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's. >>> >>> This is a subtle difference but one we should document well. I think >>> its ok, since most folks using the SCTP_EVENT's do not change >>> things in the middle. They basically open a socket, set the events >>> they may want... and then never touch it again. >>> >>> I do agree this would then add a nice extensible mechanism to add >>> future events as well. >>> >> >> Yes, this is something that would be good to have. It also gives >> applications a very fine control over what they can request and =20 >> that's >> generally a good thing. > > True > > R >> >> >> -vlad >> >>> As long as Kacheong and Vlad are ok with this I am too... I can see >>> it will at least be useful for the sender-dry-event. Not sure about >>> other ones but you never know. >>> >>> Kacheong, Vlad, -- thoughts.. if you agree I will start making >>> changes in BSD and the ID.. >>> >>> R >>> >>> ----- >>> Randall Stewart >>> randall@lakerest.net >>> >>> >>> >>> >> > > ----- > Randall Stewart > randall@lakerest.net > > > > >