idnits 2.17.1 draft-dreibholz-rserpool-delay-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 332. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 142: '... The ENRP server SHOULD select at most...' RFC 2119 keyword, line 143: '...heir load values SHOULD be the lowest ...' RFC 2119 keyword, line 144: '...r distances also SHOULD be lowest. Ea...' RFC 2119 keyword, line 145: '... element MUST NOT be reported more t...' RFC 2119 keyword, line 147: '... robin selection SHOULD be made among ...' (3 more instances...) 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 (January 10, 2008) is 5923 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 210, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 213, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 216, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 244, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 262, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 268, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '1') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '2') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '3') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '4') == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. '5') ** Obsolete normative reference: RFC 2960 (ref. '6') (Obsoleted by RFC 4960) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-14 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-sctpsocket (ref. '7') Summary: 9 errors (**), 0 flaws (~~), 15 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: Standards Track X. Zhou 5 Expires: July 13, 2008 Hainan University 6 January 10, 2008 8 Definition of a Delay Measurement Infrastructure and Delay-Sensitive 9 Least-Used Policy for Reliable Server Pooling 10 draft-dreibholz-rserpool-delay-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 13, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document contains the definition of a delay measurement 44 infrastructure and a delay-sensitive Least-Used policy for Reliable 45 Server Pooling. 47 1. Introduction 49 Reliable Server Pooling defines protocols for providing highly 50 available services. PEs of a pool may be distributed over a large 51 geographical area, in order to provide redundancy in case of 52 localized disasters. But the current pool policies defined in [5] do 53 not incorporate the fact of distances (i.e. delay) between PU and PE. 54 This leads to a low performance for delay-sensitive applications. 56 1.1. Scope 58 This draft defines a delay measurement infrastructure for ENRP 59 servers to add delay information into the handlespace. Furthermore, 60 a delay-sensitive Least-Used policy is defined. Performance 61 evaluations can be found in [8]. 63 1.2. Terminology 65 The terms are commonly identified in related work and can be found in 66 the Aggregate Server Access Protocol and Endpoint Handlespace 67 Redundancy Protocol Common Parameters document [4]. 69 2. Delay-Measurement Infrastructure 71 This section describes the necessary delay measurement infrastructure 72 for the policy later defined in Section 3. It has to be provided as 73 part of the ENRP servers. 75 2.1. Quantification of Distance 77 Measuring delay for SCTP associations is easy: the SCTP protocol [6] 78 already calculates a smoothed round-trip time (RTT) for the primary 79 path. This RTT only has to be queried via the standard SCTP API as 80 defined in [7]. By default, the calculated RTT has a small 81 restriction: a SCTP endpoint waits up to 200ms before acknowledging a 82 packet, in order to piggyback the acknowledgement chunk with payload 83 data. In this case, the RTT would include this latency. Using the 84 option SCTP_DELAYED_ACK_TIME (see [7]), the maximum delay before 85 acknowledging a packet can be set to 0ms (i.e. "acknowledge as soon 86 as possible"). After that, the RTT approximately consists of the 87 network latency only. Then, using the RTT, the end-to-end delay 88 between two associated components is approximately 0.5*RTT. 90 In real networks, there may be negligible delay differences: for 91 example, the delay between a PU and PE #1 is 5ms and the latency 92 between the PU and PE #2 is 6ms. From the service user's 93 perspective, such minor delay differences may be ignored and are 94 furthermore unavoidable in Internet scenarios. Therefore, the 95 distance parameter between two components A and B is defined as 96 follows: 98 Distance = DistanceStep * round( (0.5*RTT) / DistanceStep ) 100 That is, the distance parameter is defined as the nearest integer 101 multiple of the constant DistanceStep for the measured delay (i.e. 102 0.5*RTT). 104 2.2. Distance Measurement Environment 106 In order to define a distance-aware policy, it is first necessary to 107 define a basic rule: PEs and PUs choose "nearby" ENRP servers. Since 108 the operation scope of RSerPool is restricted to a single 109 organization, this condition can be met easily by appropriately 110 locating ENRP servers. 112 o A Home ENRP server can measure the delay of the ASAP associations 113 to its PE. As part of its ENRP updates to other ENRP servers, it 114 can report this measured delay together with the PE information. 116 o A non-Home-ENRP server receiving such an update simply adds the 117 delay of the ENRP association with the Home ENRP server to the 118 PE's reported delay. 120 Now, each ENRP server can approximate the distance to every PE in the 121 operation scope using the equation in Section 2.1. 123 Note, that delay changes are propagated to all ENRP servers upon PE 124 re-registrations, i.e. the delay information (and the approximated 125 distance) dynamically adapts to the state of the network. 127 3. Distance-Sensitive Least-Used Policy 129 In this section, a distance-sensitive Least Used policy is defined, 130 based on the delay-measurement infrastructure introduced in 131 Section 2. 133 3.1. Description 135 The Least Used with Distance Penalty Factor (LU-DPF) policy uses load 136 information provided by the pool elements to select the lowest-loaded 137 pool elements within the pool. If there are multiple elements having 138 lowest load, the nearest PE should be chosen. 140 3.2. ENRP Server Considerations 142 The ENRP server SHOULD select at most the requested number of pool 143 elements. Their load values SHOULD be the lowest possible ones 144 within the pool and their distances also SHOULD be lowest. Each 145 element MUST NOT be reported more than once to the pool user. If 146 there is a choice of equal-loaded and equal-distanced pool elements, 147 round robin selection SHOULD be made among these elements. The 148 returned list of pool elements MUST be sorted by load value in 149 ascending order (1st key) and distance in ascending order (2nd key). 151 3.3. Pool User Considerations 153 The pool user should try to use the pool elements returned from the 154 list in the order returned by the ENRP server. A subsequent call for 155 handle resolution may result in the same list. Therefore, it is 156 RECOMMENDED for a pool user to request multiple entries in order to 157 have a sufficient amount of feasible backup entries available. 159 3.4. Pool Member Selection Policy Parameter 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Parameter Type = 0x6 | Length = 0x14 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Policy Type = 0x40000010 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Load | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Load DPF | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Distance | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 o Load: Current load of the pool element. 176 o Load DPF: The LoadDPF setting of the PE. 178 o Distance: The approximated distance in milliseconds. 180 * Between PE and Home ENRP server: The distance SHOULD be set to 181 0. 183 * Between Non-Home ENRP server and Home ENRP server: The delay 184 measured on the ASAP association between Home ENRP server and 185 PE. 187 * Between ENRP server and PU: The sums of the measured delays on 188 the ASAP association and the ENRP association to the Home ENRP 189 server. 191 4. Reference Implementation 193 The reference implementation based on the RSerPool prototype 194 implementation rsplib can be found at [10]. 196 5. Security Considerations 198 This document does not identify security requirements beyond those 199 already documented in the ENRP and ASAP protocol specifications. 201 6. IANA Considerations 203 This document does not require additional IANA actions beyond those 204 already identified in the ENRP and ASAP protocol specifications. 206 7. References 208 7.1. Normative References 210 [1] Tuexen, M., "Architecture for Reliable Server Pooling", 211 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 213 [2] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 214 draft-ietf-rserpool-asap-13 (work in progress), February 2006. 216 [3] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 217 draft-ietf-rserpool-enrp-13 (work in progress), February 2006. 219 [4] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 220 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 221 draft-ietf-rserpool-common-param-10 (work in progress), 222 February 2006. 224 [5] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 225 Policies", draft-ietf-rserpool-policies-02 (work in progress), 226 February 2006. 228 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 229 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 230 Paxson, "Stream Control Transmission Protocol", RFC 2960, 231 October 2000. 233 [7] Stewart, R., "Sockets API Extensions for Stream Control 234 Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-14 235 (work in progress), December 2006. 237 7.2. Informative References 239 [8] Dreibholz, T. and E. Rathgeb, "On Improving the Performance of 240 Reliable Server Pooling Systems for Distance-Sensitive 241 Distributed Applications", Proceedings of the 15. ITG/GI 242 Fachtagung Kommunikation in Verteilten Systemen, February 2007. 244 [9] Dreibholz, T., "Reliable Server Pooling -- Evaluation, 245 Optimization and Extension of a Novel IETF Architecture", Ph.D. 246 Thesis University of Duisburg-Essen, Faculty of Economics, 247 Institute for Computer Science and Business Information 248 Systems, URL: http://duepublico.uni-duisburg-essen.de/servlets/ 249 DerivateServlet/Derivate-16326/Dre2006-final.pdf, March 2007. 251 [10] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 252 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 254 [11] Dreibholz, T. and E. Rathgeb, "On the Performance of Reliable 255 Server Pooling Systems", Proceedings of the 30th IEEE Local 256 Computer Networks Conference, November 2005. 258 [12] Dreibholz, T. and E. Rathgeb, "Implementing the Reliable Server 259 Pooling Framework", Proceedings of the 8th IEEE International 260 Conference on Telecommunications, June 2005. 262 [13] Dreibholz, T., Zhou, X., and E. Rathgeb, "A Performance 263 Evaluation of RSerPool Server Selection Policies in Varying 264 Heterogeneous Capacity Scenarios", Proceedings of the 33rd IEEE 265 EuroMirco Conference on Software Engineering and Advanced 266 Applications, August 2007. 268 [14] Dreibholz, T. and E. Rathgeb, "An Application Demonstration of 269 the Reliable Server Pooling Framework", Proceedings of the 24th 270 IEEE Infocom, March 2005. 272 Authors' Addresses 274 Thomas Dreibholz 275 University of Duisburg-Essen, Institute for Experimental Mathematics 276 Ellernstrasse 29 277 45326 Essen, Nordrhein-Westfalen 278 Germany 280 Phone: +49-201-1837637 281 Fax: +49-201-1837673 282 Email: dreibh@exp-math.uni-essen.de 283 URI: http://www.exp-math.uni-essen.de/~dreibh/ 285 Xing Zhou 286 Hainan University, College of Information Science and Technology 287 Renmin Road 58 288 570228 Haikou, Hainan 289 China 291 Phone: +86-898-66279141 292 Email: xing.zhou@uni-due.de 294 Full Copyright Statement 296 Copyright (C) The IETF Trust (2008). 298 This document is subject to the rights, licenses and restrictions 299 contained in BCP 78, and except as set forth therein, the authors 300 retain all their rights. 302 This document and the information contained herein are provided on an 303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 305 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 306 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 307 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 310 Intellectual Property 312 The IETF takes no position regarding the validity or scope of any 313 Intellectual Property Rights or other rights that might be claimed to 314 pertain to the implementation or use of the technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; nor does it represent that it has 317 made any independent effort to identify any such rights. Information 318 on the procedures with respect to rights in RFC documents can be 319 found in BCP 78 and BCP 79. 321 Copies of IPR disclosures made to the IETF Secretariat and any 322 assurances of licenses to be made available, or the result of an 323 attempt made to obtain a general license or permission for the use of 324 such proprietary rights by implementers or users of this 325 specification can be obtained from the IETF on-line IPR repository at 326 http://www.ietf.org/ipr. 328 The IETF invites any interested party to bring to its attention any 329 copyrights, patents or patent applications, or other proprietary 330 rights that may cover technology that may be required to implement 331 this standard. Please address the information to the IETF at 332 ietf-ipr@ietf.org. 334 Acknowledgment 336 Funding for the RFC Editor function is provided by the IETF 337 Administrative Support Activity (IASA).