idnits 2.17.1 draft-dreibholz-rserpool-applic-distcomp-05.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 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. 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 (July 11, 2008) is 5739 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: 'RFC2960' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-arch' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rserpool-enrp' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 240, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3257 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. 'I-D.ietf-rserpool-arch') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-20 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. 'I-D.ietf-rserpool-asap') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-20 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. 'I-D.ietf-rserpool-enrp') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-17 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. 'I-D.ietf-rserpool-common-param') == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. 'I-D.ietf-rserpool-policies') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-rserpool-service' ** Obsolete normative reference: RFC 3668 (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 July 11, 2008 5 Expires: January 12, 2009 7 Applicability of Reliable Server Pooling for Real-Time Distributed 8 Computing 9 draft-dreibholz-rserpool-applic-distcomp-05.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 January 12, 2009. 36 Abstract 38 This document describes the applicability of the Reliable Server 39 Pooling architecture to manage real-time distributed computing pools 40 and access the resources of such pools. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Distributed Computing using RSerPool . . . . . . . . . . . . . 3 48 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1.1. Architecture . . . . . . . . . . . . . . . . . . . . . 4 50 2.1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . 5 51 2.1.3. Implementation . . . . . . . . . . . . . . . . . . . . 5 52 3. Security considerations . . . . . . . . . . . . . . . . . . . . 5 53 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Normative References . . . . . . . . . . . . . . . . . . . 6 55 4.2. Informative References . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 Intellectual Property and Copyright Statements . . . . . . . . . . 9 59 1. Introduction 61 Reliable Server Pooling defines protocols for providing highly 62 available services. The services are located in a pool of redundant 63 servers and if a server fails, another server will take over. The 64 only requirement put on these servers belonging to the pool is that 65 if state is maintained by the server, this state must be transferred 66 to the other server taking over. 68 The goal is to provide server-based redundancy. Transport and 69 network level redundancy are handled by the transport and network 70 layer protocols. 72 The application may choose to distribute its traffic over the servers 73 of the pool conforming to a certain policy. 75 1.1. Scope 77 The scope of this document is to explain the way of using Reliable 78 Server Pooling mechanisms to manage and access pools of Distributed 79 Computing resources. 81 1.2. Terminology 83 The terms are commonly identified in related work and can be found in 84 the Aggregate Server Access Protocol and Endpoint Handlespace 85 Redundancy Protocol Common Parameters document ietf-rserpool-common- 86 param [I-D.ietf-rserpool-common-param] 88 2. Distributed Computing using RSerPool 90 2.1. Requirements 92 The application scenario for Distributed Computing is defined as 93 follows: 95 o Clients generate large computation jobs. Jobs have to be 96 processed by servers as soon as possible (real-time), i.e. unlike 97 concepts like SETI@home [SETIatHome], it is not possible to let 98 clients fetch a job, process it later and may be some day upload 99 the result. 101 o Jobs may be partitionable, i.e. they can be split up to smaller 102 pieces which can be processed independently and the processing 103 results can be concatenated to the processing result of the 104 complete job. Jobs have to be processed by servers. 106 o Servers may be unreliable; i.e. user computers may be temporarily 107 added to the pool of computing resources and may be revoked when 108 they are used again by their owners. Furthermore, they may simply 109 disappear because of broken network connections (modems, etc.) or 110 power turned off. 112 o The processing power of servers in a pool of computing resources 113 may be very heterogeneous, i.e. a few supercomputers and many low- 114 end user PCs. 116 o It must be possible to manage large server pools, e.g. up to some 117 hundreds or even thousands of servers. 119 o Due to heterogeneous processing resources within a pool, it must 120 be possible to use appropriate server selection procedures to 121 meaningfully utilize the available resources. 123 o It must be possible to dynamically add and remove servers. 125 o Servers may be unreliable, especially when the servers are 126 represented by user PCs. Failover mechanisms are required to 127 continue an interrupted computation session. 129 2.1.1. Architecture 131 o An efficient implementation of the handlespace management 132 structures allows pools to contain thousands of elements. 133 Handlespace management structures have been proposed, implemented 134 and analyzed in [Contel2005], [Dre2006]. 136 o RSerPool allows to specify server selection rules by pool member 137 selection policies [I-D.ietf-rserpool-policies]. A set of 138 adaptive and non-adaptive policies is already defined. To fulfill 139 the requirements of new applications, it is also possible to 140 define new policies. Research has already been made on the 141 subject of load distribution efficiency of pool policies in 142 Distributed Computing scenarios: see [LCN2005], [Dre2006], 143 [Tencon2005], [Euromicro2007], [ICN2005] for details. 145 o Dynamic addition and removal of PEs is a feature of RSerPool 146 [I-D.ietf-rserpool-asap]. 148 o The control/data channel concept [I-D.ietf-rserpool-service] of 149 RSerPool realizes a session layer. That is, RSerPool already 150 handles the main task of maintaining and monitoring connections 151 between PUs and PEs; the only task of the application layer to 152 provide full failover functionality is to realize an application- 153 dependent failover procedure. By the usage of client-based state 154 synchronization [LCN2002], [Euromicro2005] in the form of ASAP 155 Cookies, a failover may be fully transparent to the PU while only 156 a state restoration is necessary on the PE side. A demo 157 application [RSerPoolPage] using the RSerPool session layer in a 158 Distributed Computing application is described in [Infocom2005]. 160 2.1.2. Limitations 162 Applying RSerPool for distributed computing applications, the duties 163 of the RSerPool architecture are still limited to the management of 164 pools and independent sessions only. It is in particular a non-goal 165 to provide functionalities like data synchronization among sessions, 166 user authentication, accounting or the support for more than one 167 administrative domain. Such functionalities are considered to be 168 application-specific and are therefore out of the scope of RSerPool. 170 2.1.3. Implementation 172 A proof of concept implementation of a Distributed Computing 173 application based on the RSerPool prototype rsplib can be found at 174 [RSerPoolPage]. This system provides a fractal graphics computation 175 service; the failover procedure is handled by ASAP cookies. 177 3. Security considerations 179 The protocols used in the Reliable Server Pooling architecture only 180 try to increase the availability of the servers in the network. 181 RSerPool protocols do not contain any protocol mechanisms which are 182 directly related to user message authentication, integrity and 183 confidentiality functions. For such features, it depends on the 184 IPSEC protocols or on Transport Layer Security (TLS) protocols for 185 its own security and on the architecture and/or security features of 186 its user protocols. 188 The RSerPool architecture allows the use of different transport 189 protocols for its application and control data exchange. These 190 transport protocols may have mechanisms for reducing the risk of 191 blind denial-of-service attacks and/or masquerade attacks. If such 192 measures are required by the applications, then it is advised to 193 check the SCTP applicability statement RFC3257 [RFC3257] for guidance 194 on this issue. 196 4. References 197 4.1. Normative References 199 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 200 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 201 Zhang, L., and V. Paxson, "Stream Control Transmission 202 Protocol", RFC 2960, October 2000. 204 [RFC3257] Coene, L., "Stream Control Transmission Protocol 205 Applicability Statement", RFC 3257, April 2002. 207 [I-D.ietf-rserpool-arch] 208 Tuexen, M., "Architecture for Reliable Server Pooling", 209 draft-ietf-rserpool-arch-12 (work in progress), 210 November 2006. 212 [I-D.ietf-rserpool-asap] 213 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 214 "Aggregate Server Access Protocol (ASAP)", 215 draft-ietf-rserpool-asap-20 (work in progress), May 2008. 217 [I-D.ietf-rserpool-enrp] 218 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 219 Silverton, "Endpoint Handlespace Redundancy Protocol 220 (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), 221 May 2008. 223 [I-D.ietf-rserpool-common-param] 224 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 225 "Aggregate Server Access Protocol (ASAP) and Endpoint 226 Handlespace Redundancy Protocol (ENRP) Parameters", 227 draft-ietf-rserpool-common-param-17 (work in progress), 228 May 2008. 230 [I-D.ietf-rserpool-policies] 231 Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 232 Policies", draft-ietf-rserpool-policies-09 (work in 233 progress), May 2008. 235 [I-D.ietf-rserpool-service] 236 Conrad, P. and P. Lei, "Services Provided By Reliable 237 Server Pooling", draft-ietf-rserpool-service-02 (work in 238 progress), October 2005. 240 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 241 Technology", RFC 3668, February 2004. 243 4.2. Informative References 245 [RSerPoolPage] 246 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", URL: 247 http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 249 [Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 250 Optimization and Extension of a Novel IETF Architecture", 251 Ph.D. Thesis University of Duisburg-Essen, Faculty of 252 Economics, Institute for Computer Science and Business 253 Information Systems, URL: http:// 254 duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/ 255 Derivate-16326/Dre2006-final.pdf, March 2007. 257 [LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of 258 Reliable Server Pooling Systems", Proceedings of the 30th 259 IEEE Local Computer Networks Conference, November 2005. 261 [Tencon2005] 262 Dreibholz, T. and E. Rathgeb, "The Performance of Reliable 263 Server Pooling Systems in Different Server Capacity 264 Scenarios", Proceedings of the IEEE TENCON, November 2005. 266 [LCN2002] Dreibholz, T., "An efficient approach for state sharing in 267 server pools", Proceedings of the 27th IEEE Local Computer 268 Networks Conference, October 2002. 270 [Euromicro2005] 271 Dreibholz, T. and E. Rathgeb, "RSerPool -- Providing 272 Highly Available Services using Unreliable Servers", 273 Proceedings Proceedings of the 31st IEEE EuroMirco 274 Conference on Software Engineering and Advanced 275 Applications, August 2005. 277 [Euromicro2007] 278 Dreibholz, T., Zhou, X., and E. Rathgeb, "A Performance 279 Evaluation of RSerPool Server Selection Policies in 280 Varying Heterogeneous Capacity Scenarios", Proceedings of 281 the 33rd IEEE EuroMirco Conference on Software Engineering 282 and Advanced Applications, August 2007. 284 [ICN2005] Dreibholz, T., Rathgeb, E., and M. Tuexen, "Load 285 Distribution Performance of the Reliable Server Pooling 286 Framework", Proceedings of the 4th IEEE International 287 Conference on Networking, April 2005. 289 [Infocom2005] 290 Dreibholz, T. and E. Rathgeb, "An Application 291 Demonstration of the Reliable Server Pooling Framework", 292 Proceedings of the 24th IEEE Infocom, March 2005. 294 [Contel2005] 295 Dreibholz, T. and E. Rathgeb, "Implementing the Reliable 296 Server Pooling Framework", Proceedings of the 8th IEEE 297 International Conference on Telecommunications, June 2005. 299 [SETIatHome] 300 "SETI@home: Search for Extraterrestrial Intelligence at 301 home", URL: http://setiathome.ssl.berkeley.edu. 303 Author's Address 305 Thomas Dreibholz 306 University of Duisburg-Essen, Institute for Experimental Mathematics 307 Ellernstrasse 29 308 45326 Essen, Nordrhein-Westfalen 309 Germany 311 Phone: +49-201-1837637 312 Fax: +49-201-1837673 313 Email: dreibh@iem.uni-due.de 314 URI: http://www.iem.uni-due.de/~dreibh/ 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2008). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org.