idnits 2.17.1 draft-dreibholz-rserpool-delay-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 5, 2014) is 3757 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-34) exists of draft-dreibholz-rserpool-asap-hropt-13 == Outdated reference: A later version (-31) exists of draft-dreibholz-rserpool-enrp-takeover-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft Simula Research Laboratory 4 Intended status: Experimental X. Zhou 5 Expires: July 9, 2014 Hainan University 6 January 5, 2014 8 Definition of a Delay Measurement Infrastructure and Delay-Sensitive 9 Least-Used Policy for Reliable Server Pooling 10 draft-dreibholz-rserpool-delay-13.txt 12 Abstract 14 This document contains the definition of a delay measurement 15 infrastructure and a delay-sensitive Least-Used policy for Reliable 16 Server Pooling. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 9, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Delay-Measurement Infrastructure . . . . . . . . . . . . . . 3 57 2.1. Quantification of Distance . . . . . . . . . . . . . . . 3 58 2.2. Distance Measurement Environment . . . . . . . . . . . . 3 59 3. Distance-Sensitive Least-Used Policy . . . . . . . . . . . . 4 60 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. ENRP Server Considerations . . . . . . . . . . . . . . . 4 62 3.3. Pool User Considerations . . . . . . . . . . . . . . . . 4 63 3.4. Pool Member Selection Policy Parameter . . . . . . . . . 5 64 4. Reference Implementation . . . . . . . . . . . . . . . . . . 5 65 5. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Reliable Server Pooling defines protocols for providing highly 76 available services. PEs of a pool may be distributed over a large 77 geographical area, in order to provide redundancy in case of 78 localized disasters. But the current pool policies defined in 79 [RFC5356] do not incorporate the fact of distances (i.e. delay) 80 between PU and PE. This leads to a low performance for delay- 81 sensitive applications. 83 1.1. Scope 85 This draft defines a delay measurement infrastructure for ENRP 86 servers to add delay information into the handlespace. Furthermore, 87 a delay-sensitive Least-Used policy is defined. Performance 88 evaluations can be found in [KiVS2007]. 90 1.2. Terminology 92 The terms are commonly identified in related work and can be found in 93 the Aggregate Server Access Protocol and Endpoint Handlespace 94 Redundancy Protocol Common Parameters document [RFC5354]. 96 1.3. Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Delay-Measurement Infrastructure 103 This section describes the necessary delay measurement infrastructure 104 for the policy later defined in Section 3. It has to be provided as 105 part of the ENRP servers. 107 2.1. Quantification of Distance 109 Measuring delay for SCTP associations is easy: the SCTP protocol 110 [RFC4960] already calculates a smoothed round-trip time (RTT) for the 111 primary path. This RTT only has to be queried via the standard SCTP 112 API as defined in [RFC6458]. By default, the calculated RTT has a 113 small restriction: a SCTP endpoint waits up to 200ms before 114 acknowledging a packet, in order to piggyback the acknowledgement 115 chunk with payload data. In this case, the RTT would include this 116 latency. By using the option SCTP_DELAYED_SACK (see [RFC6458]), the 117 maximum delay before acknowledging a packet can be set to 0ms (i.e. 118 "acknowledge as soon as possible"). After that, the RTT 119 approximately consists of the network latency only. Then, using the 120 RTT, the end-to-end delay between two associated components is 121 approximately 0.5*RTT. 123 In real networks, there may be negligible delay differences: for 124 example, the delay between a PU and PE #1 is 5ms and the latency 125 between the PU and PE #2 is 6ms. From the service user's 126 perspective, such minor delay differences may be ignored and are 127 furthermore unavoidable in Internet scenarios. Therefore, the 128 distance parameter between two components A and B is defined as 129 follows: 131 Distance = DistanceStep * round( (0.5*RTT) / DistanceStep ) 133 That is, the distance parameter is defined as the nearest integer 134 multiple of the constant DistanceStep for the measured delay (i.e. 135 0.5*RTT). 137 2.2. Distance Measurement Environment 139 In order to define a distance-aware policy, it is first necessary to 140 define a basic rule: PEs and PUs choose "nearby" ENRP servers. Since 141 the operation scope of RSerPool is restricted to a single 142 organization, this condition can be met easily by appropriately 143 locating ENRP servers. 145 o A Home ENRP server can measure the delay of the ASAP associations 146 to its PE. As part of its ENRP updates to other ENRP servers, it 147 can report this measured delay together with the PE information. 149 o A non-Home-ENRP server receiving such an update simply adds the 150 delay of the ENRP association with the Home ENRP server to the 151 PE's reported delay. 153 Now, each ENRP server can approximate the distance to every PE in the 154 operation scope using the equation in Section 2.1. 156 Note, that delay changes are propagated to all ENRP servers upon PE 157 re-registrations, i.e. the delay information (and the approximated 158 distance) dynamically adapts to the state of the network. 160 3. Distance-Sensitive Least-Used Policy 162 In this section, a distance-sensitive Least Used policy is defined, 163 based on the delay-measurement infrastructure introduced in 164 Section 2. 166 3.1. Description 168 The Least Used with Distance Penalty Factor (LU-DPF) policy uses load 169 information provided by the pool elements to select the lowest-loaded 170 pool elements within the pool. If there are multiple elements having 171 lowest load, the nearest PE should be chosen. 173 3.2. ENRP Server Considerations 175 The ENRP server SHOULD select at most the requested number of pool 176 elements. Their load values SHOULD be the lowest possible ones 177 within the pool and their distances also SHOULD be lowest. Each 178 element MUST NOT be reported more than once to the pool user. If 179 there is a choice of equal-loaded and equal-distanced pool elements, 180 round robin selection SHOULD be made among these elements. The 181 returned list of pool elements MUST be sorted by load value in 182 ascending order (1st key) and distance in ascending order (2nd key). 184 3.3. Pool User Considerations 186 The pool user should try to use the pool elements returned from the 187 list in the order returned by the ENRP server. A subsequent call for 188 handle resolution may result in the same list. Therefore, it is 189 RECOMMENDED for a pool user to request multiple entries in order to 190 have a sufficient amount of feasible backup entries available. 192 3.4. Pool Member Selection Policy Parameter 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Parameter Type = 0x6 | Length = 0x14 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Policy Type = 0x40000010 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Load | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Load DPF | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Distance | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 o Load: Current load of the pool element. 210 o Load DPF: The LoadDPF setting of the PE. 212 o Distance: The approximated distance in milliseconds. 214 * Between PE and Home ENRP server: The distance SHOULD be set to 215 0. 217 * Between Non-Home ENRP server and Home ENRP server: The delay 218 measured on the ASAP association between Home ENRP server and 219 PE. 221 * Between ENRP server and PU: The sums of the measured delays on 222 the ASAP association and the ENRP association to the Home ENRP 223 server. 225 4. Reference Implementation 227 The RSerPool reference implementation RSPLIB can be found at 228 [RSerPool-Website]. It supports the functionalities defined by 229 [RFC5351], [RFC5352], [RFC5353], [RFC5354] and [RFC5356] as well as 230 the options [I-D.dreibholz-rserpool-asap-hropt], 231 [I-D.dreibholz-rserpool-enrp-takeover] and of course the option 232 defined by this document. An introduction to this implementation is 233 provided in [Dre2006]. 235 5. Testbed Platform 237 A large-scale and realistic Internet testbed platform with support 238 for the multi-homing feature of the underlying SCTP protocol is 239 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 240 some further information can be found on the project website 241 [NorNet-Website]. 243 6. Security Considerations 245 Security considerations for RSerPool systems are described by 246 [RFC5355]. 248 7. IANA Considerations 250 This document does not require additional IANA actions beyond those 251 already identified in the ENRP and ASAP protocol specifications. 253 8. References 255 8.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 261 4960, September 2007. 263 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 264 Overview of Reliable Server Pooling Protocols", RFC 5351, 265 September 2008. 267 [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 268 "Aggregate Server Access Protocol (ASAP)", RFC 5352, 269 September 2008. 271 [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 272 Silverton, "Endpoint Handlespace Redundancy Protocol 273 (ENRP)", RFC 5353, September 2008. 275 [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 276 "Aggregate Server Access Protocol (ASAP) and Endpoint 277 Handlespace Redundancy Protocol (ENRP) Parameters", RFC 278 5354, September 2008. 280 [RFC5355] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 281 Holdrege, "Threats Introduced by Reliable Server Pooling 282 (RSerPool) and Requirements for Security in Response to 283 Threats", RFC 5355, September 2008. 285 [RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling 286 Policies", RFC 5356, September 2008. 288 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 289 Yasevich, "Sockets API Extensions for the Stream Control 290 Transmission Protocol (SCTP)", RFC 6458, December 2011. 292 [I-D.dreibholz-rserpool-asap-hropt] 293 Dreibholz, T., "Handle Resolution Option for ASAP", draft- 294 dreibholz-rserpool-asap-hropt-13 (work in progress), July 295 2013. 297 [I-D.dreibholz-rserpool-enrp-takeover] 298 Dreibholz, T. and X. Zhou, "Takeover Suggestion Flag for 299 the ENRP Handle Update Message", draft-dreibholz-rserpool- 300 enrp-takeover-10 (work in progress), July 2013. 302 8.2. Informative References 304 [Dre2006] Dreibholz, T., "Reliable Server Pooling - Evaluation, 305 Optimization and Extension of a Novel IETF Architecture", 306 March 2007, . 310 [KiVS2007] 311 Dreibholz, T. and E. Rathgeb, "On Improving the 312 Performance of Reliable Server Pooling Systems for 313 Distance-Sensitive Distributed Applications", Proceedings 314 of the 15. ITG/GI Fachtagung Kommunikation in Verteilten 315 Systemen (KiVS), Pages 39-50, ISBN 978-3-540-69962-0, 316 DOI 10.1007/978-3-540-69962-0_4, February 2007, 317 . 320 [PAMS2013-NorNet] 321 Dreibholz, T. and E. Gran, "Design and Implementation of 322 the NorNet Core Research Testbed for Multi-Homed Systems", 323 Proceedings of the 3nd International Workshop on Protocols 324 and Applications with Multi-Homing Support (PAMS), Pages 325 1094-1100, ISBN 978-0-7695-4952-1, DOI 10.1109/ 326 WAINA.2013.71, March 2013, . 330 [RSerPool-Website] 331 Dreibholz, T., "Thomas Dreibholz's RSerPool Page", Online: 332 http://www.iem.uni-due.de/~dreibh/rserpool/, 2013, 333 . 335 [NorNet-Website] 336 Xiang, J., "NorNet -- A Real-World, Large-Scale Multi- 337 Homing Testbed", Online: http://www.nntb.no/, 2013, 338 . 340 Authors' Addresses 342 Thomas Dreibholz 343 Simula Research Laboratory, Network Systems Group 344 Martin Linges vei 17 345 1364 Fornebu, Akershus 346 Norway 348 Phone: +47-6782-8200 349 Fax: +47-6782-8201 350 Email: dreibh@simula.no 351 URI: http://www.iem.uni-due.de/~dreibh/ 353 Xing Zhou 354 Hainan University, College of Information Science and Technology 355 Renmin Avenue 58 356 570228 Haikou, Hainan 357 China 359 Phone: +86-898-66279141 360 Email: zhouxing@hainu.edu.cn