idnits 2.17.1 draft-dreibholz-rserpool-applic-distcomp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 270. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 02, 2006) is 6651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 171, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 175, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 196, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 204, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 212, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 232, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2960 (ref. '8') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '9') == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '10') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '11') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '12') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '13') == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. '14') == Outdated reference: A later version (-02) exists of draft-ietf-rserpool-service-01 -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Obsolete normative reference: RFC 3668 (ref. '17') (Obsoleted by RFC 3979) Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft University of Duisburg-Essen 4 Expires: August 6, 2006 Feb 02, 2006 6 Applicability of Reliable Server Pooling for Real-Time Distributed 7 Computing 8 draft-dreibholz-rserpool-applic-distcomp-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 6, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes the applicability of the Reliable Server 42 Pooling architecture to manage real-time distributed computing pools 43 and access the resources of such pools. 45 1. Introduction 47 Reliable Server Pooling defines protocols for providing highly 48 available services. The services are located in a pool of redundant 49 servers and if a server fails, another server will take over. The 50 only requirement put on these servers belonging to the pool is that 51 if state is maintained by the server, this state must be transferred 52 to the other server taking over. 54 The goal is to provide server-based redundancy. Transport and 55 network level redundancy are handled by the transport and network 56 layer protocols. 58 The application may choose to distribute its traffic over the servers 59 of the pool conforming to a certain policy. 61 1.1 Scope 63 The scope of this document is to explain the way of using Reliable 64 Server Pooling mechanisms to manage and access pools of Distributed 65 Computing resources. 67 1.2 Terminology 69 The terms are commonly identified in related work and can be found in 70 the Aggregate Server Access Protocol and Endpoint Handlespace 71 Redundancy Protocol Common Parameters document ietf-rserpool-common- 72 param [13] 74 2. Distributed Computing using RSerPool 76 2.1 Requirements 78 o Clients generate large computation jobs. Jobs have to be 79 processed by servers as soon as possible (real-time), i.e. unlike 80 concepts like SETI@home [16], it is not possible to let clients 81 fetch a job, process it later and may be some day upload the 82 result. 84 o Jobs may be partitionable, i.e. they can be split up to smaller 85 pieces which can be processed independently and the processing 86 results can be concatenated to the processing result of the 87 complete job. Jobs have to be processed by servers. 89 o Servers may be unreliable; i.e. user computers may be temporarily 90 added to the pool of computing resources and may be revoked when 91 they are used again by their owners. Furthermore, they may simply 92 disappear because of broken network connections (modems, etc.) or 93 power turned off. 95 o The processing power of servers in a pool of computing resources 96 may be very heterogeneous, i.e. a few supercomputers and many low- 97 end user PCs. 99 o It must be possible to manage large server pools, e.g. up to some 100 hundreds or even thousands of servers. 102 o Due to the heterogeneousity of the processing resources within a 103 pool, it must be possible to use appropriate server selection 104 procedures to meaningfully utilize the available resources. 106 o It must be possible to dynamically add and remove servers. 108 o Servers may be unreliable, especially when the servers are 109 represented by user PCs. Failover mechanisms are required to 110 continue an interrupted computation session. 112 2.1.1 Architecture 114 o An efficient implementation of the handlespace management 115 structures allows pools to contain thousands of elements. 116 Handlespace management structures have been proposed, implemented 117 and analyzed in [7]. 119 o RSerPool allows to specify server selection rules by pool member 120 selection policies [14]. A set of adaptive and non-adaptive 121 policies is already defined. To fulfill the requirements of new 122 applications, it is also possible to define new policies. 123 Research has already been made on the subject of load distribution 124 efficiency of pool policies in Distributed Computing scenarios: 125 see [5] for details. 127 o Dynamic addition and removal of PEs is a feature of RSerPool [11]. 129 o The control/data channel concept [15] of RSerPool realizes a 130 session layer. That is, RSerPool already handles the main task of 131 maintaining and monitoring connections between PUs and PEs; the 132 only task of the application layer to provide full failover 133 functionality is to realize an application-dependent failover 134 procedure. By the usage of client-based state synchronization [4] 135 in the form of ASAP Cookies, a failover may be fully transparent 136 to the PU while only a state restoration is necessary on the PE 137 side. A demo application [1] using the RSerPool session layer in 138 a Distributed Computing application is described in [6]. 140 2.1.2 Implementation 142 A proof of concept implementation of a Distributed Computing 143 application based on the RSerPool prototype rsplib can be found at 144 [1]. This system provides a fractal graphics computation service; 145 the failover procedure is handled by ASAP cookies. 147 3. Security considerations 149 The protocols used in the Reliable Server Pooling architecture only 150 try to increase the availability of the servers in the network. 151 RSerPool protocols do not contain any protocol mechanisms which are 152 directly related to user message authentication, integrity and 153 confidentiality functions. For such features, it depends on the 154 IPSEC protocols or on Transport Layer Security (TLS) protocols for 155 its own security and on the architecture and/or security features of 156 its user protocols. 158 The RSerPool architecture allows the use of different transport 159 protocols for its application and control data exchange. These 160 transport protocols may have mechanisms for reducing the risk of 161 blind denial-of-service attacks and/or masquerade attacks. If such 162 measures are required by the applications, then it is advised to 163 check the SCTP applicability statement RFC3257 [9] for guidance on 164 this issue. 166 4. Normative References 168 [1] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 169 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 171 [2] Dreibholz, T. and E. Rathgeb, "The Performance of Reliable 172 Server Pooling Systems in Different Server Capacity Scenarios", 173 Proceedings of the IEEE TENCON, November 2005. 175 [3] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable 176 Server Pooling Systems", Proceedings of the 30th IEEE Local 177 Computer Networks Conference, November 2005. 179 [4] Dreibholz, T., "An efficient approach for state sharing in 180 server pools", Proceedings of the 27th IEEE Local Computer 181 Networks Conference, October 2002. 183 [5] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 184 Performance of the Reliable Server Pooling Framework", 185 Proceedings of the 4th IEEE International Conference on 186 Networking, April 2005. 188 [6] Dreibholz, T. and E. Rathgeb, "An Application Demonstration of 189 the Reliable Server Pooling Framework", Proceedings of the 24th 190 IEEE Infocom, March 2005. 192 [7] Dreibholz, T. and E. Rathgeb, "Implementing of the Reliable 193 Server Pooling Framework", Proceedings of the 8th IEEE 194 International Conference on Telecommunications, June 2005. 196 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 197 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 198 Paxson, "Stream Control Transmission Protocol", RFC 2960, 199 October 2000. 201 [9] Coene, L., "Stream Control Transmission Protocol Applicability 202 Statement", RFC 3257, April 2002. 204 [10] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 205 A. Silverton, "Architecture for Reliable Server Pooling", 206 draft-ietf-rserpool-arch-09 (work in progress), February 2005. 208 [11] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 209 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-11 210 (work in progress), February 2005. 212 [12] Xie, Q., Stewart, R., Stillman, M., and M. Tuexen, "Enpoint 213 Handlespace Redundancy Protocol (ENRP)", 214 draft-ietf-rserpool-enrp-11 (work in progress), February 2005. 216 [13] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 217 Server Access Protocol (ASAP) and Endpoint Name Resolution 218 (ENRP) Parameters", draft-ietf-rserpool-common-param-08 (work 219 in progress), February 2005. 221 [14] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 222 Policies", draft-ietf-rserpool-policies-01 (work in progress), 223 June 2005. 225 [15] Conrad, P. and P. Lei, "Services Provided By Reliable Server 226 Pooling", draft-ietf-rserpool-service-01 (work in progress), 227 June 2004. 229 [16] "SETI@home: Search for Extraterrestrial Intelligence at home", 230 URL: http://setiathome.ssl.berkeley.edu. 232 [17] Bradner, S., "Intellectual Property Rights in IETF Technology", 233 RFC 3668, February 2004. 235 Author's Address 237 Thomas Dreibholz 238 University of Duisburg-Essen, Institute for Experimental Mathematics 239 Ellernstrasse 29 240 45326 Essen, Nordrhein-Westfalen 241 Germany 243 Phone: +49-201-1837637 244 Fax: +49-201-1837673 245 Email: dreibh@exp-math.uni-essen.de 246 URI: http://www.exp-math.uni-essen.de/~dreibh/ 248 Intellectual Property Statement 250 The IETF takes no position regarding the validity or scope of any 251 Intellectual Property Rights or other rights that might be claimed to 252 pertain to the implementation or use of the technology described in 253 this document or the extent to which any license under such rights 254 might or might not be available; nor does it represent that it has 255 made any independent effort to identify any such rights. Information 256 on the procedures with respect to rights in RFC documents can be 257 found in BCP 78 and BCP 79. 259 Copies of IPR disclosures made to the IETF Secretariat and any 260 assurances of licenses to be made available, or the result of an 261 attempt made to obtain a general license or permission for the use of 262 such proprietary rights by implementers or users of this 263 specification can be obtained from the IETF on-line IPR repository at 264 http://www.ietf.org/ipr. 266 The IETF invites any interested party to bring to its attention any 267 copyrights, patents or patent applications, or other proprietary 268 rights that may cover technology that may be required to implement 269 this standard. Please address the information to the IETF at 270 ietf-ipr@ietf.org. 272 Disclaimer of Validity 274 This document and the information contained herein are provided on an 275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 277 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 278 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 279 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 Copyright Statement 284 Copyright (C) The Internet Society (2006). This document is subject 285 to the rights, licenses and restrictions contained in BCP 78, and 286 except as set forth therein, the authors retain all their rights. 288 Acknowledgment 290 Funding for the RFC Editor function is currently provided by the 291 Internet Society.