idnits 2.17.1 draft-dreibholz-rserpool-applic-distcomp-03.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, updated by RFC 4748 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 317. 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 IETF Trust 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 (June 5, 2007) is 6170 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: '1' is defined on line 182, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 190, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 196, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 212, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '2') ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '4') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '5') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '6') == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 3668 (ref. '9') (Obsoleted by RFC 3979) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 8 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: Standards Track June 5, 2007 5 Expires: December 7, 2007 7 Applicability of Reliable Server Pooling for Real-Time Distributed 8 Computing 9 draft-dreibholz-rserpool-applic-distcomp-03.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 December 7, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 [6] 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 [20], 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 heterogeneous processing resources within a pool, it must 104 be possible to use appropriate server selection procedures to 105 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 [19], [11]. 120 o RSerPool allows to specify server selection rules by pool member 121 selection policies [7]. 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 [12], [11], [13], [16], [17] for details. 128 o Dynamic addition and removal of PEs is a feature of RSerPool [4]. 130 o The control/data channel concept [8] 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 136 [14], [15] in the form of ASAP Cookies, a failover may be fully 137 transparent to the PU while only a state restoration is necessary 138 on the PE side. A demo application [10] using the RSerPool 139 session layer in a Distributed Computing application is described 140 in [18]. 142 2.1.2. Limitations 144 Applying RSerPool for distributed computing applications, the duties 145 of the RSerPool architecture are still limited to the management of 146 pools and independent sessions only. It is in particular a non-goal 147 to provide functionalities like data synchronization among sessions, 148 user authentication, accounting or the support for more than one 149 administrative domain. Such functionalities are considered to be 150 application-specific and are therefore out of the scope of RSerPool. 152 2.1.3. Implementation 154 A proof of concept implementation of a Distributed Computing 155 application based on the RSerPool prototype rsplib can be found at 156 [10]. This system provides a fractal graphics computation service; 157 the failover procedure is handled by ASAP cookies. 159 3. Security considerations 161 The protocols used in the Reliable Server Pooling architecture only 162 try to increase the availability of the servers in the network. 163 RSerPool protocols do not contain any protocol mechanisms which are 164 directly related to user message authentication, integrity and 165 confidentiality functions. For such features, it depends on the 166 IPSEC protocols or on Transport Layer Security (TLS) protocols for 167 its own security and on the architecture and/or security features of 168 its user protocols. 170 The RSerPool architecture allows the use of different transport 171 protocols for its application and control data exchange. These 172 transport protocols may have mechanisms for reducing the risk of 173 blind denial-of-service attacks and/or masquerade attacks. If such 174 measures are required by the applications, then it is advised to 175 check the SCTP applicability statement RFC3257 [2] for guidance on 176 this issue. 178 4. References 180 4.1. Normative References 182 [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 183 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 184 Paxson, "Stream Control Transmission Protocol", RFC 2960, 185 October 2000. 187 [2] Coene, L., "Stream Control Transmission Protocol Applicability 188 Statement", RFC 3257, April 2002. 190 [3] Tuexen, M., "Architecture for Reliable Server Pooling", 191 draft-ietf-rserpool-arch-12 (work in progress), November 2006. 193 [4] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 194 draft-ietf-rserpool-asap-15 (work in progress), January 2007. 196 [5] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 197 draft-ietf-rserpool-enrp-15 (work in progress), January 2007. 199 [6] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 200 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 201 draft-ietf-rserpool-common-param-11 (work in progress), 202 October 2006. 204 [7] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 205 Policies", draft-ietf-rserpool-policies-04 (work in progress), 206 March 2007. 208 [8] Conrad, P. and P. Lei, "Services Provided By Reliable Server 209 Pooling", draft-ietf-rserpool-service-02 (work in progress), 210 October 2005. 212 [9] Bradner, S., "Intellectual Property Rights in IETF Technology", 213 RFC 3668, February 2004. 215 4.2. Informative References 217 [10] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 218 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 220 [11] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 221 Optimization and Extension of a Novel IETF Architecture", Ph.D. 222 Thesis University of Duisburg-Essen, Faculty of Economics, 223 Institute for Computer Science and Business Information 224 Systems, URL: http://duepublico.uni-duisburg-essen.de/servlets/ 225 DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. 227 [12] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable 228 Server Pooling Systems", Proceedings of the 30th IEEE Local 229 Computer Networks Conference, November 2005. 231 [13] Dreibholz, T. and E. Rathgeb, "The Performance of Reliable 232 Server Pooling Systems in Different Server Capacity Scenarios", 233 Proceedings of the IEEE TENCON, November 2005. 235 [14] Dreibholz, T., "An efficient approach for state sharing in 236 server pools", Proceedings of the 27th IEEE Local Computer 237 Networks Conference, October 2002. 239 [15] Dreibholz, T. and E. Rathgeb, "RSerPool -- Providing Highly 240 Available Services using Unreliable Servers", 241 Proceedings Proceedings of the 31st IEEE EuroMirco Conference 242 on Software Engineering and Advanced Applications, August 2005. 244 [16] Dreibholz, T., Zhou, X., and E. Rathgeb, "A Performance 245 Evaluation of RSerPool Server Selection Policies in Varying 246 Heterogeneous Capacity Scenarios", Proceedings Proceedings of 247 the 33rd IEEE EuroMirco Conference on Software Engineering and 248 Advanced Applications, August 2007. 250 [17] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load Distribution 251 Performance of the Reliable Server Pooling Framework", 252 Proceedings of the 4th IEEE International Conference on 253 Networking, April 2005. 255 [18] Dreibholz, T. and E. Rathgeb, "An Application Demonstration of 256 the Reliable Server Pooling Framework", Proceedings of the 24th 257 IEEE Infocom, March 2005. 259 [19] Dreibholz, T. and E. Rathgeb, "Implementing the Reliable Server 260 Pooling Framework", Proceedings of the 8th IEEE International 261 Conference on Telecommunications, June 2005. 263 [20] "SETI@home: Search for Extraterrestrial Intelligence at home", 264 URL: http://setiathome.ssl.berkeley.edu. 266 Author's Address 268 Thomas Dreibholz 269 University of Duisburg-Essen, Institute for Experimental Mathematics 270 Ellernstrasse 29 271 45326 Essen, Nordrhein-Westfalen 272 Germany 274 Phone: +49-201-1837637 275 Fax: +49-201-1837673 276 Email: dreibh@exp-math.uni-essen.de 277 URI: http://www.exp-math.uni-essen.de/~dreibh/ 279 Full Copyright Statement 281 Copyright (C) The IETF Trust (2007). 283 This document is subject to the rights, licenses and restrictions 284 contained in BCP 78, and except as set forth therein, the authors 285 retain all their rights. 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 290 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 291 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 292 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Intellectual Property 297 The IETF takes no position regarding the validity or scope of any 298 Intellectual Property Rights or other rights that might be claimed to 299 pertain to the implementation or use of the technology described in 300 this document or the extent to which any license under such rights 301 might or might not be available; nor does it represent that it has 302 made any independent effort to identify any such rights. Information 303 on the procedures with respect to rights in RFC documents can be 304 found in BCP 78 and BCP 79. 306 Copies of IPR disclosures made to the IETF Secretariat and any 307 assurances of licenses to be made available, or the result of an 308 attempt made to obtain a general license or permission for the use of 309 such proprietary rights by implementers or users of this 310 specification can be obtained from the IETF on-line IPR repository at 311 http://www.ietf.org/ipr. 313 The IETF invites any interested party to bring to its attention any 314 copyrights, patents or patent applications, or other proprietary 315 rights that may cover technology that may be required to implement 316 this standard. Please address the information to the IETF at 317 ietf-ipr@ietf.org. 319 Acknowledgment 321 Funding for the RFC Editor function is provided by the IETF 322 Administrative Support Activity (IASA).