idnits 2.17.1 draft-dreibholz-rserpool-applic-distcomp-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. ** 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 issues found here. 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 (August 25, 2006) is 6453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 172, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 176, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 197, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 205, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 211, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 230, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. '8') (Obsoleted by RFC 4960) == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-13 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-13 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-10 == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-02 ** Obsolete normative reference: RFC 3668 (ref. '17') (Obsoleted by RFC 3979) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 7 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 Intended status: Informational August 25, 2006 5 Expires: February 26, 2007 7 Applicability of Reliable Server Pooling for Real-Time Distributed 8 Computing 9 draft-dreibholz-rserpool-applic-distcomp-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes the applicability of the Reliable Server 43 Pooling architecture to manage real-time distributed computing pools 44 and access the resources of such pools. 46 1. Introduction 48 Reliable Server Pooling defines protocols for providing highly 49 available services. The services are located in a pool of redundant 50 servers and if a server fails, another server will take over. The 51 only requirement put on these servers belonging to the pool is that 52 if state is maintained by the server, this state must be transferred 53 to the other server taking over. 55 The goal is to provide server-based redundancy. Transport and 56 network level redundancy are handled by the transport and network 57 layer protocols. 59 The application may choose to distribute its traffic over the servers 60 of the pool conforming to a certain policy. 62 1.1. Scope 64 The scope of this document is to explain the way of using Reliable 65 Server Pooling mechanisms to manage and access pools of Distributed 66 Computing resources. 68 1.2. Terminology 70 The terms are commonly identified in related work and can be found in 71 the Aggregate Server Access Protocol and Endpoint Handlespace 72 Redundancy Protocol Common Parameters document ietf-rserpool-common- 73 param [13] 75 2. Distributed Computing using RSerPool 77 2.1. Requirements 79 o Clients generate large computation jobs. Jobs have to be 80 processed by servers as soon as possible (real-time), i.e. unlike 81 concepts like SETI@home [16], it is not possible to let clients 82 fetch a job, process it later and may be some day upload the 83 result. 85 o Jobs may be partitionable, i.e. they can be split up to smaller 86 pieces which can be processed independently and the processing 87 results can be concatenated to the processing result of the 88 complete job. Jobs have to be processed by servers. 90 o Servers may be unreliable; i.e. user computers may be temporarily 91 added to the pool of computing resources and may be revoked when 92 they are used again by their owners. Furthermore, they may simply 93 disappear because of broken network connections (modems, etc.) or 94 power turned off. 96 o The processing power of servers in a pool of computing resources 97 may be very heterogeneous, i.e. a few supercomputers and many low- 98 end user PCs. 100 o It must be possible to manage large server pools, e.g. up to some 101 hundreds or even thousands of servers. 103 o Due to the heterogeneousity of the processing resources within a 104 pool, it must be possible to use appropriate server selection 105 procedures to meaningfully utilize the available resources. 107 o It must be possible to dynamically add and remove servers. 109 o Servers may be unreliable, especially when the servers are 110 represented by user PCs. Failover mechanisms are required to 111 continue an interrupted computation session. 113 2.1.1. Architecture 115 o An efficient implementation of the handlespace management 116 structures allows pools to contain thousands of elements. 117 Handlespace management structures have been proposed, implemented 118 and analyzed in [7]. 120 o RSerPool allows to specify server selection rules by pool member 121 selection policies [14]. A set of adaptive and non-adaptive 122 policies is already defined. To fulfill the requirements of new 123 applications, it is also possible to define new policies. 124 Research has already been made on the subject of load distribution 125 efficiency of pool policies in Distributed Computing scenarios: 126 see [5] for details. 128 o Dynamic addition and removal of PEs is a feature of RSerPool [11]. 130 o The control/data channel concept [15] of RSerPool realizes a 131 session layer. That is, RSerPool already handles the main task of 132 maintaining and monitoring connections between PUs and PEs; the 133 only task of the application layer to provide full failover 134 functionality is to realize an application-dependent failover 135 procedure. By the usage of client-based state synchronization [4] 136 in the form of ASAP Cookies, a failover may be fully transparent 137 to the PU while only a state restoration is necessary on the PE 138 side. A demo application [1] using the RSerPool session layer in 139 a Distributed Computing application is described in [6]. 141 2.1.2. Implementation 143 A proof of concept implementation of a Distributed Computing 144 application based on the RSerPool prototype rsplib can be found at 145 [1]. This system provides a fractal graphics computation service; 146 the failover procedure is handled by ASAP cookies. 148 3. Security considerations 150 The protocols used in the Reliable Server Pooling architecture only 151 try to increase the availability of the servers in the network. 152 RSerPool protocols do not contain any protocol mechanisms which are 153 directly related to user message authentication, integrity and 154 confidentiality functions. For such features, it depends on the 155 IPSEC protocols or on Transport Layer Security (TLS) protocols for 156 its own security and on the architecture and/or security features of 157 its user protocols. 159 The RSerPool architecture allows the use of different transport 160 protocols for its application and control data exchange. These 161 transport protocols may have mechanisms for reducing the risk of 162 blind denial-of-service attacks and/or masquerade attacks. If such 163 measures are required by the applications, then it is advised to 164 check the SCTP applicability statement RFC3257 [9] for guidance on 165 this issue. 167 4. Normative References 169 [1] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 170 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 172 [2] Dreibholz, T. and E. Rathgeb, "The Performance of Reliable 173 Server Pooling Systems in Different Server Capacity Scenarios", 174 Proceedings of the IEEE TENCON, November 2005. 176 [3] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable 177 Server Pooling Systems", Proceedings of the 30th IEEE Local 178 Computer Networks Conference, November 2005. 180 [4] Dreibholz, T., "An efficient approach for state sharing in 181 server pools", Proceedings of the 27th IEEE Local Computer 182 Networks Conference, October 2002. 184 [5] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 185 Performance of the Reliable Server Pooling Framework", 186 Proceedings of the 4th IEEE International Conference on 187 Networking, April 2005. 189 [6] Dreibholz, T. and E. Rathgeb, "An Application Demonstration of 190 the Reliable Server Pooling Framework", Proceedings of the 24th 191 IEEE Infocom, March 2005. 193 [7] Dreibholz, T. and E. Rathgeb, "Implementing the Reliable Server 194 Pooling Framework", Proceedings of the 8th IEEE International 195 Conference on Telecommunications, June 2005. 197 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 198 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 199 Paxson, "Stream Control Transmission Protocol", RFC 2960, 200 October 2000. 202 [9] Coene, L., "Stream Control Transmission Protocol Applicability 203 Statement", RFC 3257, April 2002. 205 [10] Tuexen, M., "Architecture for Reliable Server Pooling", 206 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 208 [11] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 209 draft-ietf-rserpool-asap-13 (work in progress), February 2006. 211 [12] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 212 draft-ietf-rserpool-enrp-13 (work in progress), February 2006. 214 [13] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 215 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 216 draft-ietf-rserpool-common-param-10 (work in progress), 217 February 2006. 219 [14] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 220 Policies", draft-ietf-rserpool-policies-02 (work in progress), 221 February 2006. 223 [15] Conrad, P. and P. Lei, "Services Provided By Reliable Server 224 Pooling", draft-ietf-rserpool-service-02 (work in progress), 225 October 2005. 227 [16] "SETI@home: Search for Extraterrestrial Intelligence at home", 228 URL: http://setiathome.ssl.berkeley.edu. 230 [17] Bradner, S., "Intellectual Property Rights in IETF Technology", 231 RFC 3668, February 2004. 233 Author's Address 235 Thomas Dreibholz 236 University of Duisburg-Essen, Institute for Experimental Mathematics 237 Ellernstrasse 29 238 45326 Essen, Nordrhein-Westfalen 239 Germany 241 Phone: +49-201-1837637 242 Fax: +49-201-1837673 243 Email: dreibh@exp-math.uni-essen.de 244 URI: http://www.exp-math.uni-essen.de/~dreibh/ 246 Full Copyright Statement 248 Copyright (C) The Internet Society (2006). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org. 286 Acknowledgment 288 Funding for the RFC Editor function is provided by the IETF 289 Administrative Support Activity (IASA).