From rserpool-admin@ietf.org Tue Apr 1 10:45:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22073 for ; Tue, 1 Apr 2003 10:45:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G9PK12795; Tue, 1 Apr 2003 11:09:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G2xK09592 for ; Tue, 1 Apr 2003 11:02:59 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21060 for ; Tue, 1 Apr 2003 10:38:39 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id 620EB24616; Tue, 1 Apr 2003 17:38:01 +0200 (CEST) Date: Tue, 1 Apr 2003 17:35:07 +0200 Subject: Re: [Rserpool] Directions for next version of service draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Rserpool To: Phillip Conrad From: Michael Tuexen In-Reply-To: <5.1.1.6.0.20030317110804.0341e678@joda.cis.temple.edu> Message-Id: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phil, see my comments below. Best regards Michael On Monday, Mar 17, 2003, at 20:32 Europe/Berlin, Phillip Conrad wrote: > Here are some suggested directions for RSerPool: > > To the working group: do we have rough consensus on these points? I > and others (Peter, Randy, Qiaobing et al) will ask for rough > consensus on these points in the working group meeting later today in > San Francisco... and for the sake of those that are NOT in the meeting > today, please consider this email as your opportunity to express > support, dissent, or to ask for further clarification on the points > below. > > (1) In the service draft, replace "failover mode" vs. "nameservice > mode" with "multiplexed data channel" vs. "non multiplexed data > channel". > OK. > (2) In the service draft, remove application layer acks from protocol, > and write up as use case instead. > OK. > (3) In general: No multiple transport registrations: you either > > (a) register the transport address of either an SCTP or TCP (but not > both) multiplexed control and data over a single transport > association/connection. (Note: you _can_ register both, but if you do > so, they should be in different pools, preserving the principle that > all PE's in a pool should be functionally equivalent, including all > using the same transport protocol to provide service.) > > (b) you register the transport address of a data channel only, not > managed by rserpool (and do without the services that would be > provided by a control channel.) > Is this the same for all PE in a Pool? > > (4) A Note: when you register for SCTP, you may register multiple IP > addresses, but only a single port... i.e, you are only registering a > single SCTP endpoint. This is already reflected in the current > drafts. > OK. > > Thanks, > Phill Conrad > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 10:46:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22176 for ; Tue, 1 Apr 2003 10:46:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31GA5E13146 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 11:10:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G9PK12795; Tue, 1 Apr 2003 11:09:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G2xK09592 for ; Tue, 1 Apr 2003 11:02:59 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21060 for ; Tue, 1 Apr 2003 10:38:39 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id 620EB24616; Tue, 1 Apr 2003 17:38:01 +0200 (CEST) Date: Tue, 1 Apr 2003 17:35:07 +0200 Subject: Re: [Rserpool] Directions for next version of service draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Rserpool To: Phillip Conrad From: Michael Tuexen In-Reply-To: <5.1.1.6.0.20030317110804.0341e678@joda.cis.temple.edu> Message-Id: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phil, see my comments below. Best regards Michael On Monday, Mar 17, 2003, at 20:32 Europe/Berlin, Phillip Conrad wrote: > Here are some suggested directions for RSerPool: > > To the working group: do we have rough consensus on these points? I > and others (Peter, Randy, Qiaobing et al) will ask for rough > consensus on these points in the working group meeting later today in > San Francisco... and for the sake of those that are NOT in the meeting > today, please consider this email as your opportunity to express > support, dissent, or to ask for further clarification on the points > below. > > (1) In the service draft, replace "failover mode" vs. "nameservice > mode" with "multiplexed data channel" vs. "non multiplexed data > channel". > OK. > (2) In the service draft, remove application layer acks from protocol, > and write up as use case instead. > OK. > (3) In general: No multiple transport registrations: you either > > (a) register the transport address of either an SCTP or TCP (but not > both) multiplexed control and data over a single transport > association/connection. (Note: you _can_ register both, but if you do > so, they should be in different pools, preserving the principle that > all PE's in a pool should be functionally equivalent, including all > using the same transport protocol to provide service.) > > (b) you register the transport address of a data channel only, not > managed by rserpool (and do without the services that would be > provided by a control channel.) > Is this the same for all PE in a Pool? > > (4) A Note: when you register for SCTP, you may register multiple IP > addresses, but only a single port... i.e, you are only registering a > single SCTP endpoint. This is already reflected in the current > drafts. > OK. > > Thanks, > Phill Conrad > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 10:48:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22462 for ; Tue, 1 Apr 2003 10:48:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GBlK13862; Tue, 1 Apr 2003 11:11:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G4dK09828 for ; Tue, 1 Apr 2003 11:04:39 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21160 for ; Tue, 1 Apr 2003 10:40:20 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id E60AA24616; Tue, 1 Apr 2003 17:39:39 +0200 (CEST) Date: Tue, 1 Apr 2003 17:36:48 +0200 Subject: Re: [Rserpool] Re: Message channel issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Qiaobing Xie , Randall Stewart , Rserpool , "Randall Stewart (cisco)" , Maureen Stillman , "Michael Tuexen (at home)" , "Michael Tuexen (at work)" To: Phillip Conrad From: Michael Tuexen In-Reply-To: <5.1.1.6.0.20030316235723.01981338@joda.cis.temple.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, I'm sorry for commenting so late. Possibly I was not clear during the phone conference. I do not want to have a control channel only, so the comparison with ftp is not correct. The data channel is the 'important' one. I'm happy with the following: 1. If the transport for the data channel is SCTP, multiplex (using PPID) the control channel on the same transport connection. 2. If the transport for the data channel is TCP, multiplex (using Phils layer) or not. If not, you do not have a control channel. 3. If the transport layer is UDP, you do not have a control channel. That is a very simple solution. Best regards Michael On Monday, Mar 17, 2003, at 06:15 Europe/Berlin, Phillip Conrad wrote: > Some comments: > > At 01:05 PM 3/13/2003 -0600, Qiaobing Xie wrote: >> Randall Stewart wrote: >> > Maybe the solution is no more than two transports be registered >> > and they must either be >> > >> > 1) A single transport for control and data >> > 2) A single transport for data only >> > 3) Two transports one for control, one for data.. >> > >> > If you select <3> then if EITHER channel does not function >> > then the PE is considered unreachable.. >> >> I like this... I'd even go a bit further to take out <3>. > > Believe it or not, I'm in agreement with Qiaobing on several points. > First, I agree that we can probably live without multiple transport > registrations. Why did we want these in the first place? For two > reasons I think. > > (1) We wanted to allow for migration from TCP to SCTP for pool users; > i.e. allow some pool users that have not yet adopted SCTP to > participate in a pool for service X. However, this can be handled > more simply by maintaining separate pools, with separate pool handles, > e.g. X-SCTP and X-TCP. This preserves the principle that a pool > should be made up of equivalent services... this concept should > include "equivalent in terms of which transport protocol is used". > > (2) We wanted to allow for separate data and control channels on two > different protocols. E.g. control channel over SCTP (or mapped TCP) > and data channel over UDP, or protocol XYZ, or whatever. However, > Qiaobing makes a case that we can acheive better simplicity by simply > requiring that applications that use a transport other than SCTP or > TCP for their data channel do NOT benefit from the extended features > that the control channel allows. I.e., you should either use a > multplexed control/data channel, or you shoudl not use a control > channel at all. (Interestingly, this is pretty much exactly what I > had in mind when I suggested two "modes" in the original version of > the services draft. I think perhaps it is time to take a second > look at that concept. Qiaobing doesn't seem to like the terms > "failover" vs. "nameservice" mode for the services you get from a > muxed control/data channel, or a data only channel (respectively), but > I think that the concepts in the services draft are the right ones. > > Let me invite folks to re-read the services draft and make some > suggestions: is the problem with the concepts, or only with the > terminology? Can we come up with better terms that "failover" vs. > "nameservice" mode? > > Thanks, > Phill > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 10:48:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22578 for ; Tue, 1 Apr 2003 10:48:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31GCP814665 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 11:12:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GBlK13862; Tue, 1 Apr 2003 11:11:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G4dK09828 for ; Tue, 1 Apr 2003 11:04:39 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21160 for ; Tue, 1 Apr 2003 10:40:20 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id E60AA24616; Tue, 1 Apr 2003 17:39:39 +0200 (CEST) Date: Tue, 1 Apr 2003 17:36:48 +0200 Subject: Re: [Rserpool] Re: Message channel issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Qiaobing Xie , Randall Stewart , Rserpool , "Randall Stewart (cisco)" , Maureen Stillman , "Michael Tuexen (at home)" , "Michael Tuexen (at work)" To: Phillip Conrad From: Michael Tuexen In-Reply-To: <5.1.1.6.0.20030316235723.01981338@joda.cis.temple.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, I'm sorry for commenting so late. Possibly I was not clear during the phone conference. I do not want to have a control channel only, so the comparison with ftp is not correct. The data channel is the 'important' one. I'm happy with the following: 1. If the transport for the data channel is SCTP, multiplex (using PPID) the control channel on the same transport connection. 2. If the transport for the data channel is TCP, multiplex (using Phils layer) or not. If not, you do not have a control channel. 3. If the transport layer is UDP, you do not have a control channel. That is a very simple solution. Best regards Michael On Monday, Mar 17, 2003, at 06:15 Europe/Berlin, Phillip Conrad wrote: > Some comments: > > At 01:05 PM 3/13/2003 -0600, Qiaobing Xie wrote: >> Randall Stewart wrote: >> > Maybe the solution is no more than two transports be registered >> > and they must either be >> > >> > 1) A single transport for control and data >> > 2) A single transport for data only >> > 3) Two transports one for control, one for data.. >> > >> > If you select <3> then if EITHER channel does not function >> > then the PE is considered unreachable.. >> >> I like this... I'd even go a bit further to take out <3>. > > Believe it or not, I'm in agreement with Qiaobing on several points. > First, I agree that we can probably live without multiple transport > registrations. Why did we want these in the first place? For two > reasons I think. > > (1) We wanted to allow for migration from TCP to SCTP for pool users; > i.e. allow some pool users that have not yet adopted SCTP to > participate in a pool for service X. However, this can be handled > more simply by maintaining separate pools, with separate pool handles, > e.g. X-SCTP and X-TCP. This preserves the principle that a pool > should be made up of equivalent services... this concept should > include "equivalent in terms of which transport protocol is used". > > (2) We wanted to allow for separate data and control channels on two > different protocols. E.g. control channel over SCTP (or mapped TCP) > and data channel over UDP, or protocol XYZ, or whatever. However, > Qiaobing makes a case that we can acheive better simplicity by simply > requiring that applications that use a transport other than SCTP or > TCP for their data channel do NOT benefit from the extended features > that the control channel allows. I.e., you should either use a > multplexed control/data channel, or you shoudl not use a control > channel at all. (Interestingly, this is pretty much exactly what I > had in mind when I suggested two "modes" in the original version of > the services draft. I think perhaps it is time to take a second > look at that concept. Qiaobing doesn't seem to like the terms > "failover" vs. "nameservice" mode for the services you get from a > muxed control/data channel, or a data only channel (respectively), but > I think that the concepts in the services draft are the right ones. > > Let me invite folks to re-read the services draft and make some > suggestions: is the problem with the concepts, or only with the > terminology? Can we come up with better terms that "failover" vs. > "nameservice" mode? > > Thanks, > Phill > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailman-admin@ietf.org Tue Apr 1 11:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27614 for ; Tue, 1 Apr 2003 11:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31H0rK31924 for ; Tue, 1 Apr 2003 12:00:53 -0500 Date: Tue, 01 Apr 2003 12:00:53 -0500 Message-ID: <20030401170053.29326.11483.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rserpool-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rserpool-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rserpool-archive@lists.ietf.org: List Password // URL ---- -------- rserpool@ietf.org RVOD https://www1.ietf.org/mailman/options/rserpool/rserpool-archive%40lists.ietf.org From rserpool-admin@ietf.org Tue Apr 1 12:31:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02103 for ; Tue, 1 Apr 2003 12:31:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HtBK16451; Tue, 1 Apr 2003 12:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Hs8K16336 for ; Tue, 1 Apr 2003 12:54:08 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01988 for ; Tue, 1 Apr 2003 12:29:46 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id MAA08049; Tue, 1 Apr 2003 12:31:59 -0500 (EST) Message-Id: <5.1.0.14.2.20030401121904.00aa8f90@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 12:30:31 -0500 To: Michael Tuexen From: "Phillip T. Conrad" Subject: Re: [Rserpool] Directions for next version of service draft Cc: Rserpool In-Reply-To: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> References: <5.1.1.6.0.20030317110804.0341e678@joda.cis.temple.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Hi Michael: Thanks for responding to request for "rough consensus" in my previous note on several points related to the next version of the service draft. In your reply, you indicated acceptance of the suggested directions, with just one question: I've included the context for that question, and answered it below. At 05:35 PM 4/1/2003 +0200, Michael Tuexen wrote (in part): >Phil, >see my comments below. ... >>Here are some suggested directions for RSerPool: >> >>To the working group: do we have rough consensus on these points? I and >>others (Peter, Randy, Qiaobing et al) will ask for rough consensus on >>these points in the working group meeting later today in San Francisco... >>and for the sake of those that are NOT in the meeting today, please >>consider this email as your opportunity to express support, dissent, or >>to ask for further clarification on the points below. ... >>(3) In general: No multiple transport registrations: you either >> >>(a) register the transport address of either an SCTP or TCP (but not >>both) multiplexed control and data over a single transport >>association/connection. (Note: you _can_ register both, but if you do >>so, they should be in different pools, preserving the principle that all >>PE's in a pool should be functionally equivalent, including all using the >>same transport protocol to provide service.) >> >>(b) you register the transport address of a data channel only, not >>managed by rserpool (and do without the services that would be provided >>by a control channel.) >Is this the same for all PE in a Pool? To my understanding, yes: the notion is that all PEs in a given pool should behave the same way. That is one of the architectural principles we are trying to emphasize as we move forward, for the sake of simplicity. So, I think we should emphasize in the various drafts that for a given pool, all PEs either behave according to the rules of (a) above, or all PEs behave according the rules of (b). What we gain by this direction is simplicity. We lose some flexibility (in particular, we lose the ability to support some of the scenarios below), but I think the sense of the group was that none of these things are terribly important; i.e. we do not have application scenarios that require these particular capabilties. Here are some of the capabilities we give up: (1) the flexibility to failing over among a group of PEs, where some have a control channel, and others don't. (2) the flexibility to have a data channel on one transport address and protocol, and a control channel on a different transport address and perhaps a different transport protocol. I hope this explanation is helpful, and I invite comments or questions from anyone on the list. Regards, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 12:31:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02153 for ; Tue, 1 Apr 2003 12:31:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Htog16471 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 12:55:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HtBK16451; Tue, 1 Apr 2003 12:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Hs8K16336 for ; Tue, 1 Apr 2003 12:54:08 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01988 for ; Tue, 1 Apr 2003 12:29:46 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id MAA08049; Tue, 1 Apr 2003 12:31:59 -0500 (EST) Message-Id: <5.1.0.14.2.20030401121904.00aa8f90@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 12:30:31 -0500 To: Michael Tuexen From: "Phillip T. Conrad" Subject: Re: [Rserpool] Directions for next version of service draft Cc: Rserpool In-Reply-To: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> References: <5.1.1.6.0.20030317110804.0341e678@joda.cis.temple.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Hi Michael: Thanks for responding to request for "rough consensus" in my previous note on several points related to the next version of the service draft. In your reply, you indicated acceptance of the suggested directions, with just one question: I've included the context for that question, and answered it below. At 05:35 PM 4/1/2003 +0200, Michael Tuexen wrote (in part): >Phil, >see my comments below. ... >>Here are some suggested directions for RSerPool: >> >>To the working group: do we have rough consensus on these points? I and >>others (Peter, Randy, Qiaobing et al) will ask for rough consensus on >>these points in the working group meeting later today in San Francisco... >>and for the sake of those that are NOT in the meeting today, please >>consider this email as your opportunity to express support, dissent, or >>to ask for further clarification on the points below. ... >>(3) In general: No multiple transport registrations: you either >> >>(a) register the transport address of either an SCTP or TCP (but not >>both) multiplexed control and data over a single transport >>association/connection. (Note: you _can_ register both, but if you do >>so, they should be in different pools, preserving the principle that all >>PE's in a pool should be functionally equivalent, including all using the >>same transport protocol to provide service.) >> >>(b) you register the transport address of a data channel only, not >>managed by rserpool (and do without the services that would be provided >>by a control channel.) >Is this the same for all PE in a Pool? To my understanding, yes: the notion is that all PEs in a given pool should behave the same way. That is one of the architectural principles we are trying to emphasize as we move forward, for the sake of simplicity. So, I think we should emphasize in the various drafts that for a given pool, all PEs either behave according to the rules of (a) above, or all PEs behave according the rules of (b). What we gain by this direction is simplicity. We lose some flexibility (in particular, we lose the ability to support some of the scenarios below), but I think the sense of the group was that none of these things are terribly important; i.e. we do not have application scenarios that require these particular capabilties. Here are some of the capabilities we give up: (1) the flexibility to failing over among a group of PEs, where some have a control channel, and others don't. (2) the flexibility to have a data channel on one transport address and protocol, and a control channel on a different transport address and perhaps a different transport protocol. I hope this explanation is helpful, and I invite comments or questions from anyone on the list. Regards, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 13:20:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06227 for ; Tue, 1 Apr 2003 13:20:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Ii7K02393; Tue, 1 Apr 2003 13:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IhuK02337 for ; Tue, 1 Apr 2003 13:43:56 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06194 for ; Tue, 1 Apr 2003 13:19:33 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h31ILUUl000082; Tue, 1 Apr 2003 11:21:30 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA14940; Tue, 1 Apr 2003 11:19:29 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h31ILti23953; Tue, 1 Apr 2003 12:21:56 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id MAA16349; Tue, 1 Apr 2003 12:23:57 -0600 (CST) Message-ID: <3E89D8C3.8271AE3F@motorola.com> Date: Tue, 01 Apr 2003 12:21:55 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Tuexen CC: Phillip Conrad, Rserpool Subject: Re: [Rserpool] Directions for next version of service draft References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Michael, Welcome back :-) Michael Tuexen wrote: >... > > (1) In the service draft, replace "failover mode" vs. "nameservice > > mode" with "multiplexed data channel" vs. "non multiplexed data > > channel". > > > OK. Phill and I talked about this a bit more and we both felt that it might be even better if we use a pair of "non-descriptive" terms, such as "basic mode" and "enhanced mode". This is because people sometimes tends to stop reading any further and start to imagining the rest when they see a "descriptive" term :-) This often causes misunderstanding. regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 13:20:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06307 for ; Tue, 1 Apr 2003 13:20:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Iiox02542 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 13:44:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Ii7K02393; Tue, 1 Apr 2003 13:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IhuK02337 for ; Tue, 1 Apr 2003 13:43:56 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06194 for ; Tue, 1 Apr 2003 13:19:33 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h31ILUUl000082; Tue, 1 Apr 2003 11:21:30 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA14940; Tue, 1 Apr 2003 11:19:29 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h31ILti23953; Tue, 1 Apr 2003 12:21:56 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id MAA16349; Tue, 1 Apr 2003 12:23:57 -0600 (CST) Message-ID: <3E89D8C3.8271AE3F@motorola.com> Date: Tue, 01 Apr 2003 12:21:55 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Tuexen CC: Phillip Conrad, Rserpool Subject: Re: [Rserpool] Directions for next version of service draft References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Michael, Welcome back :-) Michael Tuexen wrote: >... > > (1) In the service draft, replace "failover mode" vs. "nameservice > > mode" with "multiplexed data channel" vs. "non multiplexed data > > channel". > > > OK. Phill and I talked about this a bit more and we both felt that it might be even better if we use a pair of "non-descriptive" terms, such as "basic mode" and "enhanced mode". This is because people sometimes tends to stop reading any further and start to imagining the rest when they see a "descriptive" term :-) This often causes misunderstanding. regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 14:02:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08199 for ; Tue, 1 Apr 2003 14:02:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JQ6K10500; Tue, 1 Apr 2003 14:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JP3K10461 for ; Tue, 1 Apr 2003 14:25:03 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08133 for ; Tue, 1 Apr 2003 14:00:40 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h31J3DZ23417 for ; Tue, 1 Apr 2003 13:03:13 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 1 Apr 2003 13:03:06 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 13:03:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 1 Apr 2003 13:01:15 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E680C5@daebe007.americas.nokia.com> Thread-Topic: Rserpool Conference call details for Tuesday, March 4 at 10AM EST USA Thread-Index: AcLhkMw0Cq1j8O+KSZqmfJs/PQdMYAW75LQA To: X-OriginalArrivalTime: 01 Apr 2003 19:03:03.0497 (UTC) FILETIME=[524BE390:01C2F881] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31JP3K10462 Subject: [Rserpool] Rserpool Conference call details for Friday, April 4 at 10AM EST USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team conference call will be Friday, April 4 at 10AM EST USA Conference call details for Friday, April 4 at 10AM EST USA DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 14:02:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08216 for ; Tue, 1 Apr 2003 14:02:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31JQjb10558 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 14:26:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JQ6K10500; Tue, 1 Apr 2003 14:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JP3K10461 for ; Tue, 1 Apr 2003 14:25:03 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08133 for ; Tue, 1 Apr 2003 14:00:40 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h31J3DZ23417 for ; Tue, 1 Apr 2003 13:03:13 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 1 Apr 2003 13:03:06 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 13:03:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 1 Apr 2003 13:01:15 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811E680C5@daebe007.americas.nokia.com> Thread-Topic: Rserpool Conference call details for Tuesday, March 4 at 10AM EST USA Thread-Index: AcLhkMw0Cq1j8O+KSZqmfJs/PQdMYAW75LQA To: X-OriginalArrivalTime: 01 Apr 2003 19:03:03.0497 (UTC) FILETIME=[524BE390:01C2F881] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31JP3K10462 Subject: [Rserpool] Rserpool Conference call details for Friday, April 4 at 10AM EST USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team conference call will be Friday, April 4 at 10AM EST USA Conference call details for Friday, April 4 at 10AM EST USA DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 16:59:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17261 for ; Tue, 1 Apr 2003 16:59:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MNDK25308; Tue, 1 Apr 2003 17:23:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MM6K25255 for ; Tue, 1 Apr 2003 17:22:06 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17178 for ; Tue, 1 Apr 2003 16:57:40 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA09412 for ; Tue, 1 Apr 2003 17:00:05 -0500 (EST) Message-Id: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 17:03:52 -0500 To: Rserpool From: "Phillip T. Conrad" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Rserpool] Another data channel issue: failover of messages in basic mode? Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Dear Colleagues: In my discussion with Qiaobing about renaming the two modes for RSerPool services to "basic" and "enhanced", another issue that Qiaobing raised is whether in basic mode, automatic failover of messages can be provided as a service. My first inclination is to say "no", however on further reflection, I said I would think about it. So here are some thoughts about that, and an question to pose to the working group. My first reaction is to say that what you get in basic mode is the selection of a server that is better than what you would get with DNS because it - is based on reports from PEs and PUs about server health - can based on a policy value (for load sharing) (and maybe some other benefits that the working group can help me to recite; I'm definitely inviting help with the text here!) But in basic mode, you do not get automatic best-effort message failover, because that requires you to be sending over a transport that is mapped to the RSerPool API. Message failover comes in enhanced mode, along with all the other goodies (business cards, etc) However, Qiaobing pointed out, correctly, that you do not need the control channel to do message failover (now that application layer acks are gone); all you need is someway to tell the RSerPool API how to map the the RSerPool data transmission primitives (e.g. the equivalent in your particular API of the data.send primitive) to the transport protocol in question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping is so trivial that it almost doesn't even need to be mentioned, and if we provide it, this will allow failover of any message that has not yet been put on the wire. Of course, except for with SCTP, you will not get any message failover of messages that have already been submitted to the transport layer and were never transmitted, since no protocol other than SCTP supports "retrieval" (note that because application layer acks were removed, you don't even get that with the TCP mapping layer anymore.) My question is this: how often would it be, for example, in UDP, that you would have any messages that had not yet been put on the wire? The only time I can imagine an RSerPool implementation not putting something on the wire immediately is if the underlying transport layer socket is not writable (determined for example via a select() system call in the sockets API, or an EWOULDBLOCK error, etc.) My understanding is that this typically happens when the transport endpoint is restricted because of cwnd or rwnd, and then also runs out of buffer space, and the socket runs out of buffer space too. This could realistically happen with SCTP or TCP particularly if the application on the peer end is slow to read and process data. But how realistic is it for UDP? My guess is that is will never happen, since UDP is never blocked due to cwnd or rwnd. So, I while I can concede Qiaobing's point that a message channel is not necessary to provide I'm not sure there is a practical need to provide for message failover in basic mode. I'd like to keep basic mode as basic as possible, just for cleanness of the architecture. I'd like to invite the rest of the working group to comment on these two possibilities: should we (1) allow for message failover in basic mode for messages not yet put on the wire (which means, conceivably, any arbitrary transport protocol)? OR (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? Thanks, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 16:59:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17275 for ; Tue, 1 Apr 2003 16:59:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MNEK25323; Tue, 1 Apr 2003 17:23:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MMgK25272 for ; Tue, 1 Apr 2003 17:22:42 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17198 for ; Tue, 1 Apr 2003 16:58:09 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA09403; Tue, 1 Apr 2003 17:00:30 -0500 (EST) Message-Id: <5.1.0.14.2.20030401143409.052ab578@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 16:51:58 -0500 To: Rserpool From: "Phillip T. Conrad" Subject: Re: [Rserpool] Directions for next version of service draft Cc: Michael Tuexen In-Reply-To: <3E89D8C3.8271AE3F@motorola.com> References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Dear Colleagues, Yes, Qiaobing is correct; he and I discussed this and I agree with him. I am inclined to use these terms ("basic mode" vs. "enhanced mode") in the next version of the service draft if there is no strong objection from the list. Essentially, "basic mode" would be the mode in which there is no control channel (and hence, no business cards, etc.). In this mode, only a single transport endpoint could be registered (by port number) to serve as the data channel. This data channel can use "any" transport protocol. However, the transport protocol used must be the same transport protocol for all members of a given pool.) This is similar to the notion that all PEs in a given pool must use the same policy type (see section 4.3 of ENRP draft). The "enhanced mode" is the one in which all PEs in a given pool must either all use SCTP, _or_ they must all use TCP as the transport protocol. (Read the "_or_" as "exclusive or"). The SCTP association or TCP connection provides a multiplexed data/control channel that allows the enhanced services (business cards, etc.) that require the control channel. This raises an issue: I wonder if we should include language in the ENRP draft about the "transport protocol" that is similar to that which already exists in the ENRP draft about "policy type"... i.e. that the first PE to register with a particular pool handle "x" is the one that determines the policy type that all PEs must follow for pool "x". Regards, Phill At 12:21 PM 4/1/2003 -0600, Qiaobing Xie wrote: >Phill and I talked about this a bit more and we both felt that it might >be even better if we use a pair of "non-descriptive" terms, such as >"basic mode" and "enhanced mode". This is because people sometimes tends >to stop reading any further and start to imagining the rest when they >see a "descriptive" term :-) This often causes misunderstanding. > >regards, >-Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 17:00:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17313 for ; Tue, 1 Apr 2003 17:00:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31MNvW25355 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 17:23:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MNDK25308; Tue, 1 Apr 2003 17:23:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MM6K25255 for ; Tue, 1 Apr 2003 17:22:06 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17178 for ; Tue, 1 Apr 2003 16:57:40 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA09412 for ; Tue, 1 Apr 2003 17:00:05 -0500 (EST) Message-Id: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 17:03:52 -0500 To: Rserpool From: "Phillip T. Conrad" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Rserpool] Another data channel issue: failover of messages in basic mode? Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Dear Colleagues: In my discussion with Qiaobing about renaming the two modes for RSerPool services to "basic" and "enhanced", another issue that Qiaobing raised is whether in basic mode, automatic failover of messages can be provided as a service. My first inclination is to say "no", however on further reflection, I said I would think about it. So here are some thoughts about that, and an question to pose to the working group. My first reaction is to say that what you get in basic mode is the selection of a server that is better than what you would get with DNS because it - is based on reports from PEs and PUs about server health - can based on a policy value (for load sharing) (and maybe some other benefits that the working group can help me to recite; I'm definitely inviting help with the text here!) But in basic mode, you do not get automatic best-effort message failover, because that requires you to be sending over a transport that is mapped to the RSerPool API. Message failover comes in enhanced mode, along with all the other goodies (business cards, etc) However, Qiaobing pointed out, correctly, that you do not need the control channel to do message failover (now that application layer acks are gone); all you need is someway to tell the RSerPool API how to map the the RSerPool data transmission primitives (e.g. the equivalent in your particular API of the data.send primitive) to the transport protocol in question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping is so trivial that it almost doesn't even need to be mentioned, and if we provide it, this will allow failover of any message that has not yet been put on the wire. Of course, except for with SCTP, you will not get any message failover of messages that have already been submitted to the transport layer and were never transmitted, since no protocol other than SCTP supports "retrieval" (note that because application layer acks were removed, you don't even get that with the TCP mapping layer anymore.) My question is this: how often would it be, for example, in UDP, that you would have any messages that had not yet been put on the wire? The only time I can imagine an RSerPool implementation not putting something on the wire immediately is if the underlying transport layer socket is not writable (determined for example via a select() system call in the sockets API, or an EWOULDBLOCK error, etc.) My understanding is that this typically happens when the transport endpoint is restricted because of cwnd or rwnd, and then also runs out of buffer space, and the socket runs out of buffer space too. This could realistically happen with SCTP or TCP particularly if the application on the peer end is slow to read and process data. But how realistic is it for UDP? My guess is that is will never happen, since UDP is never blocked due to cwnd or rwnd. So, I while I can concede Qiaobing's point that a message channel is not necessary to provide I'm not sure there is a practical need to provide for message failover in basic mode. I'd like to keep basic mode as basic as possible, just for cleanness of the architecture. I'd like to invite the rest of the working group to comment on these two possibilities: should we (1) allow for message failover in basic mode for messages not yet put on the wire (which means, conceivably, any arbitrary transport protocol)? OR (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? Thanks, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 17:00:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17327 for ; Tue, 1 Apr 2003 17:00:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31MNwB25368 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 17:23:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MNEK25323; Tue, 1 Apr 2003 17:23:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MMgK25272 for ; Tue, 1 Apr 2003 17:22:42 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17198 for ; Tue, 1 Apr 2003 16:58:09 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA09403; Tue, 1 Apr 2003 17:00:30 -0500 (EST) Message-Id: <5.1.0.14.2.20030401143409.052ab578@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 16:51:58 -0500 To: Rserpool From: "Phillip T. Conrad" Subject: Re: [Rserpool] Directions for next version of service draft Cc: Michael Tuexen In-Reply-To: <3E89D8C3.8271AE3F@motorola.com> References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Dear Colleagues, Yes, Qiaobing is correct; he and I discussed this and I agree with him. I am inclined to use these terms ("basic mode" vs. "enhanced mode") in the next version of the service draft if there is no strong objection from the list. Essentially, "basic mode" would be the mode in which there is no control channel (and hence, no business cards, etc.). In this mode, only a single transport endpoint could be registered (by port number) to serve as the data channel. This data channel can use "any" transport protocol. However, the transport protocol used must be the same transport protocol for all members of a given pool.) This is similar to the notion that all PEs in a given pool must use the same policy type (see section 4.3 of ENRP draft). The "enhanced mode" is the one in which all PEs in a given pool must either all use SCTP, _or_ they must all use TCP as the transport protocol. (Read the "_or_" as "exclusive or"). The SCTP association or TCP connection provides a multiplexed data/control channel that allows the enhanced services (business cards, etc.) that require the control channel. This raises an issue: I wonder if we should include language in the ENRP draft about the "transport protocol" that is similar to that which already exists in the ENRP draft about "policy type"... i.e. that the first PE to register with a particular pool handle "x" is the one that determines the policy type that all PEs must follow for pool "x". Regards, Phill At 12:21 PM 4/1/2003 -0600, Qiaobing Xie wrote: >Phill and I talked about this a bit more and we both felt that it might >be even better if we use a pair of "non-descriptive" terms, such as >"basic mode" and "enhanced mode". This is because people sometimes tends >to stop reading any further and start to imagining the rest when they >see a "descriptive" term :-) This often causes misunderstanding. > >regards, >-Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 17:58:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19268 for ; Tue, 1 Apr 2003 17:58:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NM4K29670; Tue, 1 Apr 2003 18:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGwiO19261 for ; Fri, 28 Mar 2003 11:58:44 -0500 Received: from moutng.kundenserver.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06408; Fri, 28 Mar 2003 11:36:21 -0500 (EST) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18ywsP-00015P-00; Fri, 28 Mar 2003 17:38:45 +0100 Received: from [217.231.234.146] (helo=hp001323) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18ywsO-0004eR-00; Fri, 28 Mar 2003 17:38:44 +0100 Message-ID: <00ce01c2f549$f7addea0$0200a8c0@hp001323> From: "Heinz Prantner" To: , , References: Date: Fri, 28 Mar 2003 17:49:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Rserpool] Re: [Sigtran] New e-mail address Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit actually , this reminds me on something - for those of you I had the chance to meet on several occasions : me too, can be reached on a new address: heinz.prantner@onlinehome.de kind regards, Heinz ----- Original Message ----- From: "Tuexen Michael" To: ; ; Sent: Friday, March 28, 2003 2:37 PM Subject: [Sigtran] New e-mail address > Dear all, > > my Siemens e-mail address will no longer work. > Please use > > tuexen@fh-muenster.de > > in case you want to contact me. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 17:58:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19282 for ; Tue, 1 Apr 2003 17:58:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NM3K29655; Tue, 1 Apr 2003 18:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHFCO19816 for ; Fri, 21 Mar 2003 12:15:12 -0500 Received: from mid-2.inet.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18710 for ; Fri, 21 Mar 2003 11:56:14 -0500 (EST) Received: from [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-4.3.7-430 id ::ffff:213.92.1.193+8CFF86TskT7X; Fri, 21 Mar 2003 17:58:22 +0100 Date: Fri, 21 Mar 2003 18:01:14 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel To: WG IETF rserpool From: Harrie Hazewinkel Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [Rserpool] draft-conrad-rserpool-service-03.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI, Some comments on your draft. I do sent these to the WG-list, since it looks like this private submission is (or becomes) work of the WG. Overall, I believe this document could be integrated with the architecture document. What would the WG think of this?? Im also believe that here and there the text can be improved. I know it is work in progress, but still. Some of my main points are below. Harrie > Abstract > > RSerPool [1] is a framework to provide highly available services Is 'highly available' changed into 'high availability' not better?? In other documents and the RFC 3237 speak of 'highly reliable'. (multiple times in the document) > between clients and servers. This is achieved by grouping servers > into pools, each with an identifier and pooling policy. Three > classes of entities are defined: Pool Users (clients), Pool Elements > (servers), and Name Servers. I believe the first usage of 'clients and servers' is misleading in association to the last usage where 'clients' and 'servers' are used as text replacement for 'Pool Users' and 'Pool Elements'. I would suggest to delete 'between clients and servers'. I beleive, 'clients' and 'servers' are not the well-known definitions in this document. > This memo defines the services provided by this framework to upper > layer protocols and applications for Pool Users and Pool Elements. > It describes the service primitives that the framework provides and > describes example scenarios. > > It also describes the requirements for mapping (or adaption or > "shim") layers for a variety of transport protocols (SCTP, TCP, or > others) such that upper layer protocols and applications may use a > common framework/API to utilize the services provided. The above sentence seems grammatically not correct. (not native speaker). > 1. Introduction > > The Reliable Server Pooling architecture is defined in [1]. The > architecture provides highly available services by defining three > classes of entities: pool users (clients), pool elements (servers), > and name servers. Pool elements are grouped into server pools and > can be used by pool users via its pool name (or "handle") and can be > selected by following the pool's pool element selection policy. Why only mentioning 'Pool elements' more detailed. I suggest to do the same for the pool users and name servers. This is maybe a little bit repeating from other documents, but as introduction a small description would suffice. > Utilizing a limited set of RSerPool services provides the capability > for legacy upper layer software to use a few RSerPool services with > relatively minor modifications, and allows a broad range of > underlying transport protocols to be supported. To achieve a richer > and more complete failover model, however, a majority of the > RSerPool > services should be used, which places certain requirements and > restrictions on the transport layers that can be supported. Would it not be usefull to define compliance statements for this. > > Note that regardless of the number of service primitives actually > utilized by any given upper layer protocol, this document assumes > that the upper layer protocol/application is operating on a platform > that has a full running, implmentation of ASAP. ^^ 'implmentation' -'implementation' > > The following figure illustrates the protocol stacks when using the > RSerPool framework (Pool Element perspective shown). Note that the > mapping layer MAY be a "NULL" layer, if no control channel is > utilized and/or the data channel is not utilized (e.g. application > specific data). > > +--------------------------------------+ > | Application/Upper Layer Protocol | > +--------------------------------------+ > | RSerPool API | > |(control channel) | (data channel) | > +------------------+--------+----------+ > | ASAP layer | | > +------------------+--------+ | > | mapping/adaption layer | > +------------------+-------------------+ > | transport protocol | > +------------------+-------------------+ Provide a description of the functionality of the protocol stack. Because of the lack of the small description I don't understand exactly how the 'NULL' layer relates to the control channel as written in the text before. It seems not stacked on top of each other. > The purpose of this document is to describe: > > 1. the precise services provided by RSerPool to the upper layer, Since there are more 'upper layer's, 'upper layer' -> 'Application/Upper Layer Protocol'. > 2. the tradeoffs in choosing which services to utilize, > > 3. how applications must be designed for each of these services, > > 4. how applications written over various transports (SCTP, TCP, and > others) can be mapped into these services. I do not fully understand this. If I look at the previous stack, there are always layers between the 'Application/...' and the transport protocol. How could an application then be written for a specific transport? I also have the idea that 3. and 4. are the same. Or do you mean that 4. is to described applications that were written directly on top of a transport? > > 3. Example Application Scenarios I believe it is weird that first examples of service usages are given and then the services are defined. I suggest to move section 4. forward followed by section 3. (of course renumber :-) > > To illustrate the differences among an application without RSerPool, > an application using limited RserPool services, and an application > using a full suite of RSerPool services, this section provides an > informal description of how failover may be handled in each of these > cases. Since I am not sure what the long term target of this document is, I wonder about the text 'informal description'. > 3.1 Example Scenario for Failover Without RSerPool > > Consider a typical client/server application that does not use a > reliable server pooling framework of any kind. Typically, the > server > is specified by a DNS name. At some point, the application 'DNS name' -> 'hostname' > 4.1 Initialization 'Initialization' -> 'Initialization Service' > 4.3 Failover Callback Function I would rename this into 'Failover Callback Function' -> 'Failover service'. And as a result also change the section accordingly. > > The charter of the RSerPool Working Group specifically states that > transaction failover is out of scope for RSerPool, i.e. "if a > server > fails during processing of a transaction this transaction may be > lost. Some services may provide a way to handle the failure, but > this is not guaranteed." Accordingly, the RSerPool framework > provides a "hook" for applications to provide their own application- > specific failover mechanism(s). Immagine you read the above in 10 years, why would I care about the charter. I suggest delete it. > Business Card services: when automatic failover is used, the > exchange of business cards for rendezvous services is > automatically performed by the RSerPool framework (e.g. no > application intervention is required. Is this not a seperate section?? > > 4.5 Upper Layer/Application Level Acknowledgements > Should the acknowledgement not be part of the services? > ULP_ACK, responds to a received upper layer acknowledgement > request. Is there no ULP_NACK? (not ACK) > 4.6 RSerPool Managed Data Channel 'Channel' -> 'Service' > 5.2.1 Mappings: Mandatory Requirements > > These features MUST be present in any mapping of the RSerPool > framework mode to TCP (or any other transport protocol): Why mentioning specifically TCP. Make it generic, since also SCTP is used many times in RSerPool. Example -> These features MUST be present in any mapping of the RSerPool framework to a transport protocol: _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 17:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19304 for ; Tue, 1 Apr 2003 17:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31NNDA29889 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 18:23:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NM4K29670; Tue, 1 Apr 2003 18:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGwiO19261 for ; Fri, 28 Mar 2003 11:58:44 -0500 Received: from moutng.kundenserver.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06408; Fri, 28 Mar 2003 11:36:21 -0500 (EST) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18ywsP-00015P-00; Fri, 28 Mar 2003 17:38:45 +0100 Received: from [217.231.234.146] (helo=hp001323) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18ywsO-0004eR-00; Fri, 28 Mar 2003 17:38:44 +0100 Message-ID: <00ce01c2f549$f7addea0$0200a8c0@hp001323> From: "Heinz Prantner" To: , , References: Date: Fri, 28 Mar 2003 17:49:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Rserpool] Re: [Sigtran] New e-mail address Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit actually , this reminds me on something - for those of you I had the chance to meet on several occasions : me too, can be reached on a new address: heinz.prantner@onlinehome.de kind regards, Heinz ----- Original Message ----- From: "Tuexen Michael" To: ; ; Sent: Friday, March 28, 2003 2:37 PM Subject: [Sigtran] New e-mail address > Dear all, > > my Siemens e-mail address will no longer work. > Please use > > tuexen@fh-muenster.de > > in case you want to contact me. > > Best regards > Michael > > Michael Tuexen Tel.: +49 89 722 47210 > Siemens AG Fax: +49 89 722 48212 > ICN CP SE C 7 e-mail: Michael.Tuexen@siemens.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 17:59:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19318 for ; Tue, 1 Apr 2003 17:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31NNEf29902 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 18:23:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NM3K29655; Tue, 1 Apr 2003 18:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LHFCO19816 for ; Fri, 21 Mar 2003 12:15:12 -0500 Received: from mid-2.inet.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18710 for ; Fri, 21 Mar 2003 11:56:14 -0500 (EST) Received: from [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-4.3.7-430 id ::ffff:213.92.1.193+8CFF86TskT7X; Fri, 21 Mar 2003 17:58:22 +0100 Date: Fri, 21 Mar 2003 18:01:14 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel To: WG IETF rserpool From: Harrie Hazewinkel Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [Rserpool] draft-conrad-rserpool-service-03.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI, Some comments on your draft. I do sent these to the WG-list, since it looks like this private submission is (or becomes) work of the WG. Overall, I believe this document could be integrated with the architecture document. What would the WG think of this?? Im also believe that here and there the text can be improved. I know it is work in progress, but still. Some of my main points are below. Harrie > Abstract > > RSerPool [1] is a framework to provide highly available services Is 'highly available' changed into 'high availability' not better?? In other documents and the RFC 3237 speak of 'highly reliable'. (multiple times in the document) > between clients and servers. This is achieved by grouping servers > into pools, each with an identifier and pooling policy. Three > classes of entities are defined: Pool Users (clients), Pool Elements > (servers), and Name Servers. I believe the first usage of 'clients and servers' is misleading in association to the last usage where 'clients' and 'servers' are used as text replacement for 'Pool Users' and 'Pool Elements'. I would suggest to delete 'between clients and servers'. I beleive, 'clients' and 'servers' are not the well-known definitions in this document. > This memo defines the services provided by this framework to upper > layer protocols and applications for Pool Users and Pool Elements. > It describes the service primitives that the framework provides and > describes example scenarios. > > It also describes the requirements for mapping (or adaption or > "shim") layers for a variety of transport protocols (SCTP, TCP, or > others) such that upper layer protocols and applications may use a > common framework/API to utilize the services provided. The above sentence seems grammatically not correct. (not native speaker). > 1. Introduction > > The Reliable Server Pooling architecture is defined in [1]. The > architecture provides highly available services by defining three > classes of entities: pool users (clients), pool elements (servers), > and name servers. Pool elements are grouped into server pools and > can be used by pool users via its pool name (or "handle") and can be > selected by following the pool's pool element selection policy. Why only mentioning 'Pool elements' more detailed. I suggest to do the same for the pool users and name servers. This is maybe a little bit repeating from other documents, but as introduction a small description would suffice. > Utilizing a limited set of RSerPool services provides the capability > for legacy upper layer software to use a few RSerPool services with > relatively minor modifications, and allows a broad range of > underlying transport protocols to be supported. To achieve a richer > and more complete failover model, however, a majority of the > RSerPool > services should be used, which places certain requirements and > restrictions on the transport layers that can be supported. Would it not be usefull to define compliance statements for this. > > Note that regardless of the number of service primitives actually > utilized by any given upper layer protocol, this document assumes > that the upper layer protocol/application is operating on a platform > that has a full running, implmentation of ASAP. ^^ 'implmentation' -'implementation' > > The following figure illustrates the protocol stacks when using the > RSerPool framework (Pool Element perspective shown). Note that the > mapping layer MAY be a "NULL" layer, if no control channel is > utilized and/or the data channel is not utilized (e.g. application > specific data). > > +--------------------------------------+ > | Application/Upper Layer Protocol | > +--------------------------------------+ > | RSerPool API | > |(control channel) | (data channel) | > +------------------+--------+----------+ > | ASAP layer | | > +------------------+--------+ | > | mapping/adaption layer | > +------------------+-------------------+ > | transport protocol | > +------------------+-------------------+ Provide a description of the functionality of the protocol stack. Because of the lack of the small description I don't understand exactly how the 'NULL' layer relates to the control channel as written in the text before. It seems not stacked on top of each other. > The purpose of this document is to describe: > > 1. the precise services provided by RSerPool to the upper layer, Since there are more 'upper layer's, 'upper layer' -> 'Application/Upper Layer Protocol'. > 2. the tradeoffs in choosing which services to utilize, > > 3. how applications must be designed for each of these services, > > 4. how applications written over various transports (SCTP, TCP, and > others) can be mapped into these services. I do not fully understand this. If I look at the previous stack, there are always layers between the 'Application/...' and the transport protocol. How could an application then be written for a specific transport? I also have the idea that 3. and 4. are the same. Or do you mean that 4. is to described applications that were written directly on top of a transport? > > 3. Example Application Scenarios I believe it is weird that first examples of service usages are given and then the services are defined. I suggest to move section 4. forward followed by section 3. (of course renumber :-) > > To illustrate the differences among an application without RSerPool, > an application using limited RserPool services, and an application > using a full suite of RSerPool services, this section provides an > informal description of how failover may be handled in each of these > cases. Since I am not sure what the long term target of this document is, I wonder about the text 'informal description'. > 3.1 Example Scenario for Failover Without RSerPool > > Consider a typical client/server application that does not use a > reliable server pooling framework of any kind. Typically, the > server > is specified by a DNS name. At some point, the application 'DNS name' -> 'hostname' > 4.1 Initialization 'Initialization' -> 'Initialization Service' > 4.3 Failover Callback Function I would rename this into 'Failover Callback Function' -> 'Failover service'. And as a result also change the section accordingly. > > The charter of the RSerPool Working Group specifically states that > transaction failover is out of scope for RSerPool, i.e. "if a > server > fails during processing of a transaction this transaction may be > lost. Some services may provide a way to handle the failure, but > this is not guaranteed." Accordingly, the RSerPool framework > provides a "hook" for applications to provide their own application- > specific failover mechanism(s). Immagine you read the above in 10 years, why would I care about the charter. I suggest delete it. > Business Card services: when automatic failover is used, the > exchange of business cards for rendezvous services is > automatically performed by the RSerPool framework (e.g. no > application intervention is required. Is this not a seperate section?? > > 4.5 Upper Layer/Application Level Acknowledgements > Should the acknowledgement not be part of the services? > ULP_ACK, responds to a received upper layer acknowledgement > request. Is there no ULP_NACK? (not ACK) > 4.6 RSerPool Managed Data Channel 'Channel' -> 'Service' > 5.2.1 Mappings: Mandatory Requirements > > These features MUST be present in any mapping of the RSerPool > framework mode to TCP (or any other transport protocol): Why mentioning specifically TCP. Make it generic, since also SCTP is used many times in RSerPool. Example -> These features MUST be present in any mapping of the RSerPool framework to a transport protocol: _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 1 18:10:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20443 for ; Tue, 1 Apr 2003 18:10:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NY3K30394; Tue, 1 Apr 2003 18:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NXMK30353 for ; Tue, 1 Apr 2003 18:33:22 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20166 for ; Tue, 1 Apr 2003 18:08:54 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h31NBLWQ009576; Tue, 1 Apr 2003 16:11:21 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA17754; Tue, 1 Apr 2003 16:11:20 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h31NBIJ17934; Tue, 1 Apr 2003 17:11:18 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id RAA16614; Tue, 1 Apr 2003 17:13:20 -0600 (CST) Message-ID: <3E8A1C98.2AAC5ED1@motorola.com> Date: Tue, 01 Apr 2003 17:11:20 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phillip T. Conrad" CC: Rserpool, Michael Tuexen Subject: Re: [Rserpool] Directions for next version of service draft References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> <5.1.0.14.2.20030401143409.052ab578@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit .... > This raises an issue: I wonder if we should include language in the ENRP > draft about the "transport protocol" that is similar to that which already > exists in the ENRP draft about "policy type"... i.e. that the first PE to > register with a particular pool handle "x" is the one that determines the > policy type that all PEs must follow for pool "x". Hi, Phill, This is a good point. I agree with you that this needs to be added to ENRP. And we may need an additional error code to indicate: "sorry, your reg is rejected due to inconsistent transport type". regards, -Qiaobing > > Regards, > > Phill > > At 12:21 PM 4/1/2003 -0600, Qiaobing Xie wrote: > >Phill and I talked about this a bit more and we both felt that it might > >be even better if we use a pair of "non-descriptive" terms, such as > >"basic mode" and "enhanced mode". This is because people sometimes tends > >to stop reading any further and start to imagining the rest when they > >see a "descriptive" term :-) This often causes misunderstanding. > > > >regards, > >-Qiaobing > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 1 18:10:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20497 for ; Tue, 1 Apr 2003 18:10:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31NYgl30436 for rserpool-archive@odin.ietf.org; Tue, 1 Apr 2003 18:34:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NY3K30394; Tue, 1 Apr 2003 18:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NXMK30353 for ; Tue, 1 Apr 2003 18:33:22 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20166 for ; Tue, 1 Apr 2003 18:08:54 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h31NBLWQ009576; Tue, 1 Apr 2003 16:11:21 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA17754; Tue, 1 Apr 2003 16:11:20 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h31NBIJ17934; Tue, 1 Apr 2003 17:11:18 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id RAA16614; Tue, 1 Apr 2003 17:13:20 -0600 (CST) Message-ID: <3E8A1C98.2AAC5ED1@motorola.com> Date: Tue, 01 Apr 2003 17:11:20 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phillip T. Conrad" CC: Rserpool, Michael Tuexen Subject: Re: [Rserpool] Directions for next version of service draft References: <84858EEE-6457-11D7-8466-0030654C1AB6@lurchi.franken.de> <5.1.0.14.2.20030401143409.052ab578@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit .... > This raises an issue: I wonder if we should include language in the ENRP > draft about the "transport protocol" that is similar to that which already > exists in the ENRP draft about "policy type"... i.e. that the first PE to > register with a particular pool handle "x" is the one that determines the > policy type that all PEs must follow for pool "x". Hi, Phill, This is a good point. I agree with you that this needs to be added to ENRP. And we may need an additional error code to indicate: "sorry, your reg is rejected due to inconsistent transport type". regards, -Qiaobing > > Regards, > > Phill > > At 12:21 PM 4/1/2003 -0600, Qiaobing Xie wrote: > >Phill and I talked about this a bit more and we both felt that it might > >be even better if we use a pair of "non-descriptive" terms, such as > >"basic mode" and "enhanced mode". This is because people sometimes tends > >to stop reading any further and start to imagining the rest when they > >see a "descriptive" term :-) This often causes misunderstanding. > > > >regards, > >-Qiaobing > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 2 04:29:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01682 for ; Wed, 2 Apr 2003 04:29:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329r6K20883; Wed, 2 Apr 2003 04:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329q5K20836 for ; Wed, 2 Apr 2003 04:52:05 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01653 for ; Wed, 2 Apr 2003 04:27:25 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id 708ED2468A; Wed, 2 Apr 2003 11:26:46 +0200 (CEST) Date: Wed, 2 Apr 2003 11:23:55 +0200 Subject: Re: [Rserpool] Directions for next version of service draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Phillip Conrad , Rserpool To: Qiaobing Xie From: Michael Tuexen In-Reply-To: <3E89D8C3.8271AE3F@motorola.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Qiaobing, I have no problem in changing the name. I think we just picked some names to discuss the items. Best regards Michael On Tuesday, Apr 1, 2003, at 20:21 Europe/Berlin, Qiaobing Xie wrote: > Hi, Michael, > > Welcome back :-) > > Michael Tuexen wrote: >> ... >>> (1) In the service draft, replace "failover mode" vs. "nameservice >>> mode" with "multiplexed data channel" vs. "non multiplexed data >>> channel". >>> >> OK. > > Phill and I talked about this a bit more and we both felt that it might > be even better if we use a pair of "non-descriptive" terms, such as > "basic mode" and "enhanced mode". This is because people sometimes > tends > to stop reading any further and start to imagining the rest when they > see a "descriptive" term :-) This often causes misunderstanding. > > regards, > -Qiaobing > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 2 04:29:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01698 for ; Wed, 2 Apr 2003 04:29:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h329rmN20910 for rserpool-archive@odin.ietf.org; Wed, 2 Apr 2003 04:53:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329r6K20883; Wed, 2 Apr 2003 04:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329q5K20836 for ; Wed, 2 Apr 2003 04:52:05 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01653 for ; Wed, 2 Apr 2003 04:27:25 -0500 (EST) Received: from lurchi.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id 708ED2468A; Wed, 2 Apr 2003 11:26:46 +0200 (CEST) Date: Wed, 2 Apr 2003 11:23:55 +0200 Subject: Re: [Rserpool] Directions for next version of service draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Phillip Conrad , Rserpool To: Qiaobing Xie From: Michael Tuexen In-Reply-To: <3E89D8C3.8271AE3F@motorola.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Qiaobing, I have no problem in changing the name. I think we just picked some names to discuss the items. Best regards Michael On Tuesday, Apr 1, 2003, at 20:21 Europe/Berlin, Qiaobing Xie wrote: > Hi, Michael, > > Welcome back :-) > > Michael Tuexen wrote: >> ... >>> (1) In the service draft, replace "failover mode" vs. "nameservice >>> mode" with "multiplexed data channel" vs. "non multiplexed data >>> channel". >>> >> OK. > > Phill and I talked about this a bit more and we both felt that it might > be even better if we use a pair of "non-descriptive" terms, such as > "basic mode" and "enhanced mode". This is because people sometimes > tends > to stop reading any further and start to imagining the rest when they > see a "descriptive" term :-) This often causes misunderstanding. > > regards, > -Qiaobing > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 2 15:48:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08482 for ; Wed, 2 Apr 2003 15:48:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LDCK17067; Wed, 2 Apr 2003 16:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32L7xK16758 for ; Wed, 2 Apr 2003 16:07:59 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08353 for ; Wed, 2 Apr 2003 15:43:02 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id PAA14897; Wed, 2 Apr 2003 15:45:19 -0500 (EST) Message-Id: <5.1.0.14.2.20030402142242.029ad1c0@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 Apr 2003 15:48:03 -0500 To: Harrie Hazewinkel , IETF rserpool WG From: "Phillip T. Conrad" Subject: Re: [Rserpool] draft-conrad-rserpool-service-03.txt Cc: Phillip Conrad In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , At 06:01 PM 3/21/2003 +0100, Harrie Hazewinkel wrote: >HI, > >Some comments on your draft. I do sent these to the WG-list, >since it looks like this private submission is (or becomes) >work of the WG. Yes, with the next submission, this will become an official working group document. This was approved at the Atlanta IETF, but I have been slow to update the document due to the number of outstanding issues, as well as demands of my "day job". >Overall, I believe this document could be integrated with the >architecture document. What would the WG think of this?? This is something that has come up at both of the last two IETFs, and I think the consensus among document authors was that , yes, this is something we will consider before going to last call, but for now it is useful for pragmatic reasons to keep them separate. >> RSerPool [1] is a framework to provide highly available services > >Is 'highly available' changed into 'high availability' not better?? >In other documents and the RFC 3237 speak of 'highly reliable'. >(multiple times in the document) I agree: I like "high availabilty" better. I'll make this change in the next pass unless there are strong objections. I think that it might be good to consider adopting "high availability" in other places as well, since I think this gets more to the heart of the goal of RSerPool as I understand it than "highly reliable". >> between clients and servers. This is achieved by grouping servers >> into pools, each with an identifier and pooling policy. Three >> classes of entities are defined: Pool Users (clients), Pool Elements >> (servers), and Name Servers. > > >I believe the first usage of 'clients and servers' is misleading >in association to the last usage where 'clients' and 'servers' >are used as text replacement for 'Pool Users' and 'Pool Elements'. >I would suggest to delete 'between clients and servers'. >I beleive, 'clients' and 'servers' are not the well-known definitions >in this document. I agree; adopting your first change, and striking the words "between clients and servers" makes the first sentence read: "RSerPool [1] is a framework to provide high availability services." I'm comfortable with that. >> This memo defines the services provided by this framework to upper >> layer protocols and applications for Pool Users and Pool Elements. >> It describes the service primitives that the framework provides and >> describes example scenarios. >> >> It also describes the requirements for mapping (or adaption or >> "shim") layers for a variety of transport protocols (SCTP, TCP, or >> others) such that upper layer protocols and applications may use a >> common framework/API to utilize the services provided. > >The above sentence seems grammatically not correct. (not native speaker). Good catch: I'm not sure whether it is grammatically incorrect, but I do I agree that it is hard to read and needs to be made more clear. How about the following substitution? This document also describe how to use the RSerPool framework on top of a variety of underlying transport protocols, including SCTP, TCP and others. In some cases, mapping (or adaptation or "shim" layers) may be required in between RSerPool and the underlying transport. This document specifies requirements for these mapping layers. >>1. Introduction >> >> The Reliable Server Pooling architecture is defined in [1]. The >> architecture provides highly available services by defining three >> classes of entities: pool users (clients), pool elements (servers), >> and name servers. Pool elements are grouped into server pools and >> can be used by pool users via its pool name (or "handle") and can be >> selected by following the pool's pool element selection policy. > >Why only mentioning 'Pool elements' more detailed. I suggest to do the same >for the pool users and name servers. This is maybe a little bit repeating >from other documents, but as introduction a small description would suffice. Rather than providing more detail about "pool elements", my goal in this sentence was to briefly explain the concept of "server pool", "pool name", "handle", and "pool element selection policy". However, I would be open to including a bit more introduction about pool users and name servers if you can suggest some text. >> Utilizing a limited set of RSerPool services provides the capability >> for legacy upper layer software to use a few RSerPool services with >> relatively minor modifications, and allows a broad range of >> underlying transport protocols to be supported. To achieve a richer >> and more complete failover model, however, a majority of the RSerPool >> services should be used, which places certain requirements and >> restrictions on the transport layers that can be supported. > >Would it not be usefull to define compliance statements for this. It might, though I'm not entirely sure what a "compliance statement" in this context would look like. Can you suggest some text? >> Note that regardless of the number of service primitives actually >> utilized by any given upper layer protocol, this document assumes >> that the upper layer protocol/application is operating on a platform >> that has a full running, implmentation of ASAP. > ^^ >'implmentation' -'implementation' good catch.. I'll make a note to run the spell checker more carefully next time around. >> The following figure illustrates the protocol stacks when using the >> RSerPool framework (Pool Element perspective shown). Note that the >> mapping layer MAY be a "NULL" layer, if no control channel is >> utilized and/or the data channel is not utilized (e.g. application >> specific data). >> >> +--------------------------------------+ >> | Application/Upper Layer Protocol | >> +--------------------------------------+ >> | RSerPool API | >> |(control channel) | (data channel) | >> +------------------+--------+----------+ >> | ASAP layer | | >> +------------------+--------+ | >> | mapping/adaption layer | >> +------------------+-------------------+ >> | transport protocol | >> +------------------+-------------------+ > >Provide a description of the functionality of the protocol stack. >Because of the lack of the small description I don't understand exactly >how the 'NULL' layer relates to the control channel as written in the >text before. It seems not stacked on top of each other. I think we may end up scrapping this diagram altogether and redrawing it showing two different cases, one for basic mode, and another for enhanced mode. I agree that some additional text will be needed to explain the diagrams more clearly. >> The purpose of this document is to describe: >> >> 1. the precise services provided by RSerPool to the upper layer, > >Since there are more 'upper layer's, >'upper layer' -> 'Application/Upper Layer Protocol'. OK >> 2. the tradeoffs in choosing which services to utilize, >> >> 3. how applications must be designed for each of these services, >> >> 4. how applications written over various transports (SCTP, TCP, and >> others) can be mapped into these services. > >I do not fully understand this. If I look at the previous stack, >there are always layers between the 'Application/...' and the transport >protocol. How could an application then be written for a >specific transport? > >I also have the idea that 3. and 4. are the same. Or do you mean that 4. >is to described applications that were written directly on top of >a transport? Suppose I were to change 3 to read "how new applications should be designed..." and change (4) to insert the word "legacy", so that it reads: "how legacy applications written over various..." This was my intention, but I can see how it was not clear from the text. >>3. Example Application Scenarios > >I believe it is weird that first examples of service usages are given and then >the services are defined. I suggest to move section 4. forward followed >by section 3. (of course renumber :-) I think that the reason we didn't do it this way (and I think this may address some of your concerns below) is that one of the reasons for this document is to provide something that folks from various Application area working groups can read, and get a picture of whether RSerPool is something useful for their applications or not. This is why we provide an "informal description" (per your comment below) of various scenarios before we get into a formal description of RSerPool services. It is also one argument for keeping the document separate from the architecture, ASAP, ENRP and other documents, which are more dealing with the internal details of the technology. The services document is intended to explain what the upper layer gets by sitting on top of RSerPool, and treating it, in a sense, as a black box that provides a particular set of services. >> To illustrate the differences among an application without RSerPool, >> an application using limited RserPool services, and an application >> using a full suite of RSerPool services, this section provides an >> informal description of how failover may be handled in each of these >> cases. > >Since I am not sure what the long term target of this document is, I >wonder about the text 'informal description'. (see comments above) >>3.1 Example Scenario for Failover Without RSerPool >> >> Consider a typical client/server application that does not use a >> reliable server pooling framework of any kind. Typically, the server >> is specified by a DNS name. At some point, the application > >'DNS name' -> 'hostname' OK... as long as we still emphasize that DNS is being used to translate the hostname to an IP address, as contrasted with RSerPool translating a Pool Handle to a Pool Element Handle. While parallels can be drawn between the two processes, we also want to emphasize the differences. >>4.1 Initialization > >'Initialization' -> 'Initialization Service' OK >>4.3 Failover Callback Function > >I would rename this into 'Failover Callback Function' -> 'Failover service'. >And as a result also change the section accordingly. Calling this "failover service" would be misleading, I think, because this "failover call back function" is only one component of the complete failover service, not the whole thing. Other parts of the failover service are the message services associated with failover (including forwarding and/or retransmission to a new pool element, for example.) However, I would be ok with calling it the "failover callback service", if it is helpful to have all the services have "service" in their name. >> The charter of the RSerPool Working Group specifically states that >> transaction failover is out of scope for RSerPool, i.e. "if a server >> fails during processing of a transaction this transaction may be >> lost. Some services may provide a way to handle the failure, but >> this is not guaranteed." Accordingly, the RSerPool framework >> provides a "hook" for applications to provide their own application- >> specific failover mechanism(s). > >Immagine you read the above in 10 years, why would I care about >the charter. I suggest delete it. Good point: what does the WG think of the following text in its place? (Note that this paragraph introduces the failover callback function, possibly renamed as the "failover callback service"). Transaction failover is out-of-scope for the set of services provided by RSerPool , i.e. if a server ails during processing of a transaction this transaction may be lost. Techniques to prevent such losses (such as three phase commit) can be built on top of RSerPool, but are not part of the RSerPool framework. However, as a "hook" to assist applications that want to build their own recovery mechanisms, RSerPool provides a failover callback service. >> Business Card services: when automatic failover is used, the >> exchange of business cards for rendezvous services is >> automatically performed by the RSerPool framework (e.g. no >> application intervention is required. > >Is this not a seperate section?? I agree that the placement here is awkward... thanks for pointing that out. >>4.5 Upper Layer/Application Level Acknowledgements > >Should the acknowledgement not be part of the services? >> ULP_ACK, responds to a received upper layer acknowledgement >> request. > >Is there no ULP_NACK? (not ACK) We've decided to remove this as a service anyway, so this section will be gone in the next iteration. >>4.6 RSerPool Managed Data Channel > >'Channel' -> 'Service' Actually, I'd prefer "Services for RSerPool Managed Data Channel", since in fact, this section lists several service primitives. Also, while we're on the subject, we need to make sure that the service primitives here, and the ones in the ASAP draft are aligned with one another, something I plan to make sure we do on the next iteration. >>5.2.1 Mappings: Mandatory Requirements >> >> These features MUST be present in any mapping of the RSerPool >> framework mode to TCP (or any other transport protocol): > >Why mentioning specifically TCP. Make it generic, since also >SCTP is used many times in RSerPool. >Example -> >These features MUST be present in any mapping of the RSerPool >framework to a transport protocol: I agree with your suggested alternative text here. Overall, thanks for reading the document and providing some helpful comments. Thanks, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 2 15:49:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08507 for ; Wed, 2 Apr 2003 15:49:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32LDrh17127 for rserpool-archive@odin.ietf.org; Wed, 2 Apr 2003 16:13:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32LDCK17067; Wed, 2 Apr 2003 16:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32L7xK16758 for ; Wed, 2 Apr 2003 16:07:59 -0500 Received: from joda.cis.temple.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08353 for ; Wed, 2 Apr 2003 15:43:02 -0500 (EST) Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id PAA14897; Wed, 2 Apr 2003 15:45:19 -0500 (EST) Message-Id: <5.1.0.14.2.20030402142242.029ad1c0@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 Apr 2003 15:48:03 -0500 To: Harrie Hazewinkel , IETF rserpool WG From: "Phillip T. Conrad" Subject: Re: [Rserpool] draft-conrad-rserpool-service-03.txt Cc: Phillip Conrad In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , At 06:01 PM 3/21/2003 +0100, Harrie Hazewinkel wrote: >HI, > >Some comments on your draft. I do sent these to the WG-list, >since it looks like this private submission is (or becomes) >work of the WG. Yes, with the next submission, this will become an official working group document. This was approved at the Atlanta IETF, but I have been slow to update the document due to the number of outstanding issues, as well as demands of my "day job". >Overall, I believe this document could be integrated with the >architecture document. What would the WG think of this?? This is something that has come up at both of the last two IETFs, and I think the consensus among document authors was that , yes, this is something we will consider before going to last call, but for now it is useful for pragmatic reasons to keep them separate. >> RSerPool [1] is a framework to provide highly available services > >Is 'highly available' changed into 'high availability' not better?? >In other documents and the RFC 3237 speak of 'highly reliable'. >(multiple times in the document) I agree: I like "high availabilty" better. I'll make this change in the next pass unless there are strong objections. I think that it might be good to consider adopting "high availability" in other places as well, since I think this gets more to the heart of the goal of RSerPool as I understand it than "highly reliable". >> between clients and servers. This is achieved by grouping servers >> into pools, each with an identifier and pooling policy. Three >> classes of entities are defined: Pool Users (clients), Pool Elements >> (servers), and Name Servers. > > >I believe the first usage of 'clients and servers' is misleading >in association to the last usage where 'clients' and 'servers' >are used as text replacement for 'Pool Users' and 'Pool Elements'. >I would suggest to delete 'between clients and servers'. >I beleive, 'clients' and 'servers' are not the well-known definitions >in this document. I agree; adopting your first change, and striking the words "between clients and servers" makes the first sentence read: "RSerPool [1] is a framework to provide high availability services." I'm comfortable with that. >> This memo defines the services provided by this framework to upper >> layer protocols and applications for Pool Users and Pool Elements. >> It describes the service primitives that the framework provides and >> describes example scenarios. >> >> It also describes the requirements for mapping (or adaption or >> "shim") layers for a variety of transport protocols (SCTP, TCP, or >> others) such that upper layer protocols and applications may use a >> common framework/API to utilize the services provided. > >The above sentence seems grammatically not correct. (not native speaker). Good catch: I'm not sure whether it is grammatically incorrect, but I do I agree that it is hard to read and needs to be made more clear. How about the following substitution? This document also describe how to use the RSerPool framework on top of a variety of underlying transport protocols, including SCTP, TCP and others. In some cases, mapping (or adaptation or "shim" layers) may be required in between RSerPool and the underlying transport. This document specifies requirements for these mapping layers. >>1. Introduction >> >> The Reliable Server Pooling architecture is defined in [1]. The >> architecture provides highly available services by defining three >> classes of entities: pool users (clients), pool elements (servers), >> and name servers. Pool elements are grouped into server pools and >> can be used by pool users via its pool name (or "handle") and can be >> selected by following the pool's pool element selection policy. > >Why only mentioning 'Pool elements' more detailed. I suggest to do the same >for the pool users and name servers. This is maybe a little bit repeating >from other documents, but as introduction a small description would suffice. Rather than providing more detail about "pool elements", my goal in this sentence was to briefly explain the concept of "server pool", "pool name", "handle", and "pool element selection policy". However, I would be open to including a bit more introduction about pool users and name servers if you can suggest some text. >> Utilizing a limited set of RSerPool services provides the capability >> for legacy upper layer software to use a few RSerPool services with >> relatively minor modifications, and allows a broad range of >> underlying transport protocols to be supported. To achieve a richer >> and more complete failover model, however, a majority of the RSerPool >> services should be used, which places certain requirements and >> restrictions on the transport layers that can be supported. > >Would it not be usefull to define compliance statements for this. It might, though I'm not entirely sure what a "compliance statement" in this context would look like. Can you suggest some text? >> Note that regardless of the number of service primitives actually >> utilized by any given upper layer protocol, this document assumes >> that the upper layer protocol/application is operating on a platform >> that has a full running, implmentation of ASAP. > ^^ >'implmentation' -'implementation' good catch.. I'll make a note to run the spell checker more carefully next time around. >> The following figure illustrates the protocol stacks when using the >> RSerPool framework (Pool Element perspective shown). Note that the >> mapping layer MAY be a "NULL" layer, if no control channel is >> utilized and/or the data channel is not utilized (e.g. application >> specific data). >> >> +--------------------------------------+ >> | Application/Upper Layer Protocol | >> +--------------------------------------+ >> | RSerPool API | >> |(control channel) | (data channel) | >> +------------------+--------+----------+ >> | ASAP layer | | >> +------------------+--------+ | >> | mapping/adaption layer | >> +------------------+-------------------+ >> | transport protocol | >> +------------------+-------------------+ > >Provide a description of the functionality of the protocol stack. >Because of the lack of the small description I don't understand exactly >how the 'NULL' layer relates to the control channel as written in the >text before. It seems not stacked on top of each other. I think we may end up scrapping this diagram altogether and redrawing it showing two different cases, one for basic mode, and another for enhanced mode. I agree that some additional text will be needed to explain the diagrams more clearly. >> The purpose of this document is to describe: >> >> 1. the precise services provided by RSerPool to the upper layer, > >Since there are more 'upper layer's, >'upper layer' -> 'Application/Upper Layer Protocol'. OK >> 2. the tradeoffs in choosing which services to utilize, >> >> 3. how applications must be designed for each of these services, >> >> 4. how applications written over various transports (SCTP, TCP, and >> others) can be mapped into these services. > >I do not fully understand this. If I look at the previous stack, >there are always layers between the 'Application/...' and the transport >protocol. How could an application then be written for a >specific transport? > >I also have the idea that 3. and 4. are the same. Or do you mean that 4. >is to described applications that were written directly on top of >a transport? Suppose I were to change 3 to read "how new applications should be designed..." and change (4) to insert the word "legacy", so that it reads: "how legacy applications written over various..." This was my intention, but I can see how it was not clear from the text. >>3. Example Application Scenarios > >I believe it is weird that first examples of service usages are given and then >the services are defined. I suggest to move section 4. forward followed >by section 3. (of course renumber :-) I think that the reason we didn't do it this way (and I think this may address some of your concerns below) is that one of the reasons for this document is to provide something that folks from various Application area working groups can read, and get a picture of whether RSerPool is something useful for their applications or not. This is why we provide an "informal description" (per your comment below) of various scenarios before we get into a formal description of RSerPool services. It is also one argument for keeping the document separate from the architecture, ASAP, ENRP and other documents, which are more dealing with the internal details of the technology. The services document is intended to explain what the upper layer gets by sitting on top of RSerPool, and treating it, in a sense, as a black box that provides a particular set of services. >> To illustrate the differences among an application without RSerPool, >> an application using limited RserPool services, and an application >> using a full suite of RSerPool services, this section provides an >> informal description of how failover may be handled in each of these >> cases. > >Since I am not sure what the long term target of this document is, I >wonder about the text 'informal description'. (see comments above) >>3.1 Example Scenario for Failover Without RSerPool >> >> Consider a typical client/server application that does not use a >> reliable server pooling framework of any kind. Typically, the server >> is specified by a DNS name. At some point, the application > >'DNS name' -> 'hostname' OK... as long as we still emphasize that DNS is being used to translate the hostname to an IP address, as contrasted with RSerPool translating a Pool Handle to a Pool Element Handle. While parallels can be drawn between the two processes, we also want to emphasize the differences. >>4.1 Initialization > >'Initialization' -> 'Initialization Service' OK >>4.3 Failover Callback Function > >I would rename this into 'Failover Callback Function' -> 'Failover service'. >And as a result also change the section accordingly. Calling this "failover service" would be misleading, I think, because this "failover call back function" is only one component of the complete failover service, not the whole thing. Other parts of the failover service are the message services associated with failover (including forwarding and/or retransmission to a new pool element, for example.) However, I would be ok with calling it the "failover callback service", if it is helpful to have all the services have "service" in their name. >> The charter of the RSerPool Working Group specifically states that >> transaction failover is out of scope for RSerPool, i.e. "if a server >> fails during processing of a transaction this transaction may be >> lost. Some services may provide a way to handle the failure, but >> this is not guaranteed." Accordingly, the RSerPool framework >> provides a "hook" for applications to provide their own application- >> specific failover mechanism(s). > >Immagine you read the above in 10 years, why would I care about >the charter. I suggest delete it. Good point: what does the WG think of the following text in its place? (Note that this paragraph introduces the failover callback function, possibly renamed as the "failover callback service"). Transaction failover is out-of-scope for the set of services provided by RSerPool , i.e. if a server ails during processing of a transaction this transaction may be lost. Techniques to prevent such losses (such as three phase commit) can be built on top of RSerPool, but are not part of the RSerPool framework. However, as a "hook" to assist applications that want to build their own recovery mechanisms, RSerPool provides a failover callback service. >> Business Card services: when automatic failover is used, the >> exchange of business cards for rendezvous services is >> automatically performed by the RSerPool framework (e.g. no >> application intervention is required. > >Is this not a seperate section?? I agree that the placement here is awkward... thanks for pointing that out. >>4.5 Upper Layer/Application Level Acknowledgements > >Should the acknowledgement not be part of the services? >> ULP_ACK, responds to a received upper layer acknowledgement >> request. > >Is there no ULP_NACK? (not ACK) We've decided to remove this as a service anyway, so this section will be gone in the next iteration. >>4.6 RSerPool Managed Data Channel > >'Channel' -> 'Service' Actually, I'd prefer "Services for RSerPool Managed Data Channel", since in fact, this section lists several service primitives. Also, while we're on the subject, we need to make sure that the service primitives here, and the ones in the ASAP draft are aligned with one another, something I plan to make sure we do on the next iteration. >>5.2.1 Mappings: Mandatory Requirements >> >> These features MUST be present in any mapping of the RSerPool >> framework mode to TCP (or any other transport protocol): > >Why mentioning specifically TCP. Make it generic, since also >SCTP is used many times in RSerPool. >Example -> >These features MUST be present in any mapping of the RSerPool >framework to a transport protocol: I agree with your suggested alternative text here. Overall, thanks for reading the document and providing some helpful comments. Thanks, Phill _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 2 16:51:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11286 for ; Wed, 2 Apr 2003 16:51:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MFUK23888; Wed, 2 Apr 2003 17:15:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329ngK20713 for ; Wed, 2 Apr 2003 04:49:42 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01603 for ; Wed, 2 Apr 2003 04:25:02 -0500 (EST) Received: from micmac.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id E2F4324687 for ; Wed, 2 Apr 2003 11:24:22 +0200 (CEST) Date: Wed, 2 Apr 2003 11:21:32 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [Rserpool] Directions for next version of service draft From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: rserpool@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7E2EE011-64EC-11D7-BC64-0030654C1AB6@micmac.franken.de> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just forgot the mailing list... Begin forwarded message: > From: Michael Tuexen > Date: Wed Apr 2, 2003 11:20:45 Europe/Berlin > To: "Phillip T. Conrad" > Subject: Re: [Rserpool] Directions for next version of service draft > > Hi Phil, > > I agree with you and prefer also that solution. I just was not sure > if this is the common understanding. > > Best regards > Michael > > On Tuesday, Apr 1, 2003, at 19:30 Europe/Berlin, Phillip T. Conrad > wrote: > >> Hi Michael: >> Thanks for responding to request for "rough consensus" in my >> previous note on several points related to the next version of the >> service draft. In your reply, you indicated acceptance of the >> suggested directions, with just one question: I've included the >> context for that question, and answered it below. >> >> At 05:35 PM 4/1/2003 +0200, Michael Tuexen wrote (in part): >>> Phil, >>> see my comments below. >> ... >>>> Here are some suggested directions for RSerPool: >>>> >>>> To the working group: do we have rough consensus on these points? >>>> I and others (Peter, Randy, Qiaobing et al) will ask for rough >>>> consensus on these points in the working group meeting later today >>>> in San Francisco... and for the sake of those that are NOT in the >>>> meeting today, please consider this email as your opportunity to >>>> express support, dissent, or to ask for further clarification on >>>> the points below. >> ... >>>> (3) In general: No multiple transport registrations: you either >>>> >>>> (a) register the transport address of either an SCTP or TCP (but >>>> not both) multiplexed control and data over a single transport >>>> association/connection. (Note: you _can_ register both, but if you >>>> do so, they should be in different pools, preserving the principle >>>> that all PE's in a pool should be functionally equivalent, >>>> including all using the same transport protocol to provide >>>> service.) >>>> >>>> (b) you register the transport address of a data channel only, not >>>> managed by rserpool (and do without the services that would be >>>> provided by a control channel.) >>> Is this the same for all PE in a Pool? >> >> To my understanding, yes: the notion is that all PEs in a given pool >> should behave the same way. That is one of the architectural >> principles we are trying to emphasize as we move forward, for the >> sake of simplicity. So, I think we should emphasize in the various >> drafts that for a given pool, all PEs either behave according to the >> rules of (a) above, or all PEs behave according the rules of (b). >> >> What we gain by this direction is simplicity. We lose some >> flexibility (in particular, we lose the ability to support some of >> the scenarios below), but I think the sense of the group was that >> none of these things are terribly important; i.e. we do not have >> application scenarios that require these particular capabilties. >> Here are some of the capabilities we give up: >> >> (1) the flexibility to failing over among a group of PEs, where some >> have a control channel, and others don't. >> (2) the flexibility to have a data channel on one transport address >> and protocol, and a control channel on a different transport address >> and perhaps a different transport protocol. >> >> I hope this explanation is helpful, and I invite comments or >> questions from anyone on the list. >> >> Regards, >> Phill >> >> > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 2 16:51:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11305 for ; Wed, 2 Apr 2003 16:51:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32MG8623947 for rserpool-archive@odin.ietf.org; Wed, 2 Apr 2003 17:16:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MFUK23888; Wed, 2 Apr 2003 17:15:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h329ngK20713 for ; Wed, 2 Apr 2003 04:49:42 -0500 Received: from ilsa.franken.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01603 for ; Wed, 2 Apr 2003 04:25:02 -0500 (EST) Received: from micmac.franken.de (unknown [194.95.73.172]) by ilsa.franken.de (Postfix) with ESMTP id E2F4324687 for ; Wed, 2 Apr 2003 11:24:22 +0200 (CEST) Date: Wed, 2 Apr 2003 11:21:32 +0200 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: [Rserpool] Directions for next version of service draft From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: rserpool@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7E2EE011-64EC-11D7-BC64-0030654C1AB6@micmac.franken.de> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just forgot the mailing list... Begin forwarded message: > From: Michael Tuexen > Date: Wed Apr 2, 2003 11:20:45 Europe/Berlin > To: "Phillip T. Conrad" > Subject: Re: [Rserpool] Directions for next version of service draft > > Hi Phil, > > I agree with you and prefer also that solution. I just was not sure > if this is the common understanding. > > Best regards > Michael > > On Tuesday, Apr 1, 2003, at 19:30 Europe/Berlin, Phillip T. Conrad > wrote: > >> Hi Michael: >> Thanks for responding to request for "rough consensus" in my >> previous note on several points related to the next version of the >> service draft. In your reply, you indicated acceptance of the >> suggested directions, with just one question: I've included the >> context for that question, and answered it below. >> >> At 05:35 PM 4/1/2003 +0200, Michael Tuexen wrote (in part): >>> Phil, >>> see my comments below. >> ... >>>> Here are some suggested directions for RSerPool: >>>> >>>> To the working group: do we have rough consensus on these points? >>>> I and others (Peter, Randy, Qiaobing et al) will ask for rough >>>> consensus on these points in the working group meeting later today >>>> in San Francisco... and for the sake of those that are NOT in the >>>> meeting today, please consider this email as your opportunity to >>>> express support, dissent, or to ask for further clarification on >>>> the points below. >> ... >>>> (3) In general: No multiple transport registrations: you either >>>> >>>> (a) register the transport address of either an SCTP or TCP (but >>>> not both) multiplexed control and data over a single transport >>>> association/connection. (Note: you _can_ register both, but if you >>>> do so, they should be in different pools, preserving the principle >>>> that all PE's in a pool should be functionally equivalent, >>>> including all using the same transport protocol to provide >>>> service.) >>>> >>>> (b) you register the transport address of a data channel only, not >>>> managed by rserpool (and do without the services that would be >>>> provided by a control channel.) >>> Is this the same for all PE in a Pool? >> >> To my understanding, yes: the notion is that all PEs in a given pool >> should behave the same way. That is one of the architectural >> principles we are trying to emphasize as we move forward, for the >> sake of simplicity. So, I think we should emphasize in the various >> drafts that for a given pool, all PEs either behave according to the >> rules of (a) above, or all PEs behave according the rules of (b). >> >> What we gain by this direction is simplicity. We lose some >> flexibility (in particular, we lose the ability to support some of >> the scenarios below), but I think the sense of the group was that >> none of these things are terribly important; i.e. we do not have >> application scenarios that require these particular capabilties. >> Here are some of the capabilities we give up: >> >> (1) the flexibility to failing over among a group of PEs, where some >> have a control channel, and others don't. >> (2) the flexibility to have a data channel on one transport address >> and protocol, and a control channel on a different transport address >> and perhaps a different transport protocol. >> >> I hope this explanation is helpful, and I invite comments or >> questions from anyone on the list. >> >> Regards, >> Phill >> >> > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 2 19:09:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18267 for ; Wed, 2 Apr 2003 19:09:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330B5K03733; Wed, 2 Apr 2003 19:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330AkK03685 for ; Wed, 2 Apr 2003 19:10:46 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18247 for ; Wed, 2 Apr 2003 19:08:15 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h330AgqP021150; Wed, 2 Apr 2003 17:10:42 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA24309; Wed, 2 Apr 2003 17:10:12 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h3307VJ00616; Wed, 2 Apr 2003 18:07:31 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id SAA17761; Wed, 2 Apr 2003 18:09:32 -0600 (CST) Message-ID: <3E8B7B50.BF421814@motorola.com> Date: Wed, 02 Apr 2003 18:07:44 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phillip T. Conrad" CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Phill, Please see my comments below... "Phillip T. Conrad" wrote: ... > However, Qiaobing pointed out, correctly, that you do not need the control > channel to do message failover (now that application layer acks are gone); > all you need is someway to tell the RSerPool API how to map the the > RSerPool data transmission primitives (e.g. the equivalent in your > particular API of the data.send primitive) to the transport protocol in > question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping > is so trivial that it almost doesn't even need to be mentioned, and if we > provide it, this will allow failover of any message that has not yet been > put on the wire. > > Of course, except for with SCTP, you will not get any message failover of > messages that have already been submitted to the transport layer and were > never transmitted, since no protocol other than SCTP supports "retrieval" > (note that because application layer acks were removed, you don't even get > that with the TCP mapping layer anymore.) To better describe this, we probably should use 2 separate terms here: "Session Failover (SF)" - upon a failure of the current PE, the action of the PU picking up an alternate PE in the pool and carrying on the comm session btw the pool user and the pool. "Message Failover (MF)" - upon a failure of the current PE, the action of session failover, PLUS, in a best-effort fashion, re-sending un-acked messages to the new PE. SF is the key and a fundamental objective of RSERPOOL. This is expressed all over the requirement RFC (all the examples are meant to show this benefit). It has little to do with the control channel. But how well session failover can be performed depends on the transport - with well configured SCTP as transport, SF can be fast and smooth; with TCP, SF may come with long latency; with UDP, SF can only happen when the app assists in reachability monitoring. MF is something desirable but not fundamental to RSERPOOL. This is why we stated "transaction integrity not guaranteed" when we worked on the requirement. Similarly, MF has little to do with the control channel. It mainly depends on whether the transport layer provides data retrieval services. With SCTP, your chance of having data retrieval is good. With TCP or UDP, you probably will be out of luck. What difference the control channel (as currently defined for Cookie and B-card) makes is to allow a finer control on the failover transition. With B-card, you can select the best candidate PE; with Cookie, you can better prepare the new PE by passing some app state info. But none of those will play a role in MF. If you are talking about TCP mapping in particular, I think we need to point out that TCP mapping != control channel, nor it means MF. In the TCP draft, if I read it right, PPID and TSN are both optional. This means that if I turn off the PPID then there won't be a control channel. Moreover, if I turn off the TSN, then there won't be an ACK service that can create MF possibility. > My question is this: how often would it be, for example, in UDP, that you > would have any messages that had not yet been put on the wire? The only > time I can imagine an RSerPool implementation not putting something on the > wire immediately is if the underlying transport layer socket is not > writable (determined for example via a select() system call in the sockets > API, or an EWOULDBLOCK error, etc.) My understanding is that > this typically happens when the transport endpoint is restricted because > of cwnd or rwnd, and then also runs out of buffer space, and the socket > runs out of buffer space too. > > This could realistically happen with SCTP or TCP particularly if the > application on the peer end is slow to read and process data. But how > realistic is it for UDP? My guess is that is will never happen, since UDP > is never blocked due to cwnd or rwnd. > > So, I while I can concede Qiaobing's point that a message channel is not > necessary to provide I'm not sure there is a practical need to provide for > message failover in basic mode. I'd like to keep basic mode as basic as > possible, just for cleanness of the architecture. Yes. This (or similar reasoning) was what led many in the requirement team to believe MF should not be made a hard requirement. E.g., I don't think there are many UDP apps need MF service. > I'd like to invite the rest of the working group to comment on these two > possibilities: should we > > (1) allow for message failover in basic mode for messages not yet put on > the wire (which means, conceivably, any arbitrary transport protocol)? > > OR > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? This means, if my PU uses SCTP in basic mode, my PU is disallowed to use data retrieval provided by SCTP? Why should I be restricted like this? You can only convince my if you can show me that either doing so is harmful or it is useless for all applications. regards, -Qiaobing > > Thanks, > Phill > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 2 19:09:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18293 for ; Wed, 2 Apr 2003 19:09:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h330BhZ03795 for rserpool-archive@odin.ietf.org; Wed, 2 Apr 2003 19:11:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330B5K03733; Wed, 2 Apr 2003 19:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330AkK03685 for ; Wed, 2 Apr 2003 19:10:46 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18247 for ; Wed, 2 Apr 2003 19:08:15 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h330AgqP021150; Wed, 2 Apr 2003 17:10:42 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA24309; Wed, 2 Apr 2003 17:10:12 -0700 (MST)] Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h3307VJ00616; Wed, 2 Apr 2003 18:07:31 -0600 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id SAA17761; Wed, 2 Apr 2003 18:09:32 -0600 (CST) Message-ID: <3E8B7B50.BF421814@motorola.com> Date: Wed, 02 Apr 2003 18:07:44 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phillip T. Conrad" CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Phill, Please see my comments below... "Phillip T. Conrad" wrote: ... > However, Qiaobing pointed out, correctly, that you do not need the control > channel to do message failover (now that application layer acks are gone); > all you need is someway to tell the RSerPool API how to map the the > RSerPool data transmission primitives (e.g. the equivalent in your > particular API of the data.send primitive) to the transport protocol in > question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping > is so trivial that it almost doesn't even need to be mentioned, and if we > provide it, this will allow failover of any message that has not yet been > put on the wire. > > Of course, except for with SCTP, you will not get any message failover of > messages that have already been submitted to the transport layer and were > never transmitted, since no protocol other than SCTP supports "retrieval" > (note that because application layer acks were removed, you don't even get > that with the TCP mapping layer anymore.) To better describe this, we probably should use 2 separate terms here: "Session Failover (SF)" - upon a failure of the current PE, the action of the PU picking up an alternate PE in the pool and carrying on the comm session btw the pool user and the pool. "Message Failover (MF)" - upon a failure of the current PE, the action of session failover, PLUS, in a best-effort fashion, re-sending un-acked messages to the new PE. SF is the key and a fundamental objective of RSERPOOL. This is expressed all over the requirement RFC (all the examples are meant to show this benefit). It has little to do with the control channel. But how well session failover can be performed depends on the transport - with well configured SCTP as transport, SF can be fast and smooth; with TCP, SF may come with long latency; with UDP, SF can only happen when the app assists in reachability monitoring. MF is something desirable but not fundamental to RSERPOOL. This is why we stated "transaction integrity not guaranteed" when we worked on the requirement. Similarly, MF has little to do with the control channel. It mainly depends on whether the transport layer provides data retrieval services. With SCTP, your chance of having data retrieval is good. With TCP or UDP, you probably will be out of luck. What difference the control channel (as currently defined for Cookie and B-card) makes is to allow a finer control on the failover transition. With B-card, you can select the best candidate PE; with Cookie, you can better prepare the new PE by passing some app state info. But none of those will play a role in MF. If you are talking about TCP mapping in particular, I think we need to point out that TCP mapping != control channel, nor it means MF. In the TCP draft, if I read it right, PPID and TSN are both optional. This means that if I turn off the PPID then there won't be a control channel. Moreover, if I turn off the TSN, then there won't be an ACK service that can create MF possibility. > My question is this: how often would it be, for example, in UDP, that you > would have any messages that had not yet been put on the wire? The only > time I can imagine an RSerPool implementation not putting something on the > wire immediately is if the underlying transport layer socket is not > writable (determined for example via a select() system call in the sockets > API, or an EWOULDBLOCK error, etc.) My understanding is that > this typically happens when the transport endpoint is restricted because > of cwnd or rwnd, and then also runs out of buffer space, and the socket > runs out of buffer space too. > > This could realistically happen with SCTP or TCP particularly if the > application on the peer end is slow to read and process data. But how > realistic is it for UDP? My guess is that is will never happen, since UDP > is never blocked due to cwnd or rwnd. > > So, I while I can concede Qiaobing's point that a message channel is not > necessary to provide I'm not sure there is a practical need to provide for > message failover in basic mode. I'd like to keep basic mode as basic as > possible, just for cleanness of the architecture. Yes. This (or similar reasoning) was what led many in the requirement team to believe MF should not be made a hard requirement. E.g., I don't think there are many UDP apps need MF service. > I'd like to invite the rest of the working group to comment on these two > possibilities: should we > > (1) allow for message failover in basic mode for messages not yet put on > the wire (which means, conceivably, any arbitrary transport protocol)? > > OR > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? This means, if my PU uses SCTP in basic mode, my PU is disallowed to use data retrieval provided by SCTP? Why should I be restricted like this? You can only convince my if you can show me that either doing so is harmful or it is useless for all applications. regards, -Qiaobing > > Thanks, > Phill > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Apr 3 00:00:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24449 for ; Thu, 3 Apr 2003 00:00:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33527K25499; Thu, 3 Apr 2003 00:02:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3351kK25481 for ; Thu, 3 Apr 2003 00:01:46 -0500 Received: from sccrmhc02.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24417 for ; Wed, 2 Apr 2003 23:59:09 -0500 (EST) Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200304030501370020077ee6e>; Thu, 3 Apr 2003 05:01:37 +0000 Message-ID: <3E8BBFD8.7DC572AD@ieee.org> Date: Wed, 02 Apr 2003 23:00:08 -0600 From: Peter Lei X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comments inline... Qiaobing Xie wrote: > > Hi, Phill, > > Please see my comments below... > > "Phillip T. Conrad" wrote: > ... > > However, Qiaobing pointed out, correctly, that you do not need the control > > channel to do message failover (now that application layer acks are gone); > > all you need is someway to tell the RSerPool API how to map the the > > RSerPool data transmission primitives (e.g. the equivalent in your > > particular API of the data.send primitive) to the transport protocol in > > question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping > > is so trivial that it almost doesn't even need to be mentioned, and if we > > provide it, this will allow failover of any message that has not yet been > > put on the wire. > > > > Of course, except for with SCTP, you will not get any message failover of > > messages that have already been submitted to the transport layer and were > > never transmitted, since no protocol other than SCTP supports "retrieval" > > (note that because application layer acks were removed, you don't even get > > that with the TCP mapping layer anymore.) As in it is no longer a MUST / SHOULD requirement. TCP mapping layer MAY implement buffering for retrival. > To better describe this, we probably should use 2 separate terms here: > > "Session Failover (SF)" - upon a failure of the current PE, the action > of the PU picking up an alternate PE in the pool and carrying on the > comm session btw the pool user and the pool. > > "Message Failover (MF)" - upon a failure of the current PE, the action > of session failover, PLUS, in a best-effort fashion, re-sending un-acked > messages to the new PE. > > SF is the key and a fundamental objective of RSERPOOL. This is expressed > all over the requirement RFC (all the examples are meant to show this > benefit). It has little to do with the control channel. But how well > session failover can be performed depends on the transport - with well > configured SCTP as transport, SF can be fast and smooth; with TCP, SF > may come with long latency; with UDP, SF can only happen when the app > assists in reachability monitoring. > > MF is something desirable but not fundamental to RSERPOOL. This is why > we stated "transaction integrity not guaranteed" when we worked on the > requirement. Similarly, MF has little to do with the control channel. It > mainly depends on whether the transport layer provides data retrieval > services. With SCTP, your chance of having data retrieval is good. With > TCP or UDP, you probably will be out of luck. > > What difference the control channel (as currently defined for Cookie and > B-card) makes is to allow a finer control on the failover transition. > With B-card, you can select the best candidate PE; with Cookie, you can > better prepare the new PE by passing some app state info. But none of > those will play a role in MF. Agree up to here... > If you are talking about TCP mapping in particular, I think we need to > point out that TCP mapping != control channel, nor it means MF. In the > TCP draft, if I read it right, PPID and TSN are both optional. This > means that if I turn off the PPID then there won't be a control channel. > Moreover, if I turn off the TSN, then there won't be an ACK service that > can create MF possibility. The TCP mapping draft does state that PPID is required for multiplexed control and data (e.g. control = ASAP PPID); as of San Fran, only this multiplexed control and data would be used now anyways, right? I had intended on making this change (non-optional PPID) in the next pass. Also in San Fran, I indicated that we would note in the draft that there is no requirement for implementing a buffer for message retrieval, but MAY be desirable; certainly without buffering, MF cannot be performed (and as you point out, TSN is also needed then). While the fields are optional, they are meant to be implemented... they provide the necessary hooks in order to provide for SF and w/buffering, MF. Recall that the motivation for the TCP mapping draft, in particular, was to allow non-SCTP transport; there are additional features like heartbeating that help SF as compared to plain TCP. > > My question is this: how often would it be, for example, in UDP, that you > > would have any messages that had not yet been put on the wire? The only > > time I can imagine an RSerPool implementation not putting something on the > > wire immediately is if the underlying transport layer socket is not > > writable (determined for example via a select() system call in the sockets > > API, or an EWOULDBLOCK error, etc.) My understanding is that > > this typically happens when the transport endpoint is restricted because > > of cwnd or rwnd, and then also runs out of buffer space, and the socket > > runs out of buffer space too. > > > > This could realistically happen with SCTP or TCP particularly if the > > application on the peer end is slow to read and process data. But how > > realistic is it for UDP? My guess is that is will never happen, since UDP > > is never blocked due to cwnd or rwnd. > > > > So, I while I can concede Qiaobing's point that a message channel is not > > necessary to provide I'm not sure there is a practical need to provide for > > message failover in basic mode. I'd like to keep basic mode as basic as > > possible, just for cleanness of the architecture. > > Yes. This (or similar reasoning) was what led many in the requirement > team to believe MF should not be made a hard requirement. E.g., I don't > think there are many UDP apps need MF service. > > > I'd like to invite the rest of the working group to comment on these two > > possibilities: should we > > > > (1) allow for message failover in basic mode for messages not yet put on > > the wire (which means, conceivably, any arbitrary transport protocol)? > > > > OR > > > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? > > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > data retrieval provided by SCTP? Why should I be restricted like this? > You can only convince my if you can show me that either doing so is > harmful or it is useless for all applications. I'm not sure I follow your scenario... the PU is not "disallowed" from using SCTP retrieval... it's just not "automatically" done on behalf of the PU by the rserpool framework / ASAP; the PU is certainly able to retrieve and re-send "manually" if it wishes upon SF. thanks, --peter > regards, > -Qiaobing > > > > > Thanks, > > Phill > > > > _______________________________________________ > > rserpool mailing list > > rserpool@ietf.org > > https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Apr 3 00:00:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24482 for ; Thu, 3 Apr 2003 00:00:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3352kh25521 for rserpool-archive@odin.ietf.org; Thu, 3 Apr 2003 00:02:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33527K25499; Thu, 3 Apr 2003 00:02:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3351kK25481 for ; Thu, 3 Apr 2003 00:01:46 -0500 Received: from sccrmhc02.attbi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24417 for ; Wed, 2 Apr 2003 23:59:09 -0500 (EST) Received: from ieee.org (12-248-116-44.client.attbi.com[12.248.116.44]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200304030501370020077ee6e>; Thu, 3 Apr 2003 05:01:37 +0000 Message-ID: <3E8BBFD8.7DC572AD@ieee.org> Date: Wed, 02 Apr 2003 23:00:08 -0600 From: Peter Lei X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comments inline... Qiaobing Xie wrote: > > Hi, Phill, > > Please see my comments below... > > "Phillip T. Conrad" wrote: > ... > > However, Qiaobing pointed out, correctly, that you do not need the control > > channel to do message failover (now that application layer acks are gone); > > all you need is someway to tell the RSerPool API how to map the the > > RSerPool data transmission primitives (e.g. the equivalent in your > > particular API of the data.send primitive) to the transport protocol in > > question (whether that be SCTP, TCP, UDP, DCCP or whatever). This mapping > > is so trivial that it almost doesn't even need to be mentioned, and if we > > provide it, this will allow failover of any message that has not yet been > > put on the wire. > > > > Of course, except for with SCTP, you will not get any message failover of > > messages that have already been submitted to the transport layer and were > > never transmitted, since no protocol other than SCTP supports "retrieval" > > (note that because application layer acks were removed, you don't even get > > that with the TCP mapping layer anymore.) As in it is no longer a MUST / SHOULD requirement. TCP mapping layer MAY implement buffering for retrival. > To better describe this, we probably should use 2 separate terms here: > > "Session Failover (SF)" - upon a failure of the current PE, the action > of the PU picking up an alternate PE in the pool and carrying on the > comm session btw the pool user and the pool. > > "Message Failover (MF)" - upon a failure of the current PE, the action > of session failover, PLUS, in a best-effort fashion, re-sending un-acked > messages to the new PE. > > SF is the key and a fundamental objective of RSERPOOL. This is expressed > all over the requirement RFC (all the examples are meant to show this > benefit). It has little to do with the control channel. But how well > session failover can be performed depends on the transport - with well > configured SCTP as transport, SF can be fast and smooth; with TCP, SF > may come with long latency; with UDP, SF can only happen when the app > assists in reachability monitoring. > > MF is something desirable but not fundamental to RSERPOOL. This is why > we stated "transaction integrity not guaranteed" when we worked on the > requirement. Similarly, MF has little to do with the control channel. It > mainly depends on whether the transport layer provides data retrieval > services. With SCTP, your chance of having data retrieval is good. With > TCP or UDP, you probably will be out of luck. > > What difference the control channel (as currently defined for Cookie and > B-card) makes is to allow a finer control on the failover transition. > With B-card, you can select the best candidate PE; with Cookie, you can > better prepare the new PE by passing some app state info. But none of > those will play a role in MF. Agree up to here... > If you are talking about TCP mapping in particular, I think we need to > point out that TCP mapping != control channel, nor it means MF. In the > TCP draft, if I read it right, PPID and TSN are both optional. This > means that if I turn off the PPID then there won't be a control channel. > Moreover, if I turn off the TSN, then there won't be an ACK service that > can create MF possibility. The TCP mapping draft does state that PPID is required for multiplexed control and data (e.g. control = ASAP PPID); as of San Fran, only this multiplexed control and data would be used now anyways, right? I had intended on making this change (non-optional PPID) in the next pass. Also in San Fran, I indicated that we would note in the draft that there is no requirement for implementing a buffer for message retrieval, but MAY be desirable; certainly without buffering, MF cannot be performed (and as you point out, TSN is also needed then). While the fields are optional, they are meant to be implemented... they provide the necessary hooks in order to provide for SF and w/buffering, MF. Recall that the motivation for the TCP mapping draft, in particular, was to allow non-SCTP transport; there are additional features like heartbeating that help SF as compared to plain TCP. > > My question is this: how often would it be, for example, in UDP, that you > > would have any messages that had not yet been put on the wire? The only > > time I can imagine an RSerPool implementation not putting something on the > > wire immediately is if the underlying transport layer socket is not > > writable (determined for example via a select() system call in the sockets > > API, or an EWOULDBLOCK error, etc.) My understanding is that > > this typically happens when the transport endpoint is restricted because > > of cwnd or rwnd, and then also runs out of buffer space, and the socket > > runs out of buffer space too. > > > > This could realistically happen with SCTP or TCP particularly if the > > application on the peer end is slow to read and process data. But how > > realistic is it for UDP? My guess is that is will never happen, since UDP > > is never blocked due to cwnd or rwnd. > > > > So, I while I can concede Qiaobing's point that a message channel is not > > necessary to provide I'm not sure there is a practical need to provide for > > message failover in basic mode. I'd like to keep basic mode as basic as > > possible, just for cleanness of the architecture. > > Yes. This (or similar reasoning) was what led many in the requirement > team to believe MF should not be made a hard requirement. E.g., I don't > think there are many UDP apps need MF service. > > > I'd like to invite the rest of the working group to comment on these two > > possibilities: should we > > > > (1) allow for message failover in basic mode for messages not yet put on > > the wire (which means, conceivably, any arbitrary transport protocol)? > > > > OR > > > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? > > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > data retrieval provided by SCTP? Why should I be restricted like this? > You can only convince my if you can show me that either doing so is > harmful or it is useless for all applications. I'm not sure I follow your scenario... the PU is not "disallowed" from using SCTP retrieval... it's just not "automatically" done on behalf of the PU by the rserpool framework / ASAP; the PU is certainly able to retrieve and re-send "manually" if it wishes upon SF. thanks, --peter > regards, > -Qiaobing > > > > > Thanks, > > Phill > > > > _______________________________________________ > > rserpool mailing list > > rserpool@ietf.org > > https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Apr 3 14:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07347 for ; Thu, 3 Apr 2003 14:06:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J8MK18137; Thu, 3 Apr 2003 14:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J7vK18036 for ; Thu, 3 Apr 2003 14:07:57 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07308 for ; Thu, 3 Apr 2003 14:05:03 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33J7SZ07336 for ; Thu, 3 Apr 2003 13:07:28 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Apr 2003 13:07:22 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 13:07:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Apr 2003 13:07:21 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81101222C77@daebe007.americas.nokia.com> Thread-Topic: Rserpool Conference call details for Tuesday, March 4 at 10AM EST USA Thread-Index: AcLhkMw0Cq1j8O+KSZqmfJs/PQdMYAW75LQAAGTkDDA= To: X-OriginalArrivalTime: 03 Apr 2003 19:07:21.0855 (UTC) FILETIME=[411DB0F0:01C2FA14] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33J7vK18037 Subject: [Rserpool] Reminder: Rserpool Conference call details for Friday, April 4 at 10AM EST USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team conference call will be Friday, April 4 at 10AM EST USA Conference call details for Friday, April 4 at 10AM EST USA DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Apr 3 14:06:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07382 for ; Thu, 3 Apr 2003 14:06:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33J95H18188 for rserpool-archive@odin.ietf.org; Thu, 3 Apr 2003 14:09:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J8MK18137; Thu, 3 Apr 2003 14:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33J7vK18036 for ; Thu, 3 Apr 2003 14:07:57 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07308 for ; Thu, 3 Apr 2003 14:05:03 -0500 (EST) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33J7SZ07336 for ; Thu, 3 Apr 2003 13:07:28 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Apr 2003 13:07:22 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 13:07:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Apr 2003 13:07:21 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81101222C77@daebe007.americas.nokia.com> Thread-Topic: Rserpool Conference call details for Tuesday, March 4 at 10AM EST USA Thread-Index: AcLhkMw0Cq1j8O+KSZqmfJs/PQdMYAW75LQAAGTkDDA= To: X-OriginalArrivalTime: 03 Apr 2003 19:07:21.0855 (UTC) FILETIME=[411DB0F0:01C2FA14] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33J7vK18037 Subject: [Rserpool] Reminder: Rserpool Conference call details for Friday, April 4 at 10AM EST USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team conference call will be Friday, April 4 at 10AM EST USA Conference call details for Friday, April 4 at 10AM EST USA DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Apr 3 15:44:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12820 for ; Thu, 3 Apr 2003 15:44:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KkNK28050; Thu, 3 Apr 2003 15:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KjcK27996 for ; Thu, 3 Apr 2003 15:45:38 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12771 for ; Thu, 3 Apr 2003 15:42:42 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h33KigR7021739 for ; Thu, 3 Apr 2003 13:44:42 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA25676 for ; Thu, 3 Apr 2003 13:42:38 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DAN22F8; Thu, 3 Apr 2003 14:45:09 -0600 Message-ID: <3E8C9CEF.93604617@motorola.com> Date: Thu, 03 Apr 2003 14:43:27 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lei CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Peter, Peter Lei wrote: ... > > As in it is no longer a MUST / SHOULD requirement. TCP mapping layer > MAY implement buffering for retrival. That sounds good. > > If you are talking about TCP mapping in particular, I think we need to > > point out that TCP mapping != control channel, nor it means MF. In the > > TCP draft, if I read it right, PPID and TSN are both optional. This > > means that if I turn off the PPID then there won't be a control channel. > > Moreover, if I turn off the TSN, then there won't be an ACK service that > > can create MF possibility. > > The TCP mapping draft does state that PPID is required for multiplexed > control and data (e.g. control = ASAP PPID); as of San Fran, only this > multiplexed control and data would be used now anyways, right? I had > intended on making this change (non-optional PPID) in the next pass. > > Also in San Fran, I indicated that we would note in the draft that there > is no requirement for implementing a buffer for message retrieval, but > MAY be desirable; certainly without buffering, MF cannot be performed > (and as you point out, TSN is also needed then). I'd agree with the above. > > While the fields are optional, they are meant to be implemented... they > provide the necessary hooks in order to provide for SF and w/buffering, > MF. Recall that the motivation for the TCP mapping draft, in particular, > was to allow non-SCTP transport; there are additional features like > heartbeating that help SF as compared to plain TCP. I understand they are mandatory to impl but optional to use. This is why I used terms like "turn on/off" in my email. This in fact means that when a PU using TCP mapping start a session with a pool, it has the choice of whether to use a ctl-channel or not. I think this flexibility is good. The point I was trying to make in my earlier email is that using TCP mapping does not automatically mean that the session will always have a ctl-channel or MF. I think we are basically in agreement here :-) .... > > > I'd like to invite the rest of the working group to comment on these two > > > possibilities: should we > > > > > > (1) allow for message failover in basic mode for messages not yet put on > > > the wire (which means, conceivably, any arbitrary transport protocol)? > > > > > > OR > > > > > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? > > > > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > > data retrieval provided by SCTP? Why should I be restricted like this? > > You can only convince my if you can show me that either doing so is > > harmful or it is useless for all applications. > > I'm not sure I follow your scenario... the PU is not "disallowed" from > using SCTP retrieval... it's just not "automatically" done on behalf of > the PU by the rserpool framework / ASAP; the PU is certainly able to > retrieve and re-send "manually" if it wishes upon SF. Then I guess I misunderstood Phill. The words "allow" and "restrict" are strong words in a protocol spec :-) So, it is ok that I can build an SCTP-based app that chooses not to use a ctl-channel, but flag the stack to perform best-effort MF during fault recovery? If so, I am happy and I don't mind what you call this mode. I just don't want to see an impl that forces me to turn on the ctl-channel whenever I try to flag for performing best-effort MF. I'd think the implementation should give the ULP two separate controls (e.g., via ioctl calls) - one for MF and one for ctl-channel. regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Apr 3 15:44:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12862 for ; Thu, 3 Apr 2003 15:44:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Kl2i28084 for rserpool-archive@odin.ietf.org; Thu, 3 Apr 2003 15:47:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KkNK28050; Thu, 3 Apr 2003 15:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KjcK27996 for ; Thu, 3 Apr 2003 15:45:38 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12771 for ; Thu, 3 Apr 2003 15:42:42 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h33KigR7021739 for ; Thu, 3 Apr 2003 13:44:42 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA25676 for ; Thu, 3 Apr 2003 13:42:38 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DAN22F8; Thu, 3 Apr 2003 14:45:09 -0600 Message-ID: <3E8C9CEF.93604617@motorola.com> Date: Thu, 03 Apr 2003 14:43:27 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lei CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Peter, Peter Lei wrote: ... > > As in it is no longer a MUST / SHOULD requirement. TCP mapping layer > MAY implement buffering for retrival. That sounds good. > > If you are talking about TCP mapping in particular, I think we need to > > point out that TCP mapping != control channel, nor it means MF. In the > > TCP draft, if I read it right, PPID and TSN are both optional. This > > means that if I turn off the PPID then there won't be a control channel. > > Moreover, if I turn off the TSN, then there won't be an ACK service that > > can create MF possibility. > > The TCP mapping draft does state that PPID is required for multiplexed > control and data (e.g. control = ASAP PPID); as of San Fran, only this > multiplexed control and data would be used now anyways, right? I had > intended on making this change (non-optional PPID) in the next pass. > > Also in San Fran, I indicated that we would note in the draft that there > is no requirement for implementing a buffer for message retrieval, but > MAY be desirable; certainly without buffering, MF cannot be performed > (and as you point out, TSN is also needed then). I'd agree with the above. > > While the fields are optional, they are meant to be implemented... they > provide the necessary hooks in order to provide for SF and w/buffering, > MF. Recall that the motivation for the TCP mapping draft, in particular, > was to allow non-SCTP transport; there are additional features like > heartbeating that help SF as compared to plain TCP. I understand they are mandatory to impl but optional to use. This is why I used terms like "turn on/off" in my email. This in fact means that when a PU using TCP mapping start a session with a pool, it has the choice of whether to use a ctl-channel or not. I think this flexibility is good. The point I was trying to make in my earlier email is that using TCP mapping does not automatically mean that the session will always have a ctl-channel or MF. I think we are basically in agreement here :-) .... > > > I'd like to invite the rest of the working group to comment on these two > > > possibilities: should we > > > > > > (1) allow for message failover in basic mode for messages not yet put on > > > the wire (which means, conceivably, any arbitrary transport protocol)? > > > > > > OR > > > > > > (2) restrict message failover to enhanced mode (SCTP and mapped TCP)? > > > > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > > data retrieval provided by SCTP? Why should I be restricted like this? > > You can only convince my if you can show me that either doing so is > > harmful or it is useless for all applications. > > I'm not sure I follow your scenario... the PU is not "disallowed" from > using SCTP retrieval... it's just not "automatically" done on behalf of > the PU by the rserpool framework / ASAP; the PU is certainly able to > retrieve and re-send "manually" if it wishes upon SF. Then I guess I misunderstood Phill. The words "allow" and "restrict" are strong words in a protocol spec :-) So, it is ok that I can build an SCTP-based app that chooses not to use a ctl-channel, but flag the stack to perform best-effort MF during fault recovery? If so, I am happy and I don't mind what you call this mode. I just don't want to see an impl that forces me to turn on the ctl-channel whenever I try to flag for performing best-effort MF. I'd think the implementation should give the ULP two separate controls (e.g., via ioctl calls) - one for MF and one for ctl-channel. regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Thu Apr 3 23:40:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25237 for ; Thu, 3 Apr 2003 23:40:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h344gWK31577; Thu, 3 Apr 2003 23:42:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h344fgK31549 for ; Thu, 3 Apr 2003 23:41:42 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25229 for ; Thu, 3 Apr 2003 23:38:35 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCS003SLYCHX5@mtaout11.icomcast.net> for rserpool@ietf.org; Thu, 03 Apr 2003 23:41:05 -0500 (EST) Date: Thu, 03 Apr 2003 23:41:15 -0500 From: Phillip Conrad Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? In-reply-to: <3E8C9CEF.93604617@motorola.com> X-Sender: phillipconrad@mail.comcast.net To: Rserpool Message-id: <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> Content-Transfer-Encoding: 7BIT Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: >> > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use >> > data retrieval provided by SCTP? Why should I be restricted like this? >> > You can only convince my if you can show me that either doing so is >> > harmful or it is useless for all applications. >> >> I'm not sure I follow your scenario... the PU is not "disallowed" from >> using SCTP retrieval... it's just not "automatically" done on behalf of >> the PU by the rserpool framework / ASAP; the PU is certainly able to >> retrieve and re-send "manually" if it wishes upon SF. > >Then I guess I misunderstood Phill. The words "allow" and "restrict" are >strong words in a protocol spec :-) So, it is ok that I can build an >SCTP-based app that chooses not to use a ctl-channel, but flag the stack >to perform best-effort MF during fault recovery? If so, I am happy and I >don't mind what you call this mode. I just don't want to see an impl >that forces me to turn on the ctl-channel whenever I try to flag for >performing best-effort MF. I'd think the implementation should give the >ULP two separate controls (e.g., via ioctl calls) - one for MF and one >for ctl-channel. I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? (Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). Regards, Phill > >regards, >-Qiaobing >_______________________________________________ >rserpool mailing list >rserpool@ietf.org >https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Thu Apr 3 23:40:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25252 for ; Thu, 3 Apr 2003 23:40:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h344hFB31640 for rserpool-archive@odin.ietf.org; Thu, 3 Apr 2003 23:43:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h344gWK31577; Thu, 3 Apr 2003 23:42:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h344fgK31549 for ; Thu, 3 Apr 2003 23:41:42 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25229 for ; Thu, 3 Apr 2003 23:38:35 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCS003SLYCHX5@mtaout11.icomcast.net> for rserpool@ietf.org; Thu, 03 Apr 2003 23:41:05 -0500 (EST) Date: Thu, 03 Apr 2003 23:41:15 -0500 From: Phillip Conrad Subject: Re: [Rserpool] Another data channel issue: failover of messages in basic mode? In-reply-to: <3E8C9CEF.93604617@motorola.com> X-Sender: phillipconrad@mail.comcast.net To: Rserpool Message-id: <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> Content-Transfer-Encoding: 7BIT Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: >> > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use >> > data retrieval provided by SCTP? Why should I be restricted like this? >> > You can only convince my if you can show me that either doing so is >> > harmful or it is useless for all applications. >> >> I'm not sure I follow your scenario... the PU is not "disallowed" from >> using SCTP retrieval... it's just not "automatically" done on behalf of >> the PU by the rserpool framework / ASAP; the PU is certainly able to >> retrieve and re-send "manually" if it wishes upon SF. > >Then I guess I misunderstood Phill. The words "allow" and "restrict" are >strong words in a protocol spec :-) So, it is ok that I can build an >SCTP-based app that chooses not to use a ctl-channel, but flag the stack >to perform best-effort MF during fault recovery? If so, I am happy and I >don't mind what you call this mode. I just don't want to see an impl >that forces me to turn on the ctl-channel whenever I try to flag for >performing best-effort MF. I'd think the implementation should give the >ULP two separate controls (e.g., via ioctl calls) - one for MF and one >for ctl-channel. I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? (Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). Regards, Phill > >regards, >-Qiaobing >_______________________________________________ >rserpool mailing list >rserpool@ietf.org >https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Apr 4 15:45:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07614 for ; Fri, 4 Apr 2003 15:45:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KmC817691; Fri, 4 Apr 2003 15:48:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Klx817665 for ; Fri, 4 Apr 2003 15:47:59 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07590 for ; Fri, 4 Apr 2003 15:44:34 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00G7U71W2J@mtaout11.icomcast.net> for rserpool@ietf.org; Fri, 04 Apr 2003 15:46:45 -0500 (EST) Date: Fri, 04 Apr 2003 15:46:48 -0500 From: Phillip Conrad X-Sender: phillipconrad@mail.comcast.net To: Rserpool Cc: Phillip Conrad Message-id: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I have a question about the hearbeat between an ENRP server and a PE. The ASAP draft says: >2.2.7 ENDPOINT_KEEP_ALIVE message ... (diagram omitted) > This message is sent to a PE by the ENRP server has a "health" check. > If the transport level Heart Beat mechanism is insufficient (usually > this means that time outs are set for too long or heartbeats are not > frequent enough), this adds heartbeat messages with the goal of > determining health status in a more timely fashion. So I conclude that the purpose of the ASAP level heartbeat is to be a backup when the transport layer heartbeat can't do the job. But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. So what am I missing here? Thanks, Phill (RFC2960, around p. 92, 93...) >The upper layer can optionally initiate the following functions: > >A) Disable heartbeat on a specific destination transport address of a > given association, > > B) Change the HB.interval, > > C) Re-enable heartbeat on a specific destination transport address of > a given association, and, > > D) Request an on-demand HEARTBEAT on a specific destination transport > address of a given association. Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Fri Apr 4 15:46:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07646 for ; Fri, 4 Apr 2003 15:46:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Kmvs17716 for rserpool-archive@odin.ietf.org; Fri, 4 Apr 2003 15:48:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KmC817691; Fri, 4 Apr 2003 15:48:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Klx817665 for ; Fri, 4 Apr 2003 15:47:59 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07590 for ; Fri, 4 Apr 2003 15:44:34 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00G7U71W2J@mtaout11.icomcast.net> for rserpool@ietf.org; Fri, 04 Apr 2003 15:46:45 -0500 (EST) Date: Fri, 04 Apr 2003 15:46:48 -0500 From: Phillip Conrad X-Sender: phillipconrad@mail.comcast.net To: Rserpool Cc: Phillip Conrad Message-id: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I have a question about the hearbeat between an ENRP server and a PE. The ASAP draft says: >2.2.7 ENDPOINT_KEEP_ALIVE message ... (diagram omitted) > This message is sent to a PE by the ENRP server has a "health" check. > If the transport level Heart Beat mechanism is insufficient (usually > this means that time outs are set for too long or heartbeats are not > frequent enough), this adds heartbeat messages with the goal of > determining health status in a more timely fashion. So I conclude that the purpose of the ASAP level heartbeat is to be a backup when the transport layer heartbeat can't do the job. But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. So what am I missing here? Thanks, Phill (RFC2960, around p. 92, 93...) >The upper layer can optionally initiate the following functions: > >A) Disable heartbeat on a specific destination transport address of a > given association, > > B) Change the HB.interval, > > C) Re-enable heartbeat on a specific destination transport address of > a given association, and, > > D) Request an on-demand HEARTBEAT on a specific destination transport > address of a given association. Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Apr 4 16:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09353 for ; Fri, 4 Apr 2003 16:48:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LpA822283; Fri, 4 Apr 2003 16:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LoZ822246 for ; Fri, 4 Apr 2003 16:50:35 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09299 for ; Fri, 4 Apr 2003 16:47:08 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h34Lnbaj001333; Fri, 4 Apr 2003 14:49:37 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA07929; Fri, 4 Apr 2003 14:49:01 -0700 (MST)] Received: from labs.mot.com (kilgore.nsr.labs.mot.com [173.23.93.76]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h34LkOm04867; Fri, 4 Apr 2003 15:46:26 -0600 Message-ID: <3E8DFD25.5060600@labs.mot.com> Date: Fri, 04 Apr 2003 15:46:13 -0600 From: "Aron J. Silverton" Reply-To: ajs@labs.mot.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Conrad, Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> In-Reply-To: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phillip Conrad wrote: > I have a question about the hearbeat between an ENRP server and a PE. > > The ASAP draft says: > > >>2.2.7 ENDPOINT_KEEP_ALIVE message > > ... (diagram omitted) > >> This message is sent to a PE by the ENRP server has a "health" check. >> If the transport level Heart Beat mechanism is insufficient (usually >> this means that time outs are set for too long or heartbeats are not >> frequent enough), this adds heartbeat messages with the goal of >> determining health status in a more timely fashion. > > > So I conclude that the purpose of the ASAP level heartbeat is to be a backup > when the transport layer heartbeat can't do the job. > > But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. > > > So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? > > We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. > > So what am I missing here? > I had assumed that this was an artifact left behind by once supporting other transport protocols between PEs and ENRP servers. I can't think of any reason why one would disable SCTP HB and choose to use ASAP HB in its place. I'm with you. Aron > Thanks, > Phill > > (RFC2960, around p. 92, 93...) > > >>The upper layer can optionally initiate the following functions: >> >>A) Disable heartbeat on a specific destination transport address of a >> given association, >> >> B) Change the HB.interval, >> >> C) Re-enable heartbeat on a specific destination transport address of >> a given association, and, >> >> D) Request an on-demand HEARTBEAT on a specific destination transport >> address of a given association. > > > Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > -- Aron J. Silverton Senior Staff Research Engineer Motorola Laboratories, Networks and Infrastructure Research Motorola, Inc. Telephone: 847-576-8747 Fax: 847-576-3240 mailto: ajs@labs.mot.com _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Fri Apr 4 16:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09368 for ; Fri, 4 Apr 2003 16:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34LpxS22321 for rserpool-archive@odin.ietf.org; Fri, 4 Apr 2003 16:51:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LpA822283; Fri, 4 Apr 2003 16:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34LoZ822246 for ; Fri, 4 Apr 2003 16:50:35 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09299 for ; Fri, 4 Apr 2003 16:47:08 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h34Lnbaj001333; Fri, 4 Apr 2003 14:49:37 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA07929; Fri, 4 Apr 2003 14:49:01 -0700 (MST)] Received: from labs.mot.com (kilgore.nsr.labs.mot.com [173.23.93.76]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h34LkOm04867; Fri, 4 Apr 2003 15:46:26 -0600 Message-ID: <3E8DFD25.5060600@labs.mot.com> Date: Fri, 04 Apr 2003 15:46:13 -0600 From: "Aron J. Silverton" Reply-To: ajs@labs.mot.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Conrad, Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> In-Reply-To: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phillip Conrad wrote: > I have a question about the hearbeat between an ENRP server and a PE. > > The ASAP draft says: > > >>2.2.7 ENDPOINT_KEEP_ALIVE message > > ... (diagram omitted) > >> This message is sent to a PE by the ENRP server has a "health" check. >> If the transport level Heart Beat mechanism is insufficient (usually >> this means that time outs are set for too long or heartbeats are not >> frequent enough), this adds heartbeat messages with the goal of >> determining health status in a more timely fashion. > > > So I conclude that the purpose of the ASAP level heartbeat is to be a backup > when the transport layer heartbeat can't do the job. > > But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. > > > So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? > > We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. > > So what am I missing here? > I had assumed that this was an artifact left behind by once supporting other transport protocols between PEs and ENRP servers. I can't think of any reason why one would disable SCTP HB and choose to use ASAP HB in its place. I'm with you. Aron > Thanks, > Phill > > (RFC2960, around p. 92, 93...) > > >>The upper layer can optionally initiate the following functions: >> >>A) Disable heartbeat on a specific destination transport address of a >> given association, >> >> B) Change the HB.interval, >> >> C) Re-enable heartbeat on a specific destination transport address of >> a given association, and, >> >> D) Request an on-demand HEARTBEAT on a specific destination transport >> address of a given association. > > > Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > -- Aron J. Silverton Senior Staff Research Engineer Motorola Laboratories, Networks and Infrastructure Research Motorola, Inc. Telephone: 847-576-8747 Fax: 847-576-3240 mailto: ajs@labs.mot.com _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Apr 4 18:28:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13900 for ; Fri, 4 Apr 2003 18:28:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NV5831430; Fri, 4 Apr 2003 18:31:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NUR831340 for ; Fri, 4 Apr 2003 18:30:27 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13870 for ; Fri, 4 Apr 2003 18:26:57 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h34NTS4T005423 for ; Fri, 4 Apr 2003 16:29:28 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA07971 for ; Fri, 4 Apr 2003 16:26:53 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANJP7K; Fri, 4 Apr 2003 17:29:27 -0600 Message-ID: <3E8E1553.37B8F67@motorola.com> Date: Fri, 04 Apr 2003 17:29:23 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Conrad CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages inbasic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phill, Phillip Conrad wrote: > > At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: > >> > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > >> > data retrieval provided by SCTP? Why should I be restricted like this? > >> > You can only convince my if you can show me that either doing so is > >> > harmful or it is useless for all applications. > >> > >> I'm not sure I follow your scenario... the PU is not "disallowed" from > >> using SCTP retrieval... it's just not "automatically" done on behalf of > >> the PU by the rserpool framework / ASAP; the PU is certainly able to > >> retrieve and re-send "manually" if it wishes upon SF. > > > >Then I guess I misunderstood Phill. The words "allow" and "restrict" are > >strong words in a protocol spec :-) So, it is ok that I can build an > >SCTP-based app that chooses not to use a ctl-channel, but flag the stack > >to perform best-effort MF during fault recovery? If so, I am happy and I > >don't mind what you call this mode. I just don't want to see an impl > >that forces me to turn on the ctl-channel whenever I try to flag for > >performing best-effort MF. I'd think the implementation should give the > >ULP two separate controls (e.g., via ioctl calls) - one for MF and one > >for ctl-channel. > > I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? This would work for me. Strictly speaking, this has more to do with the implementation strategy. I am fine with this, as long as we don't let people have the wrong impression that "to do MF one must have a ctl-channel." > > (Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). This is a little bit unclear. For example, when a PE decides to send a B-card with a wish list, where should the PE get that list? I guess it has to be passed down by the app, right? Another example, when a PE wants to send a Cookie, it can only do so under the instruction of the ULP and must get the app state info from the ULP. So I think the app must know the existence of the ctl-channel and the app must determine whether to use a ctl-channel at the initiation of the session. > > Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? Again, I am ok with this. I consider this a reasonable impl strategy. > > So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". Ok. I think this is just about terminology. In my example, I would then: 1) be using a rserpool impl that supports ctl-channel, 2) have turned on MF and therefore in the enhanced mode, and 3) not be using the ctl-channel. > > To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). Yeah, it's quite confusing now. Let me try this: basic mode - defined as a PU <-> pool session with no control channel; enhanced mode - defined as a PU <-> pool session with a control channel; Note, I don't say PE here because of potential SF. Let's see if we can agree on this first :-) regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Fri Apr 4 18:28:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13917 for ; Fri, 4 Apr 2003 18:28:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34NVk331450 for rserpool-archive@odin.ietf.org; Fri, 4 Apr 2003 18:31:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NV5831430; Fri, 4 Apr 2003 18:31:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NUR831340 for ; Fri, 4 Apr 2003 18:30:27 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13870 for ; Fri, 4 Apr 2003 18:26:57 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h34NTS4T005423 for ; Fri, 4 Apr 2003 16:29:28 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA07971 for ; Fri, 4 Apr 2003 16:26:53 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANJP7K; Fri, 4 Apr 2003 17:29:27 -0600 Message-ID: <3E8E1553.37B8F67@motorola.com> Date: Fri, 04 Apr 2003 17:29:23 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Conrad CC: Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages inbasic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Phill, Phillip Conrad wrote: > > At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: > >> > This means, if my PU uses SCTP in basic mode, my PU is disallowed to use > >> > data retrieval provided by SCTP? Why should I be restricted like this? > >> > You can only convince my if you can show me that either doing so is > >> > harmful or it is useless for all applications. > >> > >> I'm not sure I follow your scenario... the PU is not "disallowed" from > >> using SCTP retrieval... it's just not "automatically" done on behalf of > >> the PU by the rserpool framework / ASAP; the PU is certainly able to > >> retrieve and re-send "manually" if it wishes upon SF. > > > >Then I guess I misunderstood Phill. The words "allow" and "restrict" are > >strong words in a protocol spec :-) So, it is ok that I can build an > >SCTP-based app that chooses not to use a ctl-channel, but flag the stack > >to perform best-effort MF during fault recovery? If so, I am happy and I > >don't mind what you call this mode. I just don't want to see an impl > >that forces me to turn on the ctl-channel whenever I try to flag for > >performing best-effort MF. I'd think the implementation should give the > >ULP two separate controls (e.g., via ioctl calls) - one for MF and one > >for ctl-channel. > > I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? This would work for me. Strictly speaking, this has more to do with the implementation strategy. I am fine with this, as long as we don't let people have the wrong impression that "to do MF one must have a ctl-channel." > > (Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). This is a little bit unclear. For example, when a PE decides to send a B-card with a wish list, where should the PE get that list? I guess it has to be passed down by the app, right? Another example, when a PE wants to send a Cookie, it can only do so under the instruction of the ULP and must get the app state info from the ULP. So I think the app must know the existence of the ctl-channel and the app must determine whether to use a ctl-channel at the initiation of the session. > > Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? Again, I am ok with this. I consider this a reasonable impl strategy. > > So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". Ok. I think this is just about terminology. In my example, I would then: 1) be using a rserpool impl that supports ctl-channel, 2) have turned on MF and therefore in the enhanced mode, and 3) not be using the ctl-channel. > > To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). Yeah, it's quite confusing now. Let me try this: basic mode - defined as a PU <-> pool session with no control channel; enhanced mode - defined as a PU <-> pool session with a control channel; Note, I don't say PE here because of potential SF. Let's see if we can agree on this first :-) regards, -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Apr 4 18:45:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14235 for ; Fri, 4 Apr 2003 18:45:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Nm2800660; Fri, 4 Apr 2003 18:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NlX800631 for ; Fri, 4 Apr 2003 18:47:33 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14208 for ; Fri, 4 Apr 2003 18:44:03 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h34NjcRn004301 for ; Fri, 4 Apr 2003 16:45:38 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA14637 for ; Fri, 4 Apr 2003 16:43:59 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANJQH3; Fri, 4 Apr 2003 17:46:32 -0600 Message-ID: <3E8E195F.8A6FEBC4@motorola.com> Date: Fri, 04 Apr 2003 17:46:39 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ajs@labs.mot.com CC: Phillip Conrad , rserpool@ietf.org Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we only had one unified heartbeat. I think we have a consensus (at least my understanding) to keep RSERPOOL level heartbeat because SCTP is now most likely residing in the kernel. The reasoning is that, while SCTP level heartbeat monitors the end-to-end connectivity between the two SCTP stacks, it does not necessarily ensure the e2e liveliness of its ULP. We are consistent in giving this advice to other ULP developers who are really serious about reliability (such as sigtran UAs, I think they all have their own connectivity/liveliness checking on top of SCTP heartbeat). regards, -Qiaobing "Aron J. Silverton" wrote: > > Phillip Conrad wrote: > > I have a question about the hearbeat between an ENRP server and a PE. > > > > The ASAP draft says: > > > > > >>2.2.7 ENDPOINT_KEEP_ALIVE message > > > > ... (diagram omitted) > > > >> This message is sent to a PE by the ENRP server has a "health" check. > >> If the transport level Heart Beat mechanism is insufficient (usually > >> this means that time outs are set for too long or heartbeats are not > >> frequent enough), this adds heartbeat messages with the goal of > >> determining health status in a more timely fashion. > > > > > > So I conclude that the purpose of the ASAP level heartbeat is to be a backup > > when the transport layer heartbeat can't do the job. > > > > But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. > > > > > > So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? > > > > We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. > > > > So what am I missing here? > > > > I had assumed that this was an artifact left behind by once supporting > other transport protocols between PEs and ENRP servers. I can't think > of any reason why one would disable SCTP HB and choose to use ASAP HB in > its place. > > I'm with you. > > Aron > > > Thanks, > > Phill > > > > (RFC2960, around p. 92, 93...) > > > > > >>The upper layer can optionally initiate the following functions: > >> > >>A) Disable heartbeat on a specific destination transport address of a > >> given association, > >> > >> B) Change the HB.interval, > >> > >> C) Re-enable heartbeat on a specific destination transport address of > >> a given association, and, > >> > >> D) Request an on-demand HEARTBEAT on a specific destination transport > >> address of a given association. > > > > > > Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. > > > > _______________________________________________ > > rserpool mailing list > > rserpool@ietf.org > > https://www1.ietf.org/mailman/listinfo/rserpool > > > > -- > Aron J. Silverton > Senior Staff Research Engineer > Motorola Laboratories, Networks and Infrastructure Research > Motorola, Inc. > > Telephone: 847-576-8747 > Fax: 847-576-3240 > mailto: ajs@labs.mot.com > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Fri Apr 4 18:45:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14282 for ; Fri, 4 Apr 2003 18:45:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Nmet00681 for rserpool-archive@odin.ietf.org; Fri, 4 Apr 2003 18:48:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Nm2800660; Fri, 4 Apr 2003 18:48:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34NlX800631 for ; Fri, 4 Apr 2003 18:47:33 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14208 for ; Fri, 4 Apr 2003 18:44:03 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h34NjcRn004301 for ; Fri, 4 Apr 2003 16:45:38 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA14637 for ; Fri, 4 Apr 2003 16:43:59 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANJQH3; Fri, 4 Apr 2003 17:46:32 -0600 Message-ID: <3E8E195F.8A6FEBC4@motorola.com> Date: Fri, 04 Apr 2003 17:46:39 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ajs@labs.mot.com CC: Phillip Conrad , rserpool@ietf.org Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we only had one unified heartbeat. I think we have a consensus (at least my understanding) to keep RSERPOOL level heartbeat because SCTP is now most likely residing in the kernel. The reasoning is that, while SCTP level heartbeat monitors the end-to-end connectivity between the two SCTP stacks, it does not necessarily ensure the e2e liveliness of its ULP. We are consistent in giving this advice to other ULP developers who are really serious about reliability (such as sigtran UAs, I think they all have their own connectivity/liveliness checking on top of SCTP heartbeat). regards, -Qiaobing "Aron J. Silverton" wrote: > > Phillip Conrad wrote: > > I have a question about the hearbeat between an ENRP server and a PE. > > > > The ASAP draft says: > > > > > >>2.2.7 ENDPOINT_KEEP_ALIVE message > > > > ... (diagram omitted) > > > >> This message is sent to a PE by the ENRP server has a "health" check. > >> If the transport level Heart Beat mechanism is insufficient (usually > >> this means that time outs are set for too long or heartbeats are not > >> frequent enough), this adds heartbeat messages with the goal of > >> determining health status in a more timely fashion. > > > > > > So I conclude that the purpose of the ASAP level heartbeat is to be a backup > > when the transport layer heartbeat can't do the job. > > > > But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat. > > > > > > So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done? > > > > We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here. The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough". But neither of those makes sense to me. If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout. And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs. > > > > So what am I missing here? > > > > I had assumed that this was an artifact left behind by once supporting > other transport protocols between PEs and ENRP servers. I can't think > of any reason why one would disable SCTP HB and choose to use ASAP HB in > its place. > > I'm with you. > > Aron > > > Thanks, > > Phill > > > > (RFC2960, around p. 92, 93...) > > > > > >>The upper layer can optionally initiate the following functions: > >> > >>A) Disable heartbeat on a specific destination transport address of a > >> given association, > >> > >> B) Change the HB.interval, > >> > >> C) Re-enable heartbeat on a specific destination transport address of > >> a given association, and, > >> > >> D) Request an on-demand HEARTBEAT on a specific destination transport > >> address of a given association. > > > > > > Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above. > > > > _______________________________________________ > > rserpool mailing list > > rserpool@ietf.org > > https://www1.ietf.org/mailman/listinfo/rserpool > > > > -- > Aron J. Silverton > Senior Staff Research Engineer > Motorola Laboratories, Networks and Infrastructure Research > Motorola, Inc. > > Telephone: 847-576-8747 > Fax: 847-576-3240 > mailto: ajs@labs.mot.com > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Sat Apr 5 00:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18687 for ; Sat, 5 Apr 2003 00:23:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355QH821935; Sat, 5 Apr 2003 00:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355Pe821897 for ; Sat, 5 Apr 2003 00:25:40 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18676 for ; Sat, 5 Apr 2003 00:22:03 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00ESYV0XVR@mtaout11.icomcast.net> for rserpool@ietf.org; Sat, 05 Apr 2003 00:24:34 -0500 (EST) Date: Sat, 05 Apr 2003 00:24:37 -0500 From: Phillip Conrad Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) In-reply-to: <3E8E195F.8A6FEBC4@motorola.com> X-Sender: phillipconrad@mail.comcast.net To: rserpool@ietf.org Message-id: <5.1.0.14.2.20030405002051.02d67e88@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> Content-Transfer-Encoding: 7BIT Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Qiaobing: OK, your explanation below makes sense... but perhaps the text in the ASAP draft section 2.2.7 should be updated to reflect this reasoning, since at least one other person (Aron) reached the same conclusion as me based on the existing text. Regards, Phill At 05:46 PM 4/4/2003 -0600, Qiaobing Xie wrote: >Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we >only had one unified heartbeat. I think we have a consensus (at least my >understanding) to keep RSERPOOL level heartbeat because SCTP is now most >likely residing in the kernel. The reasoning is that, while SCTP level >heartbeat monitors the end-to-end connectivity between the two SCTP >stacks, it does not necessarily ensure the e2e liveliness of its ULP. We >are consistent in giving this advice to other ULP developers who are >really serious about reliability (such as sigtran UAs, I think they all >have their own connectivity/liveliness checking on top of SCTP >heartbeat). > >regards, >-Qiaobing > >"Aron J. Silverton" wrote: >> >> Phillip Conrad wrote: >> > I have a question about the hearbeat between an ENRP server and a PE. >> > >> > The ASAP draft says: >> > >> > >> >>2.2.7 ENDPOINT_KEEP_ALIVE message >> > >> > ... (diagram omitted) >> > >> >> This message is sent to a PE by the ENRP server has a "health" check. >> >> If the transport level Heart Beat mechanism is insufficient (usually >> >> this means that time outs are set for too long or heartbeats are not >> >> frequent enough), this adds heartbeat messages with the goal of >> >> determining health status in a more timely fashion. >> > >> > >> > So I conclude that the purpose of the ASAP level heartbeat is to be a >backup >> > when the transport layer heartbeat can't do the job. >> > >> > But from what I read in RFC2960 (see excerpts below) it seems as if the >upper layer (in this case, ASAP) has a lot of control over the heartbeat. >> > >> > >> > So, my question is this: what is the circumstance in which the >mechanisms already in RFC2960 aren't sufficient to get the job done? >> > >> > We have restricted PE<->NS communication to SCTP, so the answer "what if >the transport isn't SCTP" doesn't apply here. The ASAP draft says that >"time outs are too long, or the heartbeat interval isn't short enough". But >neither of those makes sense to me. If the if timeouts are too long, then >sending a data message over the transport connection isn't going to help.. >it will experience the same timeout. And if the heartbeat interval is too >short, the capabilities specified in RFC2960 should allow the ASAP entity to >change it to the interval that it needs. >> > >> > So what am I missing here? >> > >> >> I had assumed that this was an artifact left behind by once supporting >> other transport protocols between PEs and ENRP servers. I can't think >> of any reason why one would disable SCTP HB and choose to use ASAP HB in >> its place. >> >> I'm with you. >> >> Aron >> >> > Thanks, >> > Phill >> > >> > (RFC2960, around p. 92, 93...) >> > >> > >> >>The upper layer can optionally initiate the following functions: >> >> >> >>A) Disable heartbeat on a specific destination transport address of a >> >> given association, >> >> >> >> B) Change the HB.interval, >> >> >> >> C) Re-enable heartbeat on a specific destination transport address of >> >> a given association, and, >> >> >> >> D) Request an on-demand HEARTBEAT on a specific destination transport >> >> address of a given association. >> > >> > >> > Note: There are some mentions of heartbeat in the implementors guide, >but I didn't see how any of them would change the capabilities in the list >above. >> > >> > _______________________________________________ >> > rserpool mailing list >> > rserpool@ietf.org >> > https://www1.ietf.org/mailman/listinfo/rserpool >> > >> >> -- >> Aron J. Silverton >> Senior Staff Research Engineer >> Motorola Laboratories, Networks and Infrastructure Research >> Motorola, Inc. >> >> Telephone: 847-576-8747 >> Fax: 847-576-3240 >> mailto: ajs@labs.mot.com >> >> _______________________________________________ >> rserpool mailing list >> rserpool@ietf.org >> https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Sat Apr 5 00:23:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18702 for ; Sat, 5 Apr 2003 00:23:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h355QwB21969 for rserpool-archive@odin.ietf.org; Sat, 5 Apr 2003 00:26:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355QH821935; Sat, 5 Apr 2003 00:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355Pe821897 for ; Sat, 5 Apr 2003 00:25:40 -0500 Received: from smtp-out.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18676 for ; Sat, 5 Apr 2003 00:22:03 -0500 (EST) Received: from livingroom.acm.org (pcp01480554pcs.ncstl01.de.comcast.net [68.82.68.240]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HCU00ESYV0XVR@mtaout11.icomcast.net> for rserpool@ietf.org; Sat, 05 Apr 2003 00:24:34 -0500 (EST) Date: Sat, 05 Apr 2003 00:24:37 -0500 From: Phillip Conrad Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) In-reply-to: <3E8E195F.8A6FEBC4@motorola.com> X-Sender: phillipconrad@mail.comcast.net To: rserpool@ietf.org Message-id: <5.1.0.14.2.20030405002051.02d67e88@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> Content-Transfer-Encoding: 7BIT Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Qiaobing: OK, your explanation below makes sense... but perhaps the text in the ASAP draft section 2.2.7 should be updated to reflect this reasoning, since at least one other person (Aron) reached the same conclusion as me based on the existing text. Regards, Phill At 05:46 PM 4/4/2003 -0600, Qiaobing Xie wrote: >Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we >only had one unified heartbeat. I think we have a consensus (at least my >understanding) to keep RSERPOOL level heartbeat because SCTP is now most >likely residing in the kernel. The reasoning is that, while SCTP level >heartbeat monitors the end-to-end connectivity between the two SCTP >stacks, it does not necessarily ensure the e2e liveliness of its ULP. We >are consistent in giving this advice to other ULP developers who are >really serious about reliability (such as sigtran UAs, I think they all >have their own connectivity/liveliness checking on top of SCTP >heartbeat). > >regards, >-Qiaobing > >"Aron J. Silverton" wrote: >> >> Phillip Conrad wrote: >> > I have a question about the hearbeat between an ENRP server and a PE. >> > >> > The ASAP draft says: >> > >> > >> >>2.2.7 ENDPOINT_KEEP_ALIVE message >> > >> > ... (diagram omitted) >> > >> >> This message is sent to a PE by the ENRP server has a "health" check. >> >> If the transport level Heart Beat mechanism is insufficient (usually >> >> this means that time outs are set for too long or heartbeats are not >> >> frequent enough), this adds heartbeat messages with the goal of >> >> determining health status in a more timely fashion. >> > >> > >> > So I conclude that the purpose of the ASAP level heartbeat is to be a >backup >> > when the transport layer heartbeat can't do the job. >> > >> > But from what I read in RFC2960 (see excerpts below) it seems as if the >upper layer (in this case, ASAP) has a lot of control over the heartbeat. >> > >> > >> > So, my question is this: what is the circumstance in which the >mechanisms already in RFC2960 aren't sufficient to get the job done? >> > >> > We have restricted PE<->NS communication to SCTP, so the answer "what if >the transport isn't SCTP" doesn't apply here. The ASAP draft says that >"time outs are too long, or the heartbeat interval isn't short enough". But >neither of those makes sense to me. If the if timeouts are too long, then >sending a data message over the transport connection isn't going to help.. >it will experience the same timeout. And if the heartbeat interval is too >short, the capabilities specified in RFC2960 should allow the ASAP entity to >change it to the interval that it needs. >> > >> > So what am I missing here? >> > >> >> I had assumed that this was an artifact left behind by once supporting >> other transport protocols between PEs and ENRP servers. I can't think >> of any reason why one would disable SCTP HB and choose to use ASAP HB in >> its place. >> >> I'm with you. >> >> Aron >> >> > Thanks, >> > Phill >> > >> > (RFC2960, around p. 92, 93...) >> > >> > >> >>The upper layer can optionally initiate the following functions: >> >> >> >>A) Disable heartbeat on a specific destination transport address of a >> >> given association, >> >> >> >> B) Change the HB.interval, >> >> >> >> C) Re-enable heartbeat on a specific destination transport address of >> >> a given association, and, >> >> >> >> D) Request an on-demand HEARTBEAT on a specific destination transport >> >> address of a given association. >> > >> > >> > Note: There are some mentions of heartbeat in the implementors guide, >but I didn't see how any of them would change the capabilities in the list >above. >> > >> > _______________________________________________ >> > rserpool mailing list >> > rserpool@ietf.org >> > https://www1.ietf.org/mailman/listinfo/rserpool >> > >> >> -- >> Aron J. Silverton >> Senior Staff Research Engineer >> Motorola Laboratories, Networks and Infrastructure Research >> Motorola, Inc. >> >> Telephone: 847-576-8747 >> Fax: 847-576-3240 >> mailto: ajs@labs.mot.com >> >> _______________________________________________ >> rserpool mailing list >> rserpool@ietf.org >> https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Mon Apr 7 12:43:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26958 for ; Mon, 7 Apr 2003 12:43:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GlA826564; Mon, 7 Apr 2003 12:47:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Gk6826505 for ; Mon, 7 Apr 2003 12:46:06 -0400 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26729 for ; Mon, 7 Apr 2003 12:41:18 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h37GhxmV029290 for ; Mon, 7 Apr 2003 09:43:59 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA25390 for ; Mon, 7 Apr 2003 09:43:49 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANKYS7; Mon, 7 Apr 2003 11:42:59 -0500 Message-ID: <3E91AAB3.2B14215B@motorola.com> Date: Mon, 07 Apr 2003 11:43:31 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Conrad CC: rserpool@ietf.org Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> <5.1.0.14.2.20030405002051.02d67e88@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, I've noted this in my to-do list. -Q Phillip Conrad wrote: > > Qiaobing: > OK, your explanation below makes sense... but perhaps the text in the ASAP draft section 2.2.7 should be updated to reflect this reasoning, since at least one other person (Aron) reached the same conclusion as me based on the existing text. > > Regards, > Phill > > At 05:46 PM 4/4/2003 -0600, Qiaobing Xie wrote: > >Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we > >only had one unified heartbeat. I think we have a consensus (at least my > >understanding) to keep RSERPOOL level heartbeat because SCTP is now most > >likely residing in the kernel. The reasoning is that, while SCTP level > >heartbeat monitors the end-to-end connectivity between the two SCTP > >stacks, it does not necessarily ensure the e2e liveliness of its ULP. We > >are consistent in giving this advice to other ULP developers who are > >really serious about reliability (such as sigtran UAs, I think they all > >have their own connectivity/liveliness checking on top of SCTP > >heartbeat). > > > >regards, > >-Qiaobing > > > >"Aron J. Silverton" wrote: > >> > >> Phillip Conrad wrote: > >> > I have a question about the hearbeat between an ENRP server and a PE. > >> > > >> > The ASAP draft says: > >> > > >> > > >> >>2.2.7 ENDPOINT_KEEP_ALIVE message > >> > > >> > ... (diagram omitted) > >> > > >> >> This message is sent to a PE by the ENRP server has a "health" check. > >> >> If the transport level Heart Beat mechanism is insufficient (usually > >> >> this means that time outs are set for too long or heartbeats are not > >> >> frequent enough), this adds heartbeat messages with the goal of > >> >> determining health status in a more timely fashion. > >> > > >> > > >> > So I conclude that the purpose of the ASAP level heartbeat is to be a > >backup > >> > when the transport layer heartbeat can't do the job. > >> > > >> > But from what I read in RFC2960 (see excerpts below) it seems as if the > >upper layer (in this case, ASAP) has a lot of control over the heartbeat. > >> > > >> > > >> > So, my question is this: what is the circumstance in which the > >mechanisms already in RFC2960 aren't sufficient to get the job done? > >> > > >> > We have restricted PE<->NS communication to SCTP, so the answer "what if > >the transport isn't SCTP" doesn't apply here. The ASAP draft says that > >"time outs are too long, or the heartbeat interval isn't short enough". But > >neither of those makes sense to me. If the if timeouts are too long, then > >sending a data message over the transport connection isn't going to help.. > >it will experience the same timeout. And if the heartbeat interval is too > >short, the capabilities specified in RFC2960 should allow the ASAP entity to > >change it to the interval that it needs. > >> > > >> > So what am I missing here? > >> > > >> > >> I had assumed that this was an artifact left behind by once supporting > >> other transport protocols between PEs and ENRP servers. I can't think > >> of any reason why one would disable SCTP HB and choose to use ASAP HB in > >> its place. > >> > >> I'm with you. > >> > >> Aron > >> > >> > Thanks, > >> > Phill > >> > > >> > (RFC2960, around p. 92, 93...) > >> > > >> > > >> >>The upper layer can optionally initiate the following functions: > >> >> > >> >>A) Disable heartbeat on a specific destination transport address of a > >> >> given association, > >> >> > >> >> B) Change the HB.interval, > >> >> > >> >> C) Re-enable heartbeat on a specific destination transport address of > >> >> a given association, and, > >> >> > >> >> D) Request an on-demand HEARTBEAT on a specific destination transport > >> >> address of a given association. > >> > > >> > > >> > Note: There are some mentions of heartbeat in the implementors guide, > >but I didn't see how any of them would change the capabilities in the list > >above. > >> > > >> > _______________________________________________ > >> > rserpool mailing list > >> > rserpool@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/rserpool > >> > > >> > >> -- > >> Aron J. Silverton > >> Senior Staff Research Engineer > >> Motorola Laboratories, Networks and Infrastructure Research > >> Motorola, Inc. > >> > >> Telephone: 847-576-8747 > >> Fax: 847-576-3240 > >> mailto: ajs@labs.mot.com > >> > >> _______________________________________________ > >> rserpool mailing list > >> rserpool@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Mon Apr 7 12:43:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26990 for ; Mon, 7 Apr 2003 12:43:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37Glt726579 for rserpool-archive@odin.ietf.org; Mon, 7 Apr 2003 12:47:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GlA826564; Mon, 7 Apr 2003 12:47:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Gk6826505 for ; Mon, 7 Apr 2003 12:46:06 -0400 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26729 for ; Mon, 7 Apr 2003 12:41:18 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h37GhxmV029290 for ; Mon, 7 Apr 2003 09:43:59 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA25390 for ; Mon, 7 Apr 2003 09:43:49 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANKYS7; Mon, 7 Apr 2003 11:42:59 -0500 Message-ID: <3E91AAB3.2B14215B@motorola.com> Date: Mon, 07 Apr 2003 11:43:31 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Conrad CC: rserpool@ietf.org Subject: Re: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7) References: <5.1.0.14.2.20030404153539.03a0acb0@joda.cis.temple.edu> <3E8DFD25.5060600@labs.mot.com> <5.1.0.14.2.20030405002051.02d67e88@joda.cis.temple.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, I've noted this in my to-do list. -Q Phillip Conrad wrote: > > Qiaobing: > OK, your explanation below makes sense... but perhaps the text in the ASAP draft section 2.2.7 should be updated to reflect this reasoning, since at least one other person (Aron) reached the same conclusion as me based on the existing text. > > Regards, > Phill > > At 05:46 PM 4/4/2003 -0600, Qiaobing Xie wrote: > >Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we > >only had one unified heartbeat. I think we have a consensus (at least my > >understanding) to keep RSERPOOL level heartbeat because SCTP is now most > >likely residing in the kernel. The reasoning is that, while SCTP level > >heartbeat monitors the end-to-end connectivity between the two SCTP > >stacks, it does not necessarily ensure the e2e liveliness of its ULP. We > >are consistent in giving this advice to other ULP developers who are > >really serious about reliability (such as sigtran UAs, I think they all > >have their own connectivity/liveliness checking on top of SCTP > >heartbeat). > > > >regards, > >-Qiaobing > > > >"Aron J. Silverton" wrote: > >> > >> Phillip Conrad wrote: > >> > I have a question about the hearbeat between an ENRP server and a PE. > >> > > >> > The ASAP draft says: > >> > > >> > > >> >>2.2.7 ENDPOINT_KEEP_ALIVE message > >> > > >> > ... (diagram omitted) > >> > > >> >> This message is sent to a PE by the ENRP server has a "health" check. > >> >> If the transport level Heart Beat mechanism is insufficient (usually > >> >> this means that time outs are set for too long or heartbeats are not > >> >> frequent enough), this adds heartbeat messages with the goal of > >> >> determining health status in a more timely fashion. > >> > > >> > > >> > So I conclude that the purpose of the ASAP level heartbeat is to be a > >backup > >> > when the transport layer heartbeat can't do the job. > >> > > >> > But from what I read in RFC2960 (see excerpts below) it seems as if the > >upper layer (in this case, ASAP) has a lot of control over the heartbeat. > >> > > >> > > >> > So, my question is this: what is the circumstance in which the > >mechanisms already in RFC2960 aren't sufficient to get the job done? > >> > > >> > We have restricted PE<->NS communication to SCTP, so the answer "what if > >the transport isn't SCTP" doesn't apply here. The ASAP draft says that > >"time outs are too long, or the heartbeat interval isn't short enough". But > >neither of those makes sense to me. If the if timeouts are too long, then > >sending a data message over the transport connection isn't going to help.. > >it will experience the same timeout. And if the heartbeat interval is too > >short, the capabilities specified in RFC2960 should allow the ASAP entity to > >change it to the interval that it needs. > >> > > >> > So what am I missing here? > >> > > >> > >> I had assumed that this was an artifact left behind by once supporting > >> other transport protocols between PEs and ENRP servers. I can't think > >> of any reason why one would disable SCTP HB and choose to use ASAP HB in > >> its place. > >> > >> I'm with you. > >> > >> Aron > >> > >> > Thanks, > >> > Phill > >> > > >> > (RFC2960, around p. 92, 93...) > >> > > >> > > >> >>The upper layer can optionally initiate the following functions: > >> >> > >> >>A) Disable heartbeat on a specific destination transport address of a > >> >> given association, > >> >> > >> >> B) Change the HB.interval, > >> >> > >> >> C) Re-enable heartbeat on a specific destination transport address of > >> >> a given association, and, > >> >> > >> >> D) Request an on-demand HEARTBEAT on a specific destination transport > >> >> address of a given association. > >> > > >> > > >> > Note: There are some mentions of heartbeat in the implementors guide, > >but I didn't see how any of them would change the capabilities in the list > >above. > >> > > >> > _______________________________________________ > >> > rserpool mailing list > >> > rserpool@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/rserpool > >> > > >> > >> -- > >> Aron J. Silverton > >> Senior Staff Research Engineer > >> Motorola Laboratories, Networks and Infrastructure Research > >> Motorola, Inc. > >> > >> Telephone: 847-576-8747 > >> Fax: 847-576-3240 > >> mailto: ajs@labs.mot.com > >> > >> _______________________________________________ > >> rserpool mailing list > >> rserpool@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rserpool > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 8 12:10:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20505 for ; Tue, 8 Apr 2003 12:10:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF5807292; Tue, 8 Apr 2003 12:15:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GEd807235 for ; Tue, 8 Apr 2003 12:14:39 -0400 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20449 for ; Tue, 8 Apr 2003 12:09:21 -0400 (EDT) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h38GBsHP029290 for ; Tue, 8 Apr 2003 09:11:55 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA19947 for ; Tue, 8 Apr 2003 09:09:14 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANLZ7M; Tue, 8 Apr 2003 11:11:04 -0500 Message-ID: <3E92F4CC.8DA38224@motorola.com> Date: Tue, 08 Apr 2003 11:11:56 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rserpool list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rserpool] Re: I-D ACTION:draft-xie-rserpool-redundancy-model-00.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all, This I-D defines a new selection policy param to support advanced redundancy model. Your review and comments will be greatly appreciated. regards, -Qiaobing Xie > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RSERPOOL Redundancy-model Policy > Author(s) : Q. Xie, L. Yarroll > Filename : draft-xie-rserpool-redundancy-model-00.txt > Pages : 10 > Date : 2003-4-7 > > This document defines RSERPOOL Redundancy-model Member Selection > Policy parameter and the related procedures. This policy is designed > to be flexible and capable of supporting a wide range of advanced > redundancy models found in some high availability systems. The design > uses the extensibility in RSERPOOL pool load sharing policy. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-rserpool-redundancy-model-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-rserpool-redundancy-model-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 8 12:11:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20536 for ; Tue, 8 Apr 2003 12:11:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38GFlA07343 for rserpool-archive@odin.ietf.org; Tue, 8 Apr 2003 12:15:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF5807292; Tue, 8 Apr 2003 12:15:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GEd807235 for ; Tue, 8 Apr 2003 12:14:39 -0400 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20449 for ; Tue, 8 Apr 2003 12:09:21 -0400 (EDT) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h38GBsHP029290 for ; Tue, 8 Apr 2003 09:11:55 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA19947 for ; Tue, 8 Apr 2003 09:09:14 -0700 (MST)] Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANLZ7M; Tue, 8 Apr 2003 11:11:04 -0500 Message-ID: <3E92F4CC.8DA38224@motorola.com> Date: Tue, 08 Apr 2003 11:11:56 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rserpool list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rserpool] Re: I-D ACTION:draft-xie-rserpool-redundancy-model-00.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all, This I-D defines a new selection policy param to support advanced redundancy model. Your review and comments will be greatly appreciated. regards, -Qiaobing Xie > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RSERPOOL Redundancy-model Policy > Author(s) : Q. Xie, L. Yarroll > Filename : draft-xie-rserpool-redundancy-model-00.txt > Pages : 10 > Date : 2003-4-7 > > This document defines RSERPOOL Redundancy-model Member Selection > Policy parameter and the related procedures. This policy is designed > to be flexible and capable of supporting a wide range of advanced > redundancy models found in some high availability systems. The design > uses the extensibility in RSERPOOL pool load sharing policy. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-xie-rserpool-redundancy-model-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-xie-rserpool-redundancy-model-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 9 14:06:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08212 for ; Wed, 9 Apr 2003 14:06:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IBO813738; Wed, 9 Apr 2003 14:11:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IAW811824 for ; Wed, 9 Apr 2003 14:10:32 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08171 for ; Wed, 9 Apr 2003 14:04:42 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39I7MZ23427 for ; Wed, 9 Apr 2003 13:07:22 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:07:15 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:07:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:07:15 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680D6@daebe007.americas.nokia.com> Thread-Topic: Minutes of security design team teleconference - April 4 Thread-Index: AcL+wtmw+5Y1MGB0SbieQ5Ae5UkpYg== To: X-OriginalArrivalTime: 09 Apr 2003 18:07:15.0942 (UTC) FILETIME=[DA4D8860:01C2FEC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IAW811825 Subject: [Rserpool] Minutes of security design team teleconference - April 4 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit For a summary of open security issues please see the talk entitled "Rserpool Security" presented at IETF #56: www.ietf.org/proceedings/03mar/slides/reserpool-3/index.html The next security design team teleconference will be held on Tuesday, April 15 at 10AM EDT USA. Note that the US has gone to daylight savings time. Summary of April 4: This was attended by: Michael Tuexen Aron Silverton Qiaobing Xie Maureen Stillman The security design team reached consensus on using TLS from the PE to the ENRP server and between ENRP servers to guarantee the following properties: 1) the integrity of the nameserver information sent from the ENRP server to the client 2) the integrity of the registration information sent from the PE to the ENRP server 3) ensuring that a PE registers with a legitimate (non-rogue) ENRP server The open issue that this raised is: What about ENRP servers that have both: PE registrations using TLS and PE registrations not using TLS? There were two options discussed: 1) PE registration entries that had used TLS would be flagged as such. The ENRP server would pass along a list to the PU with some entries marked as "secure" and others marked as not. 2) An ENRP server that supports security would only accept PE input that used TLS. All other registrations would be rejected. Then, when the PU requests a list, it would have only secure entries. The reason to support #1 is that it lets the PU decide what entries to trust. The reason to support #2 is simplicity and support for a consistent security policy. Don't want to fragment the namespace. There was more support for #2 than for #1 and we agreed to ask the mailing list for an opinion. Comments on this? There was a question about having two separate ports for the ENRP server PE registration, one for TLS security, and the other for no security. Someone raised the issue that using two separate ports is deprecated. Using two different ports would be simpler from an implementation point of view. However, using one port has security issues and is more complex to implement and get it right. Maureen Stillman agreed to contact Eric Rescorla to find out the current IESG/IAB thinking on this issue. His response will be posted to the mailing list. Any corrections/additions to the minutes? -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 9 14:06:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08228 for ; Wed, 9 Apr 2003 14:06:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39IC7C13984 for rserpool-archive@odin.ietf.org; Wed, 9 Apr 2003 14:12:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IBO813738; Wed, 9 Apr 2003 14:11:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IAW811824 for ; Wed, 9 Apr 2003 14:10:32 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08171 for ; Wed, 9 Apr 2003 14:04:42 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39I7MZ23427 for ; Wed, 9 Apr 2003 13:07:22 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:07:15 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:07:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:07:15 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680D6@daebe007.americas.nokia.com> Thread-Topic: Minutes of security design team teleconference - April 4 Thread-Index: AcL+wtmw+5Y1MGB0SbieQ5Ae5UkpYg== To: X-OriginalArrivalTime: 09 Apr 2003 18:07:15.0942 (UTC) FILETIME=[DA4D8860:01C2FEC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IAW811825 Subject: [Rserpool] Minutes of security design team teleconference - April 4 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit For a summary of open security issues please see the talk entitled "Rserpool Security" presented at IETF #56: www.ietf.org/proceedings/03mar/slides/reserpool-3/index.html The next security design team teleconference will be held on Tuesday, April 15 at 10AM EDT USA. Note that the US has gone to daylight savings time. Summary of April 4: This was attended by: Michael Tuexen Aron Silverton Qiaobing Xie Maureen Stillman The security design team reached consensus on using TLS from the PE to the ENRP server and between ENRP servers to guarantee the following properties: 1) the integrity of the nameserver information sent from the ENRP server to the client 2) the integrity of the registration information sent from the PE to the ENRP server 3) ensuring that a PE registers with a legitimate (non-rogue) ENRP server The open issue that this raised is: What about ENRP servers that have both: PE registrations using TLS and PE registrations not using TLS? There were two options discussed: 1) PE registration entries that had used TLS would be flagged as such. The ENRP server would pass along a list to the PU with some entries marked as "secure" and others marked as not. 2) An ENRP server that supports security would only accept PE input that used TLS. All other registrations would be rejected. Then, when the PU requests a list, it would have only secure entries. The reason to support #1 is that it lets the PU decide what entries to trust. The reason to support #2 is simplicity and support for a consistent security policy. Don't want to fragment the namespace. There was more support for #2 than for #1 and we agreed to ask the mailing list for an opinion. Comments on this? There was a question about having two separate ports for the ENRP server PE registration, one for TLS security, and the other for no security. Someone raised the issue that using two separate ports is deprecated. Using two different ports would be simpler from an implementation point of view. However, using one port has security issues and is more complex to implement and get it right. Maureen Stillman agreed to contact Eric Rescorla to find out the current IESG/IAB thinking on this issue. His response will be posted to the mailing list. Any corrections/additions to the minutes? -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 9 14:10:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08305 for ; Wed, 9 Apr 2003 14:10:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IG1815106; Wed, 9 Apr 2003 14:16:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IF1815077 for ; Wed, 9 Apr 2003 14:15:01 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08288 for ; Wed, 9 Apr 2003 14:09:11 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39IBqZ23769 for ; Wed, 9 Apr 2003 13:11:52 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:11:45 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:10:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:10:55 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222C8E@daebe007.americas.nokia.com> Thread-Topic: Ports for Rserpool nameserver Thread-Index: AcL+Rjm8yH6LhpTqRgmYyPXxOIIuOAAfOm2A To: X-OriginalArrivalTime: 09 Apr 2003 18:10:56.0351 (UTC) FILETIME=[5DAD46F0:01C2FEC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IF2815080 Subject: [Rserpool] FW: Ports for Rserpool nameserver Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here is the response from Eric Rescorla on our security question. -- maureen -----Original Message----- From: ext Eric Rescorla [mailto:ekr@rtfm.com] Sent: Tuesday, April 08, 2003 11:21 PM To: Stillman Maureen (NVO-NIC/Ithaca) Cc: lyong@ciena.com Subject: Re: Ports for Rserpool nameserver Maureen, I don't know what the IESG's policy about separate ports versus application-layer signalling is these days. Keith Moore was the major player there and of course he's no longer AD. There are two ways to do an upward negotiation solution. One is unilateral. I.e. the client sends "STARTLS" first thing and then just starts negotiating TLS. This is obviously as secure as separate ports, since the client isn't switch-hitting. The other is real negotiation, in which the client requests TLS but is willing to switch-hit to normal application-layer traffic. In this case there's a downgrade attack. -Ekr > We are strongly in favor of using TLS for security in Reserpool to > protect the integrity of the namespace. TLS would be mandatory to > implement but optional to use. Given this, the ENRP name server would > listen on 2 ports for registration. One port for insecure > registrations from pool elements offering a services and the second > port for secure registrations using TLS. > > However, I had heard that the use of two different ports for a > service, one for security and one not is deprecated. Is this correct? > If so, is there a secure way to upgrade a connection that is not > secure to TLS? Isn't this tricky to implement correctly with > STARTTLS? We will be using both SCTP and TCP for this as transport. > We prefer the 2 port solution if the IESG would pass it. If they > won't then we need to find some good alternative. > > Thanks for any clarification you can give us. > > -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 9 14:11:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08325 for ; Wed, 9 Apr 2003 14:11:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39IGec15124 for rserpool-archive@odin.ietf.org; Wed, 9 Apr 2003 14:16:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IG1815106; Wed, 9 Apr 2003 14:16:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IF1815077 for ; Wed, 9 Apr 2003 14:15:01 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08288 for ; Wed, 9 Apr 2003 14:09:11 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39IBqZ23769 for ; Wed, 9 Apr 2003 13:11:52 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:11:45 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:10:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:10:55 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81101222C8E@daebe007.americas.nokia.com> Thread-Topic: Ports for Rserpool nameserver Thread-Index: AcL+Rjm8yH6LhpTqRgmYyPXxOIIuOAAfOm2A To: X-OriginalArrivalTime: 09 Apr 2003 18:10:56.0351 (UTC) FILETIME=[5DAD46F0:01C2FEC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IF2815080 Subject: [Rserpool] FW: Ports for Rserpool nameserver Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here is the response from Eric Rescorla on our security question. -- maureen -----Original Message----- From: ext Eric Rescorla [mailto:ekr@rtfm.com] Sent: Tuesday, April 08, 2003 11:21 PM To: Stillman Maureen (NVO-NIC/Ithaca) Cc: lyong@ciena.com Subject: Re: Ports for Rserpool nameserver Maureen, I don't know what the IESG's policy about separate ports versus application-layer signalling is these days. Keith Moore was the major player there and of course he's no longer AD. There are two ways to do an upward negotiation solution. One is unilateral. I.e. the client sends "STARTLS" first thing and then just starts negotiating TLS. This is obviously as secure as separate ports, since the client isn't switch-hitting. The other is real negotiation, in which the client requests TLS but is willing to switch-hit to normal application-layer traffic. In this case there's a downgrade attack. -Ekr > We are strongly in favor of using TLS for security in Reserpool to > protect the integrity of the namespace. TLS would be mandatory to > implement but optional to use. Given this, the ENRP name server would > listen on 2 ports for registration. One port for insecure > registrations from pool elements offering a services and the second > port for secure registrations using TLS. > > However, I had heard that the use of two different ports for a > service, one for security and one not is deprecated. Is this correct? > If so, is there a secure way to upgrade a connection that is not > secure to TLS? Isn't this tricky to implement correctly with > STARTTLS? We will be using both SCTP and TCP for this as transport. > We prefer the 2 port solution if the IESG would pass it. If they > won't then we need to find some good alternative. > > Thanks for any clarification you can give us. > > -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 9 14:33:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09030 for ; Wed, 9 Apr 2003 14:33:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Id3817786; Wed, 9 Apr 2003 14:39:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IcN817768 for ; Wed, 9 Apr 2003 14:38:23 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08976 for ; Wed, 9 Apr 2003 14:32:33 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39IZBZ27030 for ; Wed, 9 Apr 2003 13:35:11 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:35:05 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:34:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:34:01 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680D8@daebe007.americas.nokia.com> Thread-Topic: Rserpool minutes for IETF #56 Thread-Index: AcLv09G2TIIlu15cQZ2c3mzRNSXX5ADNeXiwAu6XyoA= To: X-OriginalArrivalTime: 09 Apr 2003 18:34:02.0291 (UTC) FILETIME=[97C2F030:01C2FEC6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IcN817769 Subject: [Rserpool] Rserpool short minutes for IETF #56 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Here is our summary. Please see www.ietf.org/proceedings03mar/index.html for the slides presented at the meeting. Any questions or comments on these minutes? > > -- maureen > > IETF #56 > Reliable Server Pooling WG (rserpool) > Monday, March 17, 2003 15:30-17:30 > > CHAIRs: > Lyndon Ong > Maureen Stillman > > Approximately 35 people attend the meeting. > > We discussed the services document draft-conrad-rserpool-service-03.txt. This draft describes the different services that rserpool can offer to the application. Recent discussions have resulted in some changes. An updated draft will be released shortly after IETF #56. The WG was asked to carefully review this document for any services that need to be added or changed. Service descriptions may need to be further refined on the mailing list. > > Outstanding issues with the tcpmapping document draft-conrad-rserpool-tcpmapping-01.txt were presented. Under discussion was the initial TSN (0 explicitly?) and message retrieval. Due to some changes agreed to in the services document, a better alignment with services draft will be included in the next draft. > > We discussed an open issue in the ASAP protocol draft-ietf-rserpool-asap-06.txt, specifically the configuration of the control and data channels. The concern is that if we allow different transport protocols for the control and data channels, the result is too complex. The consensus was to require data and control to use the same transport protocol and in addition, to use of separate pools for different protocols. Otherwise registration is complex and we prefer to keep it simple. > > Recent changes and issues concerning ENRP protocol draft-ietf-rserpool-enrp-04.txt were raised. We have added a Server_Announce message to allow name servers to broadcast so that PU or PE can find the home server. There was a question on the traffic impacts on wireless devices as it may create too much traffic. A possible solution is to limit multicast to wire, unicast over the air. The heartbeat mechanism must not be multicast, as multicast is not transparently supported across domains. Discussion of this issue will continue on the mailing list. > > The security design team has meet and discussed the security sections in both ASAP and ENRP. In addition, the design team reviewed the threat document, draft-ietf-rserpool-threats-00.txt. The open issue discussed is a requirement to ensure that if security is requested between the PU and ENRP server, then the PU is guaranteed not only to talk to an authenticated ENRP server, but also is guaranteed integrity and authentication of the PE registration data. These threats are documented in the threat document. > > Secondly, securing the control channel is an open issue. Given the consensus to require data and control channel to use the same transport solutions to the problem will be simpler. This will be further discussed on the list. The design team will continue working and report its findings to the list. The chair reopened the membership to any interested person. > > The applicability statement draft-coene-rserpool-applic-01.txt presents several examples or models of how Rserpool could be deployed. The group discussed that it needs to be aligned or merged with services document. The minimalist model was based on an IPFIX WG request. > > We discussed three current implementations of Rserpool from Siemens/University of Essen, Motorola and Temple University. > > Siemens/Essen: Linux, FreeBSD, DarwinOS For more information about this implementation, see: > http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ and http://www.sctp.de/rserpool.html. An introduction to design and implementation of our rsplib prototype is given in the paper at: > http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/#Research.> > > Motorola has an internal implementation; uses open source SCTP from sctp.org; Linux/Solaris > Temple has Kame SCTP; planning stages; FreeBSD. > > At this time the documents are becoming more stable with the exception of resolving security issues. The security design team will continue to meet with the expectation of resolving the above issues by IETF #57. > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 9 14:34:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09061 for ; Wed, 9 Apr 2003 14:34:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39IdgH17813 for rserpool-archive@odin.ietf.org; Wed, 9 Apr 2003 14:39:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Id3817786; Wed, 9 Apr 2003 14:39:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IcN817768 for ; Wed, 9 Apr 2003 14:38:23 -0400 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08976 for ; Wed, 9 Apr 2003 14:32:33 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h39IZBZ27030 for ; Wed, 9 Apr 2003 13:35:11 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 9 Apr 2003 13:35:05 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 9 Apr 2003 11:34:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Apr 2003 13:34:01 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680D8@daebe007.americas.nokia.com> Thread-Topic: Rserpool minutes for IETF #56 Thread-Index: AcLv09G2TIIlu15cQZ2c3mzRNSXX5ADNeXiwAu6XyoA= To: X-OriginalArrivalTime: 09 Apr 2003 18:34:02.0291 (UTC) FILETIME=[97C2F030:01C2FEC6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h39IcN817769 Subject: [Rserpool] Rserpool short minutes for IETF #56 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Here is our summary. Please see www.ietf.org/proceedings03mar/index.html for the slides presented at the meeting. Any questions or comments on these minutes? > > -- maureen > > IETF #56 > Reliable Server Pooling WG (rserpool) > Monday, March 17, 2003 15:30-17:30 > > CHAIRs: > Lyndon Ong > Maureen Stillman > > Approximately 35 people attend the meeting. > > We discussed the services document draft-conrad-rserpool-service-03.txt. This draft describes the different services that rserpool can offer to the application. Recent discussions have resulted in some changes. An updated draft will be released shortly after IETF #56. The WG was asked to carefully review this document for any services that need to be added or changed. Service descriptions may need to be further refined on the mailing list. > > Outstanding issues with the tcpmapping document draft-conrad-rserpool-tcpmapping-01.txt were presented. Under discussion was the initial TSN (0 explicitly?) and message retrieval. Due to some changes agreed to in the services document, a better alignment with services draft will be included in the next draft. > > We discussed an open issue in the ASAP protocol draft-ietf-rserpool-asap-06.txt, specifically the configuration of the control and data channels. The concern is that if we allow different transport protocols for the control and data channels, the result is too complex. The consensus was to require data and control to use the same transport protocol and in addition, to use of separate pools for different protocols. Otherwise registration is complex and we prefer to keep it simple. > > Recent changes and issues concerning ENRP protocol draft-ietf-rserpool-enrp-04.txt were raised. We have added a Server_Announce message to allow name servers to broadcast so that PU or PE can find the home server. There was a question on the traffic impacts on wireless devices as it may create too much traffic. A possible solution is to limit multicast to wire, unicast over the air. The heartbeat mechanism must not be multicast, as multicast is not transparently supported across domains. Discussion of this issue will continue on the mailing list. > > The security design team has meet and discussed the security sections in both ASAP and ENRP. In addition, the design team reviewed the threat document, draft-ietf-rserpool-threats-00.txt. The open issue discussed is a requirement to ensure that if security is requested between the PU and ENRP server, then the PU is guaranteed not only to talk to an authenticated ENRP server, but also is guaranteed integrity and authentication of the PE registration data. These threats are documented in the threat document. > > Secondly, securing the control channel is an open issue. Given the consensus to require data and control channel to use the same transport solutions to the problem will be simpler. This will be further discussed on the list. The design team will continue working and report its findings to the list. The chair reopened the membership to any interested person. > > The applicability statement draft-coene-rserpool-applic-01.txt presents several examples or models of how Rserpool could be deployed. The group discussed that it needs to be aligned or merged with services document. The minimalist model was based on an IPFIX WG request. > > We discussed three current implementations of Rserpool from Siemens/University of Essen, Motorola and Temple University. > > Siemens/Essen: Linux, FreeBSD, DarwinOS For more information about this implementation, see: > http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/ and http://www.sctp.de/rserpool.html. An introduction to design and implementation of our rsplib prototype is given in the paper at: > http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/#Research.> > > Motorola has an internal implementation; uses open source SCTP from sctp.org; Linux/Solaris > Temple has Kame SCTP; planning stages; FreeBSD. > > At this time the documents are becoming more stable with the exception of resolving security issues. The security design team will continue to meet with the expectation of resolving the above issues by IETF #57. > _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Fri Apr 11 15:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27712 for ; Fri, 11 Apr 2003 15:59:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BK5J823896; Fri, 11 Apr 2003 16:05:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJwS822960 for ; Fri, 11 Apr 2003 15:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27436 for ; Fri, 11 Apr 2003 15:51:38 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1944bH-0005FD-00 for rserpool@ietf.org; Fri, 11 Apr 2003 15:54:15 -0400 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by ietf-mx with esmtp (Exim 4.12) id 1944bG-0005F9-00 for rserpool@ietf.org; Fri, 11 Apr 2003 15:54:14 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3BJsEb22294 for ; Fri, 11 Apr 2003 14:54:14 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 11 Apr 2003 14:54:13 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 14:54:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 11 Apr 2003 14:54:13 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680DD@daebe007.americas.nokia.com> Thread-Topic: Security Design team conference call -- Tuesday, April 15 at 10AM EDT USA Thread-Index: AcMAZB/21gGYzdfSRouxMXMcot3mXg== To: X-OriginalArrivalTime: 11 Apr 2003 19:54:13.0784 (UTC) FILETIME=[20760180:01C30064] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3BJwS822961 Subject: [Rserpool] Security Design team conference call -- Tuesday, April 15 at 10AM EDT USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team teleconference will be held on Tuesday, April 15 at 10AM EDT USA. Note that the US has gone to daylight savings time. Here is the call in number: DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. We are open to everyone. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Fri Apr 11 15:59:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27757 for ; Fri, 11 Apr 2003 15:59:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BK61I24424 for rserpool-archive@odin.ietf.org; Fri, 11 Apr 2003 16:06:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BK5J823896; Fri, 11 Apr 2003 16:05:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJwS822960 for ; Fri, 11 Apr 2003 15:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27436 for ; Fri, 11 Apr 2003 15:51:38 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1944bH-0005FD-00 for rserpool@ietf.org; Fri, 11 Apr 2003 15:54:15 -0400 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by ietf-mx with esmtp (Exim 4.12) id 1944bG-0005F9-00 for rserpool@ietf.org; Fri, 11 Apr 2003 15:54:14 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3BJsEb22294 for ; Fri, 11 Apr 2003 14:54:14 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 11 Apr 2003 14:54:13 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 14:54:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 11 Apr 2003 14:54:13 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680DD@daebe007.americas.nokia.com> Thread-Topic: Security Design team conference call -- Tuesday, April 15 at 10AM EDT USA Thread-Index: AcMAZB/21gGYzdfSRouxMXMcot3mXg== To: X-OriginalArrivalTime: 11 Apr 2003 19:54:13.0784 (UTC) FILETIME=[20760180:01C30064] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3BJwS822961 Subject: [Rserpool] Security Design team conference call -- Tuesday, April 15 at 10AM EDT USA Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next security design team teleconference will be held on Tuesday, April 15 at 10AM EDT USA. Note that the US has gone to daylight savings time. Here is the call in number: DIAL-IN NUMBERS & PASSCODES: USA Toll Free Number: 877-940-8608 USA Toll Number: +1-712-247-6284 (for international callers) PARTICIPANT PASSCODE: 538600 We will discuss outstanding security issues. It is not too late to join the design team. We are open to everyone. Just drop me an e-mail. Thanks. -- maureen _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Mon Apr 14 21:41:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29797 for ; Mon, 14 Apr 2003 21:41:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1nB809793; Mon, 14 Apr 2003 21:49:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1mM809748 for ; Mon, 14 Apr 2003 21:48:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29773 for ; Mon, 14 Apr 2003 21:39:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195FSw-0006kD-00 for rserpool@ietf.org; Mon, 14 Apr 2003 21:42:30 -0400 Received: from [144.189.100.106] (helo=motgate6.mot.com) by ietf-mx with esmtp (Exim 4.12) id 195FSu-0006kA-00 for rserpool@ietf.org; Mon, 14 Apr 2003 21:42:29 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3F1gXvF006793 for ; Mon, 14 Apr 2003 18:42:34 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA18218 for ; Mon, 14 Apr 2003 18:42:33 -0700 (MST)] Received: from motorola.com (VAIO30 [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANR2FB; Mon, 14 Apr 2003 20:42:29 -0500 Message-ID: <3E9B5B2F.4A9059A1@motorola.com> Date: Mon, 14 Apr 2003 20:06:57 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: WG IETF rserpool , Harrie Hazewinkel Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Harrie, Thanks for your comments. Please see my response in-line.... -Qiaobing Harrie Hazewinkel wrote: > > Hi all, > > Below some comments on draft-ietf-rserpool-common-param-03.txt. > > Harrie > > > Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution > > Protocol (ENRP) common parameters document > > 'document' adds nothing to the title, I suggest to drop it. > > While reading this document, I got the impression that not all > items defined are common for both protocols. Some are for ASAP > and some are for ENRP only. If so, I would suggest to reflect this > in the title, abstract and introduction. > A simple mean to achieve this is to > do 'common parameters' -> 'parameters' Sounds a good idea. consider done. > > > Abstract > > Abstract equals the Introduction, I suggest a new (following) abstract. > > This document details the common parameters of the Aggregate Server > Access Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) > protocols defined within the Reliable Server Pooling (RSERPOOL) > architecture. ok. > > > 2. Parameters in General > > > > .. For fields with a length bigger than 4 octets, a > > number in a pair of parentheses may follow the field name to > > indicate the length of the field in number of octets. > > I do not understand this sentence. This convention is actually not used in the doc. I think it's safe to remove the sentence here. > > > 3. ENRP-ASAP Common Parameters > > > > Parameters are defined in the following Type-length-value (TLV) > ^ ^ > NIT: capitals?? ok > > > Parameter Type: 16 bits (unsigned integer) > > > > The Type field is a 16 bit identifier of the type of parameter. It > > takes a value of 0 to 65534. > > > > The value of 65535 is reserved for IETF-defined extensions. Values > > other than those defined in specific ENRP parameter description are > > reserved for use by IETF. > > How can enterprise specifc extensions be done?? > Is there a potential future need for this?? The company or organization will simply need to go through IETF and IANA and register its extensions. This is the standard way to do this in IETF. > > > > > Parameter Value: variable-length. > > > > The Parameter Value field contains the actual information to be > > transferred in the parameter. > > IMHO, it would clarify if you mention that the part of your comment is missing here. > > > > > The total length of a parameter (including Type, Parameter Length > > and > > Value fields) MUST be a multiple of 4 bytes. If the length of the > > parameter is not a multiple of 4 bytes, the sender pads the > > Parameter > > 'the sender pads' -> 'the sender MUST pad' > (although, the MUST is also defined just before) ok > > > at the end (i.e., after the Parameter Value field) with all zero > > bytes. The length of this padding is not included in the parameter > > length field. A sender SHOULD NOT pad with more than 3 bytes. The > > receiver MUST ignore the padding bytes. > > I am not sure, but 'SHOULD NOT' is 'MUST NOT'. > Correct me if I am wrong. Since the padding is not included in the > length > there is otherwise no way to find out where the new TLV starts. ok. changed to MUST NOT. > > > > > (Editor's note: clarify further that any padding inside in the > > parameter, such as the padding in sub-param is included in the total > > length) > > You could specify that one or more TLVs inside another TLV is just seen > as the parameter value. Then immplicit it is defined and some examples > can provide the clarity. This is one thing that confused implementors repeatedly in SCTP. We will need to make this very clear. May borrow some text from SCTP impl guide. > > > The Parameter Types are encoded such that the highest-order two bits > > specify the action that must be taken if the processing endpoint > > does > > not recognize the Parameter Type. > > The part above until section 3.1 is better to be moved to the > Parameter Type explaination before. In the document you are now > at Parameter Value and jump back. good point. done (I made more re-arrangement than you suggested). > > > 3.3 SCTP Transport Parameter > > > > Transport use: 16 bits (unsigned interger) > ^ > 'interger' -> 'integer' > (Happens for more 'Transport ....' lines) ok > > > IPv4 or IPv6 Address #1 - #n: > > > > Each indicates an IPv4 or IPv6 address parameter (as defined above > > in > > Section 3.1 and Section 3.2) assigned to this SCTP user transport. > > At least one IP address parameter MUST be present in an SCTP > > transport parameter. > > Just to be sure, but are IPv4 and IPv6 addresses allowed to be > mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? yes. they are allowed to be mixed in SCTP > > > > > 3.5 UDP Transport Parameter > > > > Note: A UDP port MUST NOT be used for control information. For this > > reason, no Transport Use field is provided. UDP MUST always be > > treated as a "Data Only" type transport use. > > Why not 'forcing' the value 'DATA ONLY'?? that's certainly another way to do it. we are looking at whether to keep this field. > > > 3.6 Pool Member Selection Policy Parameter > > > > This parameter defines a pool member selection policy. RSERPOOL > > supports multiple pool member selection polices and also allows > ^^^ > 'polices' -> 'policies' > > > definition of new selection polices in the future. > ^^^ > 'polices' -> 'policies' ok > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0x6 | Length = variable | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Policy Type | Policy-specific Data.... > > +-+-+-+-+-+-+-+-+------------------------------------------------ > > Why would you suddenly do not align in 4 bytes?? Fields are not always aligned to 4 bytes (we in fact have 1 bit, 16-bit fields/flags in many places). > > > > > Length: 16 bits (unsigned integer) > > > > Indicates the entire length of the parameter in number of octets, > > including the Type, Length, Policy Type fields, and the > > Policy-specific Data. > > Not sure, but in the figure is a single 'Policy Type' specified and you > speak here of 'Policy Type fields'. ok. wording refined. > > > > Note, the value in Length field will NOT cover any padding at the end > > of the parameter, if there is one. > > 'one' -> 'padding' (clarity) Still feel 'one' reads better. > > > Value Policy > > ----- --------- > > 0x0 (reserved by IETF) > > 0x1 Round Robin > > 0x2 Least Used > > 0x3 Least Used with Degradation (a.k.a. dog pile) > > 0x4 Weighted Round Robin > > others (reserved by IETF) > > How are enterprise specific policies handled?? Or is that not foreseen > now and in the future?? They will simply be defined in separate RFCs. > > > > > Policy-specific Data: > > > > The structure and fields for each presently defined policy types are > > 'types are' -> 'type is' > Not native speaker, but each makes it single, or not?? no. It's correct. Should read "The structure and ... are ..." > > > described in detail in the following subsections. The enforcement > > rules and handling procedures of these policies are defined in > > Section xxxxx in ASAP [4]. > > If those policy types are ASAP specific, maybe the types should be > described in > that document, since they are not common to ENRP and ASAP. No. Both ENRP and ASAP need to use them. Normally ASAP sends them and ENRP receives them. > > > 3.6.1 Round Robin Policy > > 3.6.2 Least Used Policy > > 3.6.3 Least Used with Degradation Policy > > 3.6.4 Weighted Round Robin Policy > > These are examples of useages from the first format presented in > section 3.6, right?? > I believe it is better to make this more clear, since I was first > confused if this > needed to go into the 'Policy-specifc Data' field. No. 3.6 is just a general template and 3.6.1 to 3.6.4 are actually parameter definitions that follow the template. > > > > > > > 3.8 Pool Element Parameter > > > > This parameter is used in multiple ENRP messages to represent an ASAP > > endpoint (i.e., a PE in a pool) and the associated information, such > > as its transport address(es), selection policy, and other operational > > or status information of the PE. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0x8 | Length=variable | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PE Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home ENRP Server Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Registration Life | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #1 : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #2 : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : : > > : ..... : > > : : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #k : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : Member Selection Policy param : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Member Selection Policy: > > I would suggest to move this parameter before the User Transport, > since there is not a specific count of 'User Transport' parameters. > OK, you can calculate it from the length of the complete parameter, > but I beleive it eases implementation. This is being change in v07. Please re-read it and see if it's better. > > > Server Transport: > > > > This is an SCTP Transport Parameter, as defined in Section 3.3 that > > contains the network access address(es), SCTP port number, etc. of > > the ENRP server. > > Is this only SCTP?? (Not sure) Yes. ENRP is always on SCTP. > > > Error causes are defined as variable-length parameters using the > > format described in 3.2.1 of RFC2960 [3], i.e.: > > I suggest the start of new section 'Error Cause Parameter'. > Also why the reference to [3]. Since you copy the complete > definition it is redundant and let people believe this is SCTP. a new sect maybe too busy but removing the ref sounds a good point. > > > Defines the type of error condition being reported. > > Cause Code > > Value Cause Code > > --------- ---------------- > > 1 Unrecognized Parameter > > 2 Unrecognized Message > > 3 Invalid Values > > 4 Non-unique PE Identifier > > 5 Pooling Policy Inconsistent > > 6 Lack of Resources > > other values reserved by IETF > > > > Cause-specific Information: variable length > > Assuming this is completely implementation dependant, I believe that > in this case also needs something as what caused it. For instance when > error cause '1' happens it must be indicated which parameter it was. > Although, this is maybe protocol specific semantics. yes. it is indeed reported back. See 3.10.1 for example - "The unrecognized parameter is included as cause specific information." > > > The following subsections (Section 3.10.1 - Section 3.10.2) define > > specific error causes. > > 1) I believe that only specifying the first 2 error causes is not > enough. They all should be defined. there is text missing. will be added in v07. > > 2) Are these really all errors that are possible?? We add more whenever we (especially the implementors) find necessary. But we should try to minimize the number of errors here. Each one adds complexity to the stack. > > 3) How can one make new error causes and/or enterprise specific ones. > Maybe it is better to define this and forsee already how new error > causes can be added and how compatibility of implementations that do not know > those new error codes must be handled. We hope to get feedback from implementors on this. In the future, if a new error cause is identified after the RFC is final, a separate draft can be used to add new error causes. > An idea is adding an Unrecognized Error to which it than can be mapped. Please explain more on this. > > > > 3.13 Communication Restrictions Parameter > > > > This parameter defines a TLV that can be used by the sender to > > restrict name server searches to a limited number of transport > > types. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0xd | Length=0x8 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Control Type | Data Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Previous the doc always specifies the item Length also. > Why not here? This will go away in v07. > > > Type | Value > > -----------+------------- > > ANY | 0x0000 > > SCTP ONLY | 0x0001 > > TCP ONLY | 0x0002 > > Why not specifying other as well. Allows extension and backwards > compatibility > for the future (maybe). > > > > > > Data Type: 16 bits (unsigned integer) > > > > This field requests the search be restricted to PE's that have a > > data > > channel type of the specified type. One of the following values > > MUST > > be used: > > > > Type | Value > > -----------+------------- > > ANY | 0x0000 > > SCTP ONLY | 0x0001 > > TCP ONLY | 0x0002 > > UDP ONLY | 0x0003 > > I neither understand why the values of 'Data Type' and 'Control Type' > are different. A 'Control Type' of UDP could be possible. Whether it > will work well is a different thing. > > Making these values equal eases it for implementors I guess too. ditto. > > > > > 4. Common Message Formats > > > > 10 reserved. > > > > 11 reserved. > > Although reserved, but what is suggested for to do when these values > are received?? Handle it as '00'? If a reserved value is used, it could be treated as a protocol error. > > > This value represents the size of the message in bytes including the > > Message Type, Message Flags, Message Length, and Message Value > > fields. Therefore, if the Message Value field is zero-length, the > > Length field will be set to 4. The Message Length field does not > > count any padding. > > > > Note, the value in Message Length field will NOT cover any padding at > > the end of this message. > > The 'Note,..' is equal in semantics to the previous sentence. > IMHO, drop it. ok. > > > > > 5. Security Considerations > > > > Details on ENRP and ASAP security constraints are a addressed in ENRP > ^ > > 'are a addressed' -> 'are addressed' ok > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Mon Apr 14 21:42:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29812 for ; Mon, 14 Apr 2003 21:42:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F1nri09833 for rserpool-archive@odin.ietf.org; Mon, 14 Apr 2003 21:49:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1nB809793; Mon, 14 Apr 2003 21:49:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1mM809748 for ; Mon, 14 Apr 2003 21:48:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29773 for ; Mon, 14 Apr 2003 21:39:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195FSw-0006kD-00 for rserpool@ietf.org; Mon, 14 Apr 2003 21:42:30 -0400 Received: from [144.189.100.106] (helo=motgate6.mot.com) by ietf-mx with esmtp (Exim 4.12) id 195FSu-0006kA-00 for rserpool@ietf.org; Mon, 14 Apr 2003 21:42:29 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3F1gXvF006793 for ; Mon, 14 Apr 2003 18:42:34 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA18218 for ; Mon, 14 Apr 2003 18:42:33 -0700 (MST)] Received: from motorola.com (VAIO30 [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANR2FB; Mon, 14 Apr 2003 20:42:29 -0500 Message-ID: <3E9B5B2F.4A9059A1@motorola.com> Date: Mon, 14 Apr 2003 20:06:57 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: WG IETF rserpool , Harrie Hazewinkel Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Harrie, Thanks for your comments. Please see my response in-line.... -Qiaobing Harrie Hazewinkel wrote: > > Hi all, > > Below some comments on draft-ietf-rserpool-common-param-03.txt. > > Harrie > > > Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution > > Protocol (ENRP) common parameters document > > 'document' adds nothing to the title, I suggest to drop it. > > While reading this document, I got the impression that not all > items defined are common for both protocols. Some are for ASAP > and some are for ENRP only. If so, I would suggest to reflect this > in the title, abstract and introduction. > A simple mean to achieve this is to > do 'common parameters' -> 'parameters' Sounds a good idea. consider done. > > > Abstract > > Abstract equals the Introduction, I suggest a new (following) abstract. > > This document details the common parameters of the Aggregate Server > Access Protocol (ASAP) and Endpoint Name Resolution Protocol (ENRP) > protocols defined within the Reliable Server Pooling (RSERPOOL) > architecture. ok. > > > 2. Parameters in General > > > > .. For fields with a length bigger than 4 octets, a > > number in a pair of parentheses may follow the field name to > > indicate the length of the field in number of octets. > > I do not understand this sentence. This convention is actually not used in the doc. I think it's safe to remove the sentence here. > > > 3. ENRP-ASAP Common Parameters > > > > Parameters are defined in the following Type-length-value (TLV) > ^ ^ > NIT: capitals?? ok > > > Parameter Type: 16 bits (unsigned integer) > > > > The Type field is a 16 bit identifier of the type of parameter. It > > takes a value of 0 to 65534. > > > > The value of 65535 is reserved for IETF-defined extensions. Values > > other than those defined in specific ENRP parameter description are > > reserved for use by IETF. > > How can enterprise specifc extensions be done?? > Is there a potential future need for this?? The company or organization will simply need to go through IETF and IANA and register its extensions. This is the standard way to do this in IETF. > > > > > Parameter Value: variable-length. > > > > The Parameter Value field contains the actual information to be > > transferred in the parameter. > > IMHO, it would clarify if you mention that the part of your comment is missing here. > > > > > The total length of a parameter (including Type, Parameter Length > > and > > Value fields) MUST be a multiple of 4 bytes. If the length of the > > parameter is not a multiple of 4 bytes, the sender pads the > > Parameter > > 'the sender pads' -> 'the sender MUST pad' > (although, the MUST is also defined just before) ok > > > at the end (i.e., after the Parameter Value field) with all zero > > bytes. The length of this padding is not included in the parameter > > length field. A sender SHOULD NOT pad with more than 3 bytes. The > > receiver MUST ignore the padding bytes. > > I am not sure, but 'SHOULD NOT' is 'MUST NOT'. > Correct me if I am wrong. Since the padding is not included in the > length > there is otherwise no way to find out where the new TLV starts. ok. changed to MUST NOT. > > > > > (Editor's note: clarify further that any padding inside in the > > parameter, such as the padding in sub-param is included in the total > > length) > > You could specify that one or more TLVs inside another TLV is just seen > as the parameter value. Then immplicit it is defined and some examples > can provide the clarity. This is one thing that confused implementors repeatedly in SCTP. We will need to make this very clear. May borrow some text from SCTP impl guide. > > > The Parameter Types are encoded such that the highest-order two bits > > specify the action that must be taken if the processing endpoint > > does > > not recognize the Parameter Type. > > The part above until section 3.1 is better to be moved to the > Parameter Type explaination before. In the document you are now > at Parameter Value and jump back. good point. done (I made more re-arrangement than you suggested). > > > 3.3 SCTP Transport Parameter > > > > Transport use: 16 bits (unsigned interger) > ^ > 'interger' -> 'integer' > (Happens for more 'Transport ....' lines) ok > > > IPv4 or IPv6 Address #1 - #n: > > > > Each indicates an IPv4 or IPv6 address parameter (as defined above > > in > > Section 3.1 and Section 3.2) assigned to this SCTP user transport. > > At least one IP address parameter MUST be present in an SCTP > > transport parameter. > > Just to be sure, but are IPv4 and IPv6 addresses allowed to be > mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? yes. they are allowed to be mixed in SCTP > > > > > 3.5 UDP Transport Parameter > > > > Note: A UDP port MUST NOT be used for control information. For this > > reason, no Transport Use field is provided. UDP MUST always be > > treated as a "Data Only" type transport use. > > Why not 'forcing' the value 'DATA ONLY'?? that's certainly another way to do it. we are looking at whether to keep this field. > > > 3.6 Pool Member Selection Policy Parameter > > > > This parameter defines a pool member selection policy. RSERPOOL > > supports multiple pool member selection polices and also allows > ^^^ > 'polices' -> 'policies' > > > definition of new selection polices in the future. > ^^^ > 'polices' -> 'policies' ok > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0x6 | Length = variable | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Policy Type | Policy-specific Data.... > > +-+-+-+-+-+-+-+-+------------------------------------------------ > > Why would you suddenly do not align in 4 bytes?? Fields are not always aligned to 4 bytes (we in fact have 1 bit, 16-bit fields/flags in many places). > > > > > Length: 16 bits (unsigned integer) > > > > Indicates the entire length of the parameter in number of octets, > > including the Type, Length, Policy Type fields, and the > > Policy-specific Data. > > Not sure, but in the figure is a single 'Policy Type' specified and you > speak here of 'Policy Type fields'. ok. wording refined. > > > > Note, the value in Length field will NOT cover any padding at the end > > of the parameter, if there is one. > > 'one' -> 'padding' (clarity) Still feel 'one' reads better. > > > Value Policy > > ----- --------- > > 0x0 (reserved by IETF) > > 0x1 Round Robin > > 0x2 Least Used > > 0x3 Least Used with Degradation (a.k.a. dog pile) > > 0x4 Weighted Round Robin > > others (reserved by IETF) > > How are enterprise specific policies handled?? Or is that not foreseen > now and in the future?? They will simply be defined in separate RFCs. > > > > > Policy-specific Data: > > > > The structure and fields for each presently defined policy types are > > 'types are' -> 'type is' > Not native speaker, but each makes it single, or not?? no. It's correct. Should read "The structure and ... are ..." > > > described in detail in the following subsections. The enforcement > > rules and handling procedures of these policies are defined in > > Section xxxxx in ASAP [4]. > > If those policy types are ASAP specific, maybe the types should be > described in > that document, since they are not common to ENRP and ASAP. No. Both ENRP and ASAP need to use them. Normally ASAP sends them and ENRP receives them. > > > 3.6.1 Round Robin Policy > > 3.6.2 Least Used Policy > > 3.6.3 Least Used with Degradation Policy > > 3.6.4 Weighted Round Robin Policy > > These are examples of useages from the first format presented in > section 3.6, right?? > I believe it is better to make this more clear, since I was first > confused if this > needed to go into the 'Policy-specifc Data' field. No. 3.6 is just a general template and 3.6.1 to 3.6.4 are actually parameter definitions that follow the template. > > > > > > > 3.8 Pool Element Parameter > > > > This parameter is used in multiple ENRP messages to represent an ASAP > > endpoint (i.e., a PE in a pool) and the associated information, such > > as its transport address(es), selection policy, and other operational > > or status information of the PE. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0x8 | Length=variable | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PE Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home ENRP Server Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Registration Life | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #1 : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #2 : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : : > > : ..... : > > : : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : User Transport param #k : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : Member Selection Policy param : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Member Selection Policy: > > I would suggest to move this parameter before the User Transport, > since there is not a specific count of 'User Transport' parameters. > OK, you can calculate it from the length of the complete parameter, > but I beleive it eases implementation. This is being change in v07. Please re-read it and see if it's better. > > > Server Transport: > > > > This is an SCTP Transport Parameter, as defined in Section 3.3 that > > contains the network access address(es), SCTP port number, etc. of > > the ENRP server. > > Is this only SCTP?? (Not sure) Yes. ENRP is always on SCTP. > > > Error causes are defined as variable-length parameters using the > > format described in 3.2.1 of RFC2960 [3], i.e.: > > I suggest the start of new section 'Error Cause Parameter'. > Also why the reference to [3]. Since you copy the complete > definition it is redundant and let people believe this is SCTP. a new sect maybe too busy but removing the ref sounds a good point. > > > Defines the type of error condition being reported. > > Cause Code > > Value Cause Code > > --------- ---------------- > > 1 Unrecognized Parameter > > 2 Unrecognized Message > > 3 Invalid Values > > 4 Non-unique PE Identifier > > 5 Pooling Policy Inconsistent > > 6 Lack of Resources > > other values reserved by IETF > > > > Cause-specific Information: variable length > > Assuming this is completely implementation dependant, I believe that > in this case also needs something as what caused it. For instance when > error cause '1' happens it must be indicated which parameter it was. > Although, this is maybe protocol specific semantics. yes. it is indeed reported back. See 3.10.1 for example - "The unrecognized parameter is included as cause specific information." > > > The following subsections (Section 3.10.1 - Section 3.10.2) define > > specific error causes. > > 1) I believe that only specifying the first 2 error causes is not > enough. They all should be defined. there is text missing. will be added in v07. > > 2) Are these really all errors that are possible?? We add more whenever we (especially the implementors) find necessary. But we should try to minimize the number of errors here. Each one adds complexity to the stack. > > 3) How can one make new error causes and/or enterprise specific ones. > Maybe it is better to define this and forsee already how new error > causes can be added and how compatibility of implementations that do not know > those new error codes must be handled. We hope to get feedback from implementors on this. In the future, if a new error cause is identified after the RFC is final, a separate draft can be used to add new error causes. > An idea is adding an Unrecognized Error to which it than can be mapped. Please explain more on this. > > > > 3.13 Communication Restrictions Parameter > > > > This parameter defines a TLV that can be used by the sender to > > restrict name server searches to a limited number of transport > > types. > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0xd | Length=0x8 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Control Type | Data Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Previous the doc always specifies the item Length also. > Why not here? This will go away in v07. > > > Type | Value > > -----------+------------- > > ANY | 0x0000 > > SCTP ONLY | 0x0001 > > TCP ONLY | 0x0002 > > Why not specifying other as well. Allows extension and backwards > compatibility > for the future (maybe). > > > > > > Data Type: 16 bits (unsigned integer) > > > > This field requests the search be restricted to PE's that have a > > data > > channel type of the specified type. One of the following values > > MUST > > be used: > > > > Type | Value > > -----------+------------- > > ANY | 0x0000 > > SCTP ONLY | 0x0001 > > TCP ONLY | 0x0002 > > UDP ONLY | 0x0003 > > I neither understand why the values of 'Data Type' and 'Control Type' > are different. A 'Control Type' of UDP could be possible. Whether it > will work well is a different thing. > > Making these values equal eases it for implementors I guess too. ditto. > > > > > 4. Common Message Formats > > > > 10 reserved. > > > > 11 reserved. > > Although reserved, but what is suggested for to do when these values > are received?? Handle it as '00'? If a reserved value is used, it could be treated as a protocol error. > > > This value represents the size of the message in bytes including the > > Message Type, Message Flags, Message Length, and Message Value > > fields. Therefore, if the Message Value field is zero-length, the > > Length field will be set to 4. The Message Length field does not > > count any padding. > > > > Note, the value in Message Length field will NOT cover any padding at > > the end of this message. > > The 'Note,..' is equal in semantics to the previous sentence. > IMHO, drop it. ok. > > > > > 5. Security Considerations > > > > Details on ENRP and ASAP security constraints are a addressed in ENRP > ^ > > 'are a addressed' -> 'are addressed' ok > > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 15 03:35:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18170 for ; Tue, 15 Apr 2003 03:35:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7h7812151; Tue, 15 Apr 2003 03:43:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7gI812109 for ; Tue, 15 Apr 2003 03:42:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18106 for ; Tue, 15 Apr 2003 03:33:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195KzK-0000kv-00 for rserpool@ietf.org; Tue, 15 Apr 2003 03:36:18 -0400 Received: from hal-4.inet.it ([213.92.5.23]) by ietf-mx with esmtp (Exim 4.12) id 195KzJ-0000ks-00 for rserpool@ietf.org; Tue, 15 Apr 2003 03:36:17 -0400 Received: from [::ffff:213.92.1.193] by hal-4.inet.it via I-SMTP-4.3.7-430 id ::ffff:213.92.1.193+xKQHEjEi4PLC; Tue, 15 Apr 2003 09:36:21 +0200 Date: Tue, 15 Apr 2003 09:39:55 +0200 Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel , WG IETF rserpool To: Qiaobing Xie From: Harrie Hazewinkel In-Reply-To: <3E9B5B2F.4A9059A1@motorola.com> Message-Id: <73C5FC0C-6F15-11D7-BC08-0003934A5A7E@jumpy.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI, Some extra clarification/comment based on your response. On Tuesday, April 15, 2003, at 03:06 AM, Qiaobing Xie wrote: >>> Parameter Type: 16 bits (unsigned integer) >>> >>> The Type field is a 16 bit identifier of the type of parameter. >>> It >>> takes a value of 0 to 65534. >>> >>> The value of 65535 is reserved for IETF-defined extensions. >>> Values >>> other than those defined in specific ENRP parameter description >>> are >>> reserved for use by IETF. >> >> How can enterprise specifc extensions be done?? >> Is there a potential future need for this?? > > The company or organization will simply need to go through IETF and > IANA > and register its extensions. This is the standard way to do this in > IETF. Then I suggest adding this. If I now want to make some extension I would not know this. >>> Parameter Value: variable-length. >>> >>> The Parameter Value field contains the actual information to be >>> transferred in the parameter. >> >> IMHO, it would clarify if you mention that the > > part of your comment is missing here. Oops, just ignore this. I would not know what to clarify it now while reading again. Sorry. >>> IPv4 or IPv6 Address #1 - #n: >>> >>> Each indicates an IPv4 or IPv6 address parameter (as defined above >>> in >>> Section 3.1 and Section 3.2) assigned to this SCTP user transport. >>> At least one IP address parameter MUST be present in an SCTP >>> transport parameter. >> >> Just to be sure, but are IPv4 and IPv6 addresses allowed to be >> mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? > > yes. they are allowed to be mixed in SCTP Maybe wise to add this. >>> Note, the value in Length field will NOT cover any padding at the >>> end >>> of the parameter, if there is one. >> >> 'one' -> 'padding' (clarity) > > Still feel 'one' reads better. Then I believe it should be any, since padding can consist of multiple bytes. Maybe on time padding. I guess this is a border case and I am not a linguistic. Otherwise, leaves as is. >> >>> described in detail in the following subsections. The enforcement >>> rules and handling procedures of these policies are defined in >>> Section xxxxx in ASAP [4]. >> >> If those policy types are ASAP specific, maybe the types should be >> described in >> that document, since they are not common to ENRP and ASAP. > > No. Both ENRP and ASAP need to use them. Normally ASAP sends them and > ENRP receives them. This confuses me, 'ASAP sends them and ENRP receives them'. You are not meaning here that an ASAP protocol engine speaks directly with an ENRP protocol engine. At least your comment makes this unclear. But if they are used in both protocols they should be in this document. >>> 3.6.1 Round Robin Policy >>> 3.6.2 Least Used Policy >>> 3.6.3 Least Used with Degradation Policy >>> 3.6.4 Weighted Round Robin Policy >> >> These are examples of useages from the first format presented in >> section 3.6, right?? >> I believe it is better to make this more clear, since I was first >> confused if this >> needed to go into the 'Policy-specifc Data' field. > > No. 3.6 is just a general template and 3.6.1 to 3.6.4 are actually > parameter definitions that follow the template. I see what you mean here. I assume this also is fixed when the TBD is done in a next update. >>> 3.8 Pool Element Parameter >>> >>> This parameter is used in multiple ENRP messages to represent an >>> ASAP >>> endpoint (i.e., a PE in a pool) and the associated information, >>> such >>> as its transport address(es), selection policy, and other >>> operational >>> or status information of the PE. >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type = 0x8 | Length=variable | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PE Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Home ENRP Server Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Registration Life | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #1 : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #2 : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : : >>> : ..... : >>> : : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #k : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : Member Selection Policy param : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Member Selection Policy: >> >> I would suggest to move this parameter before the User Transport, >> since there is not a specific count of 'User Transport' parameters. >> OK, you can calculate it from the length of the complete parameter, >> but I beleive it eases implementation. > > This is being change in v07. Please re-read it and see if it's better. You mean the ASAP draft version 07?? Or common parameters draft version 04?? >> >> 3) How can one make new error causes and/or enterprise specific ones. >> Maybe it is better to define this and forsee already how new error >> causes can be added and how compatibility of implementations that do >> not know >> those new error codes must be handled. > > We hope to get feedback from implementors on this. In the future, if a > new error cause is identified after the RFC is final, a separate draft > can be used to add new error causes. Maybe it could be an idea to make these error IANA maintained. That way only once they need to be published as RFC (original one) and updated do not need that. I understood that this way the way the IESG also handles similar things for SNMP textual conventions. > >> An idea is adding an Unrecognized Error to which it than can be >> mapped. > > Please explain more on this. Not needed, while thinking of it again it is not a good idea anyway. Section 3.10, 3.10.1 and 3.10.2 explains error parameter and if an error code is not understood by the other side, it could be treated as an 'Invalid Value' and no new Cause code is needed. Meaning the 'Unrecognized Error'-code I thought of is simply an 'Invalid value' of the Error Parameter. >> >>> >>> 4. Common Message Formats >>> >>> 10 reserved. >>> >>> 11 reserved. >> >> Although reserved, but what is suggested for to do when these values >> are received?? Handle it as '00'? > > If a reserved value is used, it could be treated as a protocol error. 'It could' makes me believe there is a potential for non-interoperability. I believe this better needs to be defined. Harrie _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 15 03:35:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18190 for ; Tue, 15 Apr 2003 03:35:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F7hqB12208 for rserpool-archive@odin.ietf.org; Tue, 15 Apr 2003 03:43:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7h7812151; Tue, 15 Apr 2003 03:43:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F7gI812109 for ; Tue, 15 Apr 2003 03:42:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18106 for ; Tue, 15 Apr 2003 03:33:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195KzK-0000kv-00 for rserpool@ietf.org; Tue, 15 Apr 2003 03:36:18 -0400 Received: from hal-4.inet.it ([213.92.5.23]) by ietf-mx with esmtp (Exim 4.12) id 195KzJ-0000ks-00 for rserpool@ietf.org; Tue, 15 Apr 2003 03:36:17 -0400 Received: from [::ffff:213.92.1.193] by hal-4.inet.it via I-SMTP-4.3.7-430 id ::ffff:213.92.1.193+xKQHEjEi4PLC; Tue, 15 Apr 2003 09:36:21 +0200 Date: Tue, 15 Apr 2003 09:39:55 +0200 Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel , WG IETF rserpool To: Qiaobing Xie From: Harrie Hazewinkel In-Reply-To: <3E9B5B2F.4A9059A1@motorola.com> Message-Id: <73C5FC0C-6F15-11D7-BC08-0003934A5A7E@jumpy.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit HI, Some extra clarification/comment based on your response. On Tuesday, April 15, 2003, at 03:06 AM, Qiaobing Xie wrote: >>> Parameter Type: 16 bits (unsigned integer) >>> >>> The Type field is a 16 bit identifier of the type of parameter. >>> It >>> takes a value of 0 to 65534. >>> >>> The value of 65535 is reserved for IETF-defined extensions. >>> Values >>> other than those defined in specific ENRP parameter description >>> are >>> reserved for use by IETF. >> >> How can enterprise specifc extensions be done?? >> Is there a potential future need for this?? > > The company or organization will simply need to go through IETF and > IANA > and register its extensions. This is the standard way to do this in > IETF. Then I suggest adding this. If I now want to make some extension I would not know this. >>> Parameter Value: variable-length. >>> >>> The Parameter Value field contains the actual information to be >>> transferred in the parameter. >> >> IMHO, it would clarify if you mention that the > > part of your comment is missing here. Oops, just ignore this. I would not know what to clarify it now while reading again. Sorry. >>> IPv4 or IPv6 Address #1 - #n: >>> >>> Each indicates an IPv4 or IPv6 address parameter (as defined above >>> in >>> Section 3.1 and Section 3.2) assigned to this SCTP user transport. >>> At least one IP address parameter MUST be present in an SCTP >>> transport parameter. >> >> Just to be sure, but are IPv4 and IPv6 addresses allowed to be >> mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? > > yes. they are allowed to be mixed in SCTP Maybe wise to add this. >>> Note, the value in Length field will NOT cover any padding at the >>> end >>> of the parameter, if there is one. >> >> 'one' -> 'padding' (clarity) > > Still feel 'one' reads better. Then I believe it should be any, since padding can consist of multiple bytes. Maybe on time padding. I guess this is a border case and I am not a linguistic. Otherwise, leaves as is. >> >>> described in detail in the following subsections. The enforcement >>> rules and handling procedures of these policies are defined in >>> Section xxxxx in ASAP [4]. >> >> If those policy types are ASAP specific, maybe the types should be >> described in >> that document, since they are not common to ENRP and ASAP. > > No. Both ENRP and ASAP need to use them. Normally ASAP sends them and > ENRP receives them. This confuses me, 'ASAP sends them and ENRP receives them'. You are not meaning here that an ASAP protocol engine speaks directly with an ENRP protocol engine. At least your comment makes this unclear. But if they are used in both protocols they should be in this document. >>> 3.6.1 Round Robin Policy >>> 3.6.2 Least Used Policy >>> 3.6.3 Least Used with Degradation Policy >>> 3.6.4 Weighted Round Robin Policy >> >> These are examples of useages from the first format presented in >> section 3.6, right?? >> I believe it is better to make this more clear, since I was first >> confused if this >> needed to go into the 'Policy-specifc Data' field. > > No. 3.6 is just a general template and 3.6.1 to 3.6.4 are actually > parameter definitions that follow the template. I see what you mean here. I assume this also is fixed when the TBD is done in a next update. >>> 3.8 Pool Element Parameter >>> >>> This parameter is used in multiple ENRP messages to represent an >>> ASAP >>> endpoint (i.e., a PE in a pool) and the associated information, >>> such >>> as its transport address(es), selection policy, and other >>> operational >>> or status information of the PE. >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type = 0x8 | Length=variable | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PE Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Home ENRP Server Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Registration Life | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #1 : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #2 : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : : >>> : ..... : >>> : : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : User Transport param #k : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : Member Selection Policy param : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Member Selection Policy: >> >> I would suggest to move this parameter before the User Transport, >> since there is not a specific count of 'User Transport' parameters. >> OK, you can calculate it from the length of the complete parameter, >> but I beleive it eases implementation. > > This is being change in v07. Please re-read it and see if it's better. You mean the ASAP draft version 07?? Or common parameters draft version 04?? >> >> 3) How can one make new error causes and/or enterprise specific ones. >> Maybe it is better to define this and forsee already how new error >> causes can be added and how compatibility of implementations that do >> not know >> those new error codes must be handled. > > We hope to get feedback from implementors on this. In the future, if a > new error cause is identified after the RFC is final, a separate draft > can be used to add new error causes. Maybe it could be an idea to make these error IANA maintained. That way only once they need to be published as RFC (original one) and updated do not need that. I understood that this way the way the IESG also handles similar things for SNMP textual conventions. > >> An idea is adding an Unrecognized Error to which it than can be >> mapped. > > Please explain more on this. Not needed, while thinking of it again it is not a good idea anyway. Section 3.10, 3.10.1 and 3.10.2 explains error parameter and if an error code is not understood by the other side, it could be treated as an 'Invalid Value' and no new Cause code is needed. Meaning the 'Unrecognized Error'-code I thought of is simply an 'Invalid value' of the Error Parameter. >> >>> >>> 4. Common Message Formats >>> >>> 10 reserved. >>> >>> 11 reserved. >> >> Although reserved, but what is suggested for to do when these values >> are received?? Handle it as '00'? > > If a reserved value is used, it could be treated as a protocol error. 'It could' makes me believe there is a potential for non-interoperability. I believe this better needs to be defined. Harrie _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 15 16:59:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11664 for ; Tue, 15 Apr 2003 16:59:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FL7G804920; Tue, 15 Apr 2003 17:07:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EB6828311 for ; Tue, 8 Apr 2003 10:11:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11111; Tue, 8 Apr 2003 10:05:51 -0400 (EDT) Message-Id: <200304081405.KAA11111@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rserpool@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:05:51 -0400 Subject: [Rserpool] I-D ACTION:draft-xie-rserpool-redundancy-model-00.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RSERPOOL Redundancy-model Policy Author(s) : Q. Xie, L. Yarroll Filename : draft-xie-rserpool-redundancy-model-00.txt Pages : 10 Date : 2003-4-7 This document defines RSERPOOL Redundancy-model Member Selection Policy parameter and the related procedures. This policy is designed to be flexible and capable of supporting a wide range of advanced redundancy models found in some high availability systems. The design uses the extensibility in RSERPOOL pool load sharing policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xie-rserpool-redundancy-model-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-xie-rserpool-redundancy-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-xie-rserpool-redundancy-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7135943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-xie-rserpool-redundancy-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-xie-rserpool-redundancy-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7135943.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 15 17:00:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11717 for ; Tue, 15 Apr 2003 17:00:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FL8XZ05511 for rserpool-archive@odin.ietf.org; Tue, 15 Apr 2003 17:08:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FL7G804920; Tue, 15 Apr 2003 17:07:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EB6828311 for ; Tue, 8 Apr 2003 10:11:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11111; Tue, 8 Apr 2003 10:05:51 -0400 (EDT) Message-Id: <200304081405.KAA11111@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rserpool@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:05:51 -0400 Subject: [Rserpool] I-D ACTION:draft-xie-rserpool-redundancy-model-00.txt Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RSERPOOL Redundancy-model Policy Author(s) : Q. Xie, L. Yarroll Filename : draft-xie-rserpool-redundancy-model-00.txt Pages : 10 Date : 2003-4-7 This document defines RSERPOOL Redundancy-model Member Selection Policy parameter and the related procedures. This policy is designed to be flexible and capable of supporting a wide range of advanced redundancy models found in some high availability systems. The design uses the extensibility in RSERPOOL pool load sharing policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xie-rserpool-redundancy-model-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-xie-rserpool-redundancy-model-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-xie-rserpool-redundancy-model-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7135943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-xie-rserpool-redundancy-model-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-xie-rserpool-redundancy-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7135943.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Tue Apr 15 17:44:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13006 for ; Tue, 15 Apr 2003 17:44:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FLr4808665; Tue, 15 Apr 2003 17:53:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FLqc808632 for ; Tue, 15 Apr 2003 17:52:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12975 for ; Tue, 15 Apr 2003 17:43:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195YFw-0004vL-00 for rserpool@ietf.org; Tue, 15 Apr 2003 17:46:20 -0400 Received: from [144.189.100.106] (helo=motgate6.mot.com) by ietf-mx with esmtp (Exim 4.12) id 195YFv-0004vH-00 for rserpool@ietf.org; Tue, 15 Apr 2003 17:46:19 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3FLkR8T024356 for ; Tue, 15 Apr 2003 14:46:27 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3FLkPXL015379 for ; Tue, 15 Apr 2003 16:46:25 -0500 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANSFBF; Tue, 15 Apr 2003 16:45:35 -0500 Message-ID: <3E9C7357.BF5F2B74@motorola.com> Date: Tue, 15 Apr 2003 16:02:15 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: WG IETF rserpool Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt References: <73C5FC0C-6F15-11D7-BC08-0003934A5A7E@jumpy.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: ... > >> How can enterprise specifc extensions be done?? > >> Is there a potential future need for this?? > > > > The company or organization will simply need to go through IETF and > > IANA and register its extensions. This is the standard way to do this in > > IETF. > > Then I suggest adding this. If I now want to make some extension > I would not know this. ok. I can add a sentence for this. ... > >> Just to be sure, but are IPv4 and IPv6 addresses allowed to be > >> mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? > > > > yes. they are allowed to be mixed in SCTP > > Maybe wise to add this. ok > > >>> Note, the value in Length field will NOT cover any padding at the > >>> end of the parameter, if there is one. > >> > >> 'one' -> 'padding' (clarity) > > > > Still feel 'one' reads better. > > Then I believe it should be any, since padding can consist of > multiple bytes. Maybe on time padding. I guess this is a border > case and I am not a linguistic. Otherwise, leaves as is. > ok. > >> > >>> described in detail in the following subsections. The enforcement > >>> rules and handling procedures of these policies are defined in > >>> Section xxxxx in ASAP [4]. > >> > >> If those policy types are ASAP specific, maybe the types should be > >> described in that document, since they are not common to ENRP and ASAP. > > > > No. Both ENRP and ASAP need to use them. Normally ASAP sends them and > > ENRP receives them. > > This confuses me, 'ASAP sends them and ENRP receives them'. > You are not meaning here that an ASAP protocol engine speaks > directly with an ENRP protocol engine. > At least your comment makes this unclear. But if they are > used in both protocols they should be in this document. My fault. I meant to say "PU/PE and ENRP server". You are correct, they are ASAP specific parameters. But as you have suggested to remove "common" from the title of this draft, I think it should be fine to keep those defs here. ... > > This is being change in v07. Please re-read it and see if it's better. > > You mean the ASAP draft version 07?? Or common parameters draft version > 04?? Both. Yes, I am working on updating both asap and parameter I-Ds to a new version. I should be more clearer. > >> 3) How can one make new error causes and/or enterprise specific ones. > >> Maybe it is better to define this and forsee already how new error > >> causes can be added and how compatibility of implementations that do > >> not know those new error codes must be handled. > > > > We hope to get feedback from implementors on this. In the future, if a > > new error cause is identified after the RFC is final, a separate draft > > can be used to add new error causes. > > Maybe it could be an idea to make these error IANA maintained. > That way only once they need to be published as RFC (original one) > and updated do not need that. I understood that this way the way the > IESG also handles similar things for SNMP textual conventions. This could be a way to go. But for the sake of readability, I'd keep them in the draft at least for now. Whether or not to hand them over to IANA can be discussed later. > >>> 4. Common Message Formats > >>> > >>> 10 reserved. > >>> > >>> 11 reserved. > >> > >> Although reserved, but what is suggested for to do when these values > >> are received?? Handle it as '00'? > > > > If a reserved value is used, it could be treated as a protocol error. > > 'It could' makes me believe there is a potential for > non-interoperability. I believe this better needs to be defined. Since these 2 bits are part of the msg type field, reserving these 2 bit patterns means that all 10xx-xxxx and 11xx-xxxx ranges are reserved by IETF. Using IETF reserved values IMO is certainly a protocol violation. -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Tue Apr 15 17:45:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13025 for ; Tue, 15 Apr 2003 17:45:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FLrh208707 for rserpool-archive@odin.ietf.org; Tue, 15 Apr 2003 17:53:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FLr4808665; Tue, 15 Apr 2003 17:53:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FLqc808632 for ; Tue, 15 Apr 2003 17:52:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12975 for ; Tue, 15 Apr 2003 17:43:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195YFw-0004vL-00 for rserpool@ietf.org; Tue, 15 Apr 2003 17:46:20 -0400 Received: from [144.189.100.106] (helo=motgate6.mot.com) by ietf-mx with esmtp (Exim 4.12) id 195YFv-0004vH-00 for rserpool@ietf.org; Tue, 15 Apr 2003 17:46:19 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3FLkR8T024356 for ; Tue, 15 Apr 2003 14:46:27 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3FLkPXL015379 for ; Tue, 15 Apr 2003 16:46:25 -0500 Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 2DANSFBF; Tue, 15 Apr 2003 16:45:35 -0500 Message-ID: <3E9C7357.BF5F2B74@motorola.com> Date: Tue, 15 Apr 2003 16:02:15 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harrie Hazewinkel CC: WG IETF rserpool Subject: Re: [Rserpool] draft-ietf-rserpool-common-param-03.txt References: <73C5FC0C-6F15-11D7-BC08-0003934A5A7E@jumpy.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: ... > >> How can enterprise specifc extensions be done?? > >> Is there a potential future need for this?? > > > > The company or organization will simply need to go through IETF and > > IANA and register its extensions. This is the standard way to do this in > > IETF. > > Then I suggest adding this. If I now want to make some extension > I would not know this. ok. I can add a sentence for this. ... > >> Just to be sure, but are IPv4 and IPv6 addresses allowed to be > >> mixed?? Or is it only IPv4 addresses or only IPv6 addresses?? > > > > yes. they are allowed to be mixed in SCTP > > Maybe wise to add this. ok > > >>> Note, the value in Length field will NOT cover any padding at the > >>> end of the parameter, if there is one. > >> > >> 'one' -> 'padding' (clarity) > > > > Still feel 'one' reads better. > > Then I believe it should be any, since padding can consist of > multiple bytes. Maybe on time padding. I guess this is a border > case and I am not a linguistic. Otherwise, leaves as is. > ok. > >> > >>> described in detail in the following subsections. The enforcement > >>> rules and handling procedures of these policies are defined in > >>> Section xxxxx in ASAP [4]. > >> > >> If those policy types are ASAP specific, maybe the types should be > >> described in that document, since they are not common to ENRP and ASAP. > > > > No. Both ENRP and ASAP need to use them. Normally ASAP sends them and > > ENRP receives them. > > This confuses me, 'ASAP sends them and ENRP receives them'. > You are not meaning here that an ASAP protocol engine speaks > directly with an ENRP protocol engine. > At least your comment makes this unclear. But if they are > used in both protocols they should be in this document. My fault. I meant to say "PU/PE and ENRP server". You are correct, they are ASAP specific parameters. But as you have suggested to remove "common" from the title of this draft, I think it should be fine to keep those defs here. ... > > This is being change in v07. Please re-read it and see if it's better. > > You mean the ASAP draft version 07?? Or common parameters draft version > 04?? Both. Yes, I am working on updating both asap and parameter I-Ds to a new version. I should be more clearer. > >> 3) How can one make new error causes and/or enterprise specific ones. > >> Maybe it is better to define this and forsee already how new error > >> causes can be added and how compatibility of implementations that do > >> not know those new error codes must be handled. > > > > We hope to get feedback from implementors on this. In the future, if a > > new error cause is identified after the RFC is final, a separate draft > > can be used to add new error causes. > > Maybe it could be an idea to make these error IANA maintained. > That way only once they need to be published as RFC (original one) > and updated do not need that. I understood that this way the way the > IESG also handles similar things for SNMP textual conventions. This could be a way to go. But for the sake of readability, I'd keep them in the draft at least for now. Whether or not to hand them over to IANA can be discussed later. > >>> 4. Common Message Formats > >>> > >>> 10 reserved. > >>> > >>> 11 reserved. > >> > >> Although reserved, but what is suggested for to do when these values > >> are received?? Handle it as '00'? > > > > If a reserved value is used, it could be treated as a protocol error. > > 'It could' makes me believe there is a potential for > non-interoperability. I believe this better needs to be defined. Since these 2 bits are part of the msg type field, reserving these 2 bit patterns means that all 10xx-xxxx and 11xx-xxxx ranges are reserved by IETF. Using IETF reserved values IMO is certainly a protocol violation. -Qiaobing _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Wed Apr 16 14:49:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11635 for ; Wed, 16 Apr 2003 14:49:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIwE813393; Wed, 16 Apr 2003 14:58:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIva813332 for ; Wed, 16 Apr 2003 14:57:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11615 for ; Wed, 16 Apr 2003 14:48:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195rzf-00038I-00 for rserpool@ietf.org; Wed, 16 Apr 2003 14:50:51 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 195rze-00038F-00 for rserpool@ietf.org; Wed, 16 Apr 2003 14:50:50 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h3GIojbY090737; Wed, 16 Apr 2003 13:50:56 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E9DA605.4010209@stewart.chicago.il.us> Date: Wed, 16 Apr 2003 13:50:45 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Phillip Conrad , Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages inbasic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> <3E8E1553.37B8F67@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think I have read most of this thread.. this seems to be the last one.. soo some comments :> Qiaobing Xie wrote: > Phill, > > Phillip Conrad wrote: > >>At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: >> >>>>>This means, if my PU uses SCTP in basic mode, my PU is disallowed to use >>>>>data retrieval provided by SCTP? Why should I be restricted like this? >>>>>You can only convince my if you can show me that either doing so is >>>>>harmful or it is useless for all applications. >>>> >>>>I'm not sure I follow your scenario... the PU is not "disallowed" from >>>>using SCTP retrieval... it's just not "automatically" done on behalf of >>>>the PU by the rserpool framework / ASAP; the PU is certainly able to >>>>retrieve and re-send "manually" if it wishes upon SF. >>> >>>Then I guess I misunderstood Phill. The words "allow" and "restrict" are >>>strong words in a protocol spec :-) So, it is ok that I can build an >>>SCTP-based app that chooses not to use a ctl-channel, but flag the stack >>>to perform best-effort MF during fault recovery? If so, I am happy and I >>>don't mind what you call this mode. I just don't want to see an impl >>>that forces me to turn on the ctl-channel whenever I try to flag for >>>performing best-effort MF. I'd think the implementation should give the >>>ULP two separate controls (e.g., via ioctl calls) - one for MF and one >>>for ctl-channel. >> >>I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? > > > This would work for me. Strictly speaking, this has more to do with the > implementation strategy. I am fine with this, as long as we don't let > people have the wrong impression that "to do MF one must have a > ctl-channel." > I never had the impression that anyone was saying that.. and keeping things as SIMPLE as possible is ALWAYS a good idea IMO :> > >>(Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). > > > This is a little bit unclear. For example, when a PE decides to send a > B-card with a wish list, where should the PE get that list? I guess it > has to be passed down by the app, right? No, the PE is going to get the list itself from its ENRP server. It gets a list of those registered with its same Pool Handle and then does a bashing of the list to figure out what order it wishes to send these to the PU it is talking to. The app may provide guidance in the form of we are doing a rondevaue or we are doing a dispersal .. with that information the PE must figure out what to put in the BC .. Another example, when a PE > wants to send a Cookie, it can only do so under the instruction of the > ULP and must get the app state info from the ULP. This is definetly true. aka it must come from the app So I think the app > must know the existence of the ctl-channel and the app must determine > whether to use a ctl-channel at the initiation of the session. I don't think the above is true.... One can easily design the app to do xxx = send_asap_cookie(state-cookie, pe); if( xxx == -1) { /* no control channel this guy will * have problems failing over */ ....; } This way you find out when you attempt to do the actual cookie population and maybe take corrective action. Now on this same subject, I would doubt the above would happen.. after all if I am writting a PE I would think I would be aware of the services I am offering my client PU and also what contract I make with him.. i.e. you must connection to me on a control/data channel over SCTP.. etc. A good app would have the above ...; to catch a error.. say sending an alarm or logging a issue.. but in general that code should join the vast majority of good code... hardly being executed since it is in the error path :> > >>Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? > > > Again, I am ok with this. I consider this a reasonable impl strategy. > > >>So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". > > > Ok. I think this is just about terminology. In my example, I would then: > 1) be using a rserpool impl that supports ctl-channel, 2) have turned on > MF and therefore in the enhanced mode, and 3) not be using the > ctl-channel. > I think this is the right approach.. you keep basic service very very basic.. and everything else is in the enhancned mode... > >>To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). > > > Yeah, it's quite confusing now. Let me try this: > > basic mode - defined as a PU <-> pool session with no control channel; > enhanced mode - defined as a PU <-> pool session with a control channel; > > Note, I don't say PE here because of potential SF. Let's see if we can > agree on this first :-) I would agree with the above :-) R > > regards, > -Qiaobing > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Wed Apr 16 14:50:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11660 for ; Wed, 16 Apr 2003 14:50:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GIwqp13419 for rserpool-archive@odin.ietf.org; Wed, 16 Apr 2003 14:58:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIwE813393; Wed, 16 Apr 2003 14:58:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIva813332 for ; Wed, 16 Apr 2003 14:57:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11615 for ; Wed, 16 Apr 2003 14:48:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195rzf-00038I-00 for rserpool@ietf.org; Wed, 16 Apr 2003 14:50:51 -0400 Received: from [67.38.193.238] (helo=stewart.chicago.il.us) by ietf-mx with esmtp (Exim 4.12) id 195rze-00038F-00 for rserpool@ietf.org; Wed, 16 Apr 2003 14:50:50 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8/8.12.3) with ESMTP id h3GIojbY090737; Wed, 16 Apr 2003 13:50:56 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E9DA605.4010209@stewart.chicago.il.us> Date: Wed, 16 Apr 2003 13:50:45 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Phillip Conrad , Rserpool Subject: Re: [Rserpool] Another data channel issue: failover of messages inbasic mode? References: <5.1.0.14.2.20030401164828.0238ad38@joda.cis.temple.edu> <3E8B7B50.BF421814@motorola.com> <3E8BBFD8.7DC572AD@ieee.org> <5.1.0.14.2.20030403221208.0471b418@joda.cis.temple.edu> <3E8E1553.37B8F67@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think I have read most of this thread.. this seems to be the last one.. soo some comments :> Qiaobing Xie wrote: > Phill, > > Phillip Conrad wrote: > >>At 02:43 PM 4/3/2003 -0600, Qiaobing Xie wrote: >> >>>>>This means, if my PU uses SCTP in basic mode, my PU is disallowed to use >>>>>data retrieval provided by SCTP? Why should I be restricted like this? >>>>>You can only convince my if you can show me that either doing so is >>>>>harmful or it is useless for all applications. >>>> >>>>I'm not sure I follow your scenario... the PU is not "disallowed" from >>>>using SCTP retrieval... it's just not "automatically" done on behalf of >>>>the PU by the rserpool framework / ASAP; the PU is certainly able to >>>>retrieve and re-send "manually" if it wishes upon SF. >>> >>>Then I guess I misunderstood Phill. The words "allow" and "restrict" are >>>strong words in a protocol spec :-) So, it is ok that I can build an >>>SCTP-based app that chooses not to use a ctl-channel, but flag the stack >>>to perform best-effort MF during fault recovery? If so, I am happy and I >>>don't mind what you call this mode. I just don't want to see an impl >>>that forces me to turn on the ctl-channel whenever I try to flag for >>>performing best-effort MF. I'd think the implementation should give the >>>ULP two separate controls (e.g., via ioctl calls) - one for MF and one >>>for ctl-channel. >> >>I think that should be possible. What I am saying is that the way you would achieve this goal is to use enhanced mode (because that is the mode that supports MF) but just never "use" the control channel. If a control channel is theoretically present, but no messages ever actually pass over it when your application is running (because your application never "turns on" the extra ASAP services such as business cards that would cause messages to be exchanged over that control channel), is that close enough to "not having a control channel" to satisfy your needs? > > > This would work for me. Strictly speaking, this has more to do with the > implementation strategy. I am fine with this, as long as we don't let > people have the wrong impression that "to do MF one must have a > ctl-channel." > I never had the impression that anyone was saying that.. and keeping things as SIMPLE as possible is ALWAYS a good idea IMO :> > >>(Note that the upper layer never accesses the control channel "directly"; the control channel is used for transmission of ASAP messages, so there is a layer of indirection between the application and the control channel). > > > This is a little bit unclear. For example, when a PE decides to send a > B-card with a wish list, where should the PE get that list? I guess it > has to be passed down by the app, right? No, the PE is going to get the list itself from its ENRP server. It gets a list of those registered with its same Pool Handle and then does a bashing of the list to figure out what order it wishes to send these to the PU it is talking to. The app may provide guidance in the form of we are doing a rondevaue or we are doing a dispersal .. with that information the PE must figure out what to put in the BC .. Another example, when a PE > wants to send a Cookie, it can only do so under the instruction of the > ULP and must get the app state info from the ULP. This is definetly true. aka it must come from the app So I think the app > must know the existence of the ctl-channel and the app must determine > whether to use a ctl-channel at the initiation of the session. I don't think the above is true.... One can easily design the app to do xxx = send_asap_cookie(state-cookie, pe); if( xxx == -1) { /* no control channel this guy will * have problems failing over */ ....; } This way you find out when you attempt to do the actual cookie population and maybe take corrective action. Now on this same subject, I would doubt the above would happen.. after all if I am writting a PE I would think I would be aware of the services I am offering my client PU and also what contract I make with him.. i.e. you must connection to me on a control/data channel over SCTP.. etc. A good app would have the above ...; to catch a error.. say sending an alarm or logging a issue.. but in general that code should join the vast majority of good code... hardly being executed since it is in the error path :> > >>Keep in mind that since we have already decided that we are NOT defining any "subsets" of RSerPool, it wont be the case that a given ASAP implementation "can't understand" a control channel. It just might be that for some particular application, you don't want the extra bits on the wire that a control channel would impose, or the processing overhead of dealing with a control channel. That's understandable. Having a "totally quiet" control channel should be enough to meet that goal, right? > > > Again, I am ok with this. I consider this a reasonable impl strategy. > > >>So what I am suggesting is that you want MF, you should use enhanced mode, because that's the mode that supports the data sending primitives that are needed to get MF. It also happens to be a mode _supports_ a control channel... but if you don't ask for any services (such as business cards, etc) that require a control channel, then nothing will actually ever "go" over the control channel, and that is no different from the control channel "not being there". > > > Ok. I think this is just about terminology. In my example, I would then: > 1) be using a rserpool impl that supports ctl-channel, 2) have turned on > MF and therefore in the enhanced mode, and 3) not be using the > ctl-channel. > I think this is the right approach.. you keep basic service very very basic.. and everything else is in the enhancned mode... > >>To emphasize this point, we can perhaps, when we get around to defining APIs, do so in such a way that the default in enhanced mode is that all the things that require a control channel are by default OFF. That way, enhanced mode by default provides SF and MF, and nothing else, so that the control channel is by default, "quiet" (practically non-existent). (At least, I think we can do this... things have been changing so fast, that I will need to re-read everything again before I can be 100% sure of this. :-) ). > > > Yeah, it's quite confusing now. Let me try this: > > basic mode - defined as a PU <-> pool session with no control channel; > enhanced mode - defined as a PU <-> pool session with a control channel; > > Note, I don't say PE here because of potential SF. Let's see if we can > agree on this first :-) I would agree with the above :-) R > > regards, > -Qiaobing > _______________________________________________ > rserpool mailing list > rserpool@ietf.org > https://www1.ietf.org/mailman/listinfo/rserpool > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From rserpool-admin@ietf.org Mon Apr 28 10:40:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03309 for ; Mon, 28 Apr 2003 10:40:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEiO815834; Mon, 28 Apr 2003 10:44:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEhn815786 for ; Mon, 28 Apr 2003 10:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03272 for ; Mon, 28 Apr 2003 10:38:42 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9oK-0003I1-00 for rserpool@ietf.org; Mon, 28 Apr 2003 10:40:52 -0400 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by ietf-mx with esmtp (Exim 4.12) id 19A9nz-0003Hq-00 for rserpool@ietf.org; Mon, 28 Apr 2003 10:40:31 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SEeYb21749 for ; Mon, 28 Apr 2003 09:40:34 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 28 Apr 2003 09:40:29 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Apr 2003 07:39:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Apr 2003 09:39:29 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680F7@daebe007.americas.nokia.com> Thread-Topic: Question on ports for ENRP name server Thread-Index: AcMLc2PLWLOWz71rT3mH0LSEablH9ACFqosw To: X-OriginalArrivalTime: 28 Apr 2003 14:39:30.0271 (UTC) FILETIME=[FA0856F0:01C30D93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SEhn815787 Subject: [Rserpool] Minutes from last security design team conference call -- next teleconference Tuesday May 6 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next conference call will be held on Tuesday, May 6 at 10AM EDT USA. Minutes of the security design team conference call on April 15 Attending the conference call: Randy Stewart Maureen Stillman Aron Silverton Michael Tuexen Qiaobing Xie 1) I sent an e-mail to our area directors regarding the issue of one port versus two for secure versus insecure communication. Jon Peterson answered below. 2) We continued our discussion of the security of individual entries in the ENRP namespace. This issue was raised on the mailing list after our last teleconference. We decided to get the opinion of Eric Rescorla. The e-mail message to him is attached below. I will post the response when I receive it. 3) Next teleconference is Tuesday, May 6 at 10AM EDT USA. -- maureen Attachment #1 -----Original Message----- From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, April 25, 2003 5:42 PM To: Stillman Maureen (NVO-NIC/Ithaca); mankin@psg.com Cc: lyong@ciena.com Subject: RE: Question on ports for ENRP name server If there is any real policy, it's specified in RFC2817, which recommends a single-port approach. Some problems with a two-port approach are also described in RFC2595 (section 7). I have, however, detected widespread skepticism about one-port protocols that use upward negotiation (like HTTP UPGRADE) from insecure to secure connections; while the spirit of RFC2817 is good, the mechanism itself is largely broken. So, as far as I know there's no consensus that either the one port or two port approach is superior. Our Transport Area security advisor tells us that either way is okay (or at least either way is equally fraught with pitfalls). - J > -----Original Message----- > From: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com] > Sent: Friday, April 25, 2003 10:38 AM > To: mankin@psg.com; jon.peterson@neustar.biz > Cc: lyong@ciena.com > Subject: Question on ports for ENRP name server > > > The Reserpool security design team has been meeting and > recently we have a question about ports. > > We are strongly in favor of using TLS for security in > Reserpool to protect the integrity of the namespace. TLS > would be mandatory to implement but optional to use. The > question concerns using one port or two ports for insecure > vs. secure communication with the ENRP server for > registration by a Pool element. One port for insecure > registrations from pool elements offering a services and the > second port for secure registrations using TLS. The group > would like to have 2 ports as this would make implementation > easier. Is there any problem with this? What is the current > policy on 2 ports versus one port? > > Thanks. > > -- maureen > Attachment #2 to Eric Rescorla: We have another question about Rserpool security. ENRP server = name server PE = pool element (server where the service resides) PU = pool user PEs register with the ENRP server using a pool handle (name) to indicate that they support a service or a set of services The security design team reached consensus on using TLS from the PE to the ENRP server and between ENRP servers to guarantee the following properties: 1) the integrity of the nameserver information sent from the ENRP server to the client 2) the integrity of the registration information sent from the PE to the ENRP server 3) ensuring that a PE registers with a legitimate (non-rogue) ENRP server The open issue that this raised is: What about ENRP servers that have both: PE registrations using TLS and PE registrations not using TLS? There were two options discussed: 1) PE registration entries that had used TLS would be flagged as such. The ENRP server would pass along a list to the PU with some entries marked as "secured" and others marked as not. 2) An ENRP server that supports security would only accept PE input that used TLS. All other registrations would be rejected. Then, when the PU requests a list, it would have only secured entries. The reason to support #1 is that it lets the PU decide what entries to trust. The reason to support #2 is simplicity and support for a consistent security policy. Don't want to fragment the namespace. The question concerns whether to allow for a "split" namespace in which some of the pool entries are "secured" and some are not. Do you have an opinion on this? _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool From mailnull@www1.ietf.org Mon Apr 28 10:40:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03326 for ; Mon, 28 Apr 2003 10:40:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SEjC615867 for rserpool-archive@odin.ietf.org; Mon, 28 Apr 2003 10:45:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEiO815834; Mon, 28 Apr 2003 10:44:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEhn815786 for ; Mon, 28 Apr 2003 10:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03272 for ; Mon, 28 Apr 2003 10:38:42 -0400 (EDT) From: Maureen.Stillman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9oK-0003I1-00 for rserpool@ietf.org; Mon, 28 Apr 2003 10:40:52 -0400 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by ietf-mx with esmtp (Exim 4.12) id 19A9nz-0003Hq-00 for rserpool@ietf.org; Mon, 28 Apr 2003 10:40:31 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SEeYb21749 for ; Mon, 28 Apr 2003 09:40:34 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 28 Apr 2003 09:40:29 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 28 Apr 2003 07:39:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Apr 2003 09:39:29 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811E680F7@daebe007.americas.nokia.com> Thread-Topic: Question on ports for ENRP name server Thread-Index: AcMLc2PLWLOWz71rT3mH0LSEablH9ACFqosw To: X-OriginalArrivalTime: 28 Apr 2003 14:39:30.0271 (UTC) FILETIME=[FA0856F0:01C30D93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SEhn815787 Subject: [Rserpool] Minutes from last security design team conference call -- next teleconference Tuesday May 6 Sender: rserpool-admin@ietf.org Errors-To: rserpool-admin@ietf.org X-BeenThere: rserpool@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Server Pooling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The next conference call will be held on Tuesday, May 6 at 10AM EDT USA. Minutes of the security design team conference call on April 15 Attending the conference call: Randy Stewart Maureen Stillman Aron Silverton Michael Tuexen Qiaobing Xie 1) I sent an e-mail to our area directors regarding the issue of one port versus two for secure versus insecure communication. Jon Peterson answered below. 2) We continued our discussion of the security of individual entries in the ENRP namespace. This issue was raised on the mailing list after our last teleconference. We decided to get the opinion of Eric Rescorla. The e-mail message to him is attached below. I will post the response when I receive it. 3) Next teleconference is Tuesday, May 6 at 10AM EDT USA. -- maureen Attachment #1 -----Original Message----- From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, April 25, 2003 5:42 PM To: Stillman Maureen (NVO-NIC/Ithaca); mankin@psg.com Cc: lyong@ciena.com Subject: RE: Question on ports for ENRP name server If there is any real policy, it's specified in RFC2817, which recommends a single-port approach. Some problems with a two-port approach are also described in RFC2595 (section 7). I have, however, detected widespread skepticism about one-port protocols that use upward negotiation (like HTTP UPGRADE) from insecure to secure connections; while the spirit of RFC2817 is good, the mechanism itself is largely broken. So, as far as I know there's no consensus that either the one port or two port approach is superior. Our Transport Area security advisor tells us that either way is okay (or at least either way is equally fraught with pitfalls). - J > -----Original Message----- > From: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com] > Sent: Friday, April 25, 2003 10:38 AM > To: mankin@psg.com; jon.peterson@neustar.biz > Cc: lyong@ciena.com > Subject: Question on ports for ENRP name server > > > The Reserpool security design team has been meeting and > recently we have a question about ports. > > We are strongly in favor of using TLS for security in > Reserpool to protect the integrity of the namespace. TLS > would be mandatory to implement but optional to use. The > question concerns using one port or two ports for insecure > vs. secure communication with the ENRP server for > registration by a Pool element. One port for insecure > registrations from pool elements offering a services and the > second port for secure registrations using TLS. The group > would like to have 2 ports as this would make implementation > easier. Is there any problem with this? What is the current > policy on 2 ports versus one port? > > Thanks. > > -- maureen > Attachment #2 to Eric Rescorla: We have another question about Rserpool security. ENRP server = name server PE = pool element (server where the service resides) PU = pool user PEs register with the ENRP server using a pool handle (name) to indicate that they support a service or a set of services The security design team reached consensus on using TLS from the PE to the ENRP server and between ENRP servers to guarantee the following properties: 1) the integrity of the nameserver information sent from the ENRP server to the client 2) the integrity of the registration information sent from the PE to the ENRP server 3) ensuring that a PE registers with a legitimate (non-rogue) ENRP server The open issue that this raised is: What about ENRP servers that have both: PE registrations using TLS and PE registrations not using TLS? There were two options discussed: 1) PE registration entries that had used TLS would be flagged as such. The ENRP server would pass along a list to the PU with some entries marked as "secured" and others marked as not. 2) An ENRP server that supports security would only accept PE input that used TLS. All other registrations would be rejected. Then, when the PU requests a list, it would have only secured entries. The reason to support #1 is that it lets the PU decide what entries to trust. The reason to support #2 is simplicity and support for a consistent security policy. Don't want to fragment the namespace. The question concerns whether to allow for a "split" namespace in which some of the pool entries are "secured" and some are not. Do you have an opinion on this? _______________________________________________ rserpool mailing list rserpool@ietf.org https://www1.ietf.org/mailman/listinfo/rserpool