idnits 2.17.1 draft-grinnemo-taps-he-03.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 date (June 2017) is 2469 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS K-J. Grinnemo 3 Internet-Draft A. Brunstrom 4 Intended status: Experimental P. Hurtig 5 Expires: December 3, 2017 Karlstad University 6 N. Khademi 7 University of Oslo 8 Z. Bozakov 9 Dell EMC Research Europe 10 June 2017 12 Happy Eyeballs for Transport Selection 13 draft-grinnemo-taps-he-03 15 Abstract 17 Ideally, network applications should be able to select an appropriate 18 transport solution from among available transport solutions. 19 However, at present, there is no agreed-upon way to do this. In 20 fact, there is not even an agreed-upon way for a source end host to 21 determine if there is support for a particular transport along a 22 network path. This draft addresses these issues, by proposing a 23 Happy Eyeballs framework. The proposed Happy Eyeballs framework 24 enables the selection of a transport solution that according to 25 application requirements, pre-set policies, and estimated network 26 conditions is the most appropriate one. Additionally, the proposed 27 framework makes it possible for an application to find out whether a 28 particular transport is supported along a network connection towards 29 a specific destination or not. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 3, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 68 4. The Happy Eyeballs Framework . . . . . . . . . . . . . . . . 4 69 5. Design and Implementation Considerations . . . . . . . . . . 5 70 5.1. Candidate List Generation . . . . . . . . . . . . . . . . 5 71 5.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Concurrent Connection Attempts . . . . . . . . . . . . . 7 73 6. Example Happy Eyeballs Scenario . . . . . . . . . . . . . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 10.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Definitions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Introduction 90 Information services on the Internet come in varying forms, such as 91 web browsing, email, and on-demand multimedia. The main motivation 92 behind the design of next-generation computer and communications 93 networks is to provide a universal and easy access to these various 94 types of information services on a single multi-service Internet. 95 This means that all forms of communications, e.g., video, voice, data 96 and control signaling, along with all types of services -- from plain 97 text web pages to multimedia applications -- are bonded in a single- 98 service platform through Internet technology. To enable the next- 99 generation networks, the TAPS Working Group suggests a decoupling 100 between the transport service provided to an application, and the 101 transport stack providing this transport service: An application 102 requests an appropriate transport service on the basis of its 103 transport requirements, and the available transport stack that best 104 meets these requirements is selected. In case the most preferred 105 transport stack is not supported along the network path to the 106 destination, or is not supported by the end host, a less-preferred 107 transport stack is selected instead. As a way to realize the 108 selection of transport stacks, this document suggests a 109 generalization of the Happy Eyeballs (HE) mechanism proposed in Wing 110 et al. [RFC6555] which addresses the selection of complete transport 111 solutions, and which lends itself to arbitrary transport selection 112 criterias. The proposed HE mechanism targets connection-oriented 113 transport solutions, and connectionless transport solutions provided 114 they offer some reasonable way to determine their successful use 115 between endpoints. 117 The HE mechanism was introduced as a means to promote the use of dual 118 network stacks. Dual-stack client applications should be encouraged 119 to try setting up connections over IPv6 first, and fall back to using 120 IPv4 if IPv6 connection attempts fail. However, serializing tests 121 for IPv6 and IPv4 connectivity can result in large connection 122 latencies. HE for IPv6 minimizes the cost in delay by parallelizing 123 attempts over IPv6 and IPv4. HE has also been proposed as an 124 efficient way to find out the optimal combination of IPv4/IPv6 and 125 TCP/SCTP to use to connect to a server 126 [I-D.wing-tsvwg-happy-eyeballs-sctp]. The HE framework suggested in 127 this document could be seen as a natural continuation of this 128 proposal. 130 3. Problem Statement 132 Currently, there is no agreed-upon way for a source end host to 133 select an appropriate transport service for a given application. In 134 fact, there is no common way for a source end-host to find out if a 135 transport stack is supported along a network path between itself and 136 a destination end host. As a consequence, it has become increasingly 137 difficult to introduce new transport stacks, and several 138 applications, including many web applications, run over TCP although 139 there are other transport protocols that better meet the requirements 140 of these applications. 142 4. The Happy Eyeballs Framework 144 +---------------+ 145 | | 146 | Application | 147 | | 148 +-------+-------+ 149 | 150 +-------v-------+ +---------------+ 151 | | | | 152 | TAPS API +-----> | 153 | | | | 154 +---------------+ | Policy | 155 +--| Management | 156 +---------------+ | | | 157 | Transport |<-+ | | 158 | Probing | | | 159 | +-----> | 160 +---------------+ +---------------+ 162 Figure 1: The Happy Eyeballs Framework. 164 The generalized HE mechanism proposed in this draft is carried out 165 within the framework depicted in Figure 1. It comprises the 166 following steps: 168 1. The Policy Management component takes as input application 169 requirements from the TAPS API, stored information about previous 170 connection attempts (e.g., whether previous connection attempts 171 succeeded or not), and network conditions and configurations. On 172 the basis of this input and the policies configured in the 173 system, the Policy Management component creates a list of 174 candidate transport solutions, L, sorted in decreasing priority 175 order. To be compliant with RFC 6555 [RFC6555], the Policy 176 Management component SHOULD, in those cases there are no policies 177 telling otherwise, following the host's address preference, 178 something which usually means giving preference to IPv6 over 179 IPv4. 180 2. It is the responsibility of the Transport Probing component to 181 select the most appropriate transport solution. This is done by 182 initiating connection attempts for each transport solution on L. 183 To minimize the number of connection attempts that are initiated, 184 the Transport Probing component SHOULD cache the outcome of 185 connection attempts in a repository kept by the Policy Management 186 component. The Policy Management component SHOULD in turn only 187 include those transport solutions on L that have not been 188 previously attempted, have valid successful connection-attempt 189 cache entries, or have previously been attempted but whose cached 190 connection-attempt entries have expired. Cached connection- 191 attempt results SHOULD be valid for a configurable amount of time 192 after which they SHOULD expire and have to be repeated. The 193 transport solutions on L are initiated in priority order. The 194 difference in priority between two consecutive candidates, C1 and 195 C2, is translated according to some criteria to a delay, D. D 196 then governs the delay between the initiation of the connection 197 attempts C1 and C2. 198 3. After the initiation of the connection attempts, the Transport 199 Probing component waits for the first or winning connection to be 200 established, which becomes the selected transport solution. For 201 the Transport Probing component to be able to efficiently use the 202 connection-attempt cache, already-initiated, non-winning 203 connection attempts SHOULD be given a fair chance to complete. 204 In that way, the connection-attempt cache will be provided with a 205 fairly accurate knowledge of which transport solutions work and 206 does not work against frequently visited transport endpoints. 207 Moreover, it MAY be beneficial to let those transport solutions 208 which have a higher priority than the winning transport solution, 209 live a predetermined amount of time after their establishment, 210 since this enables the reuse of already established connections 211 in later application requests. 213 5. Design and Implementation Considerations 215 This section discusses implementation issues that should be 216 considered when a HE mechanism is designed and implemented on the 217 basis of the HE framework proposed in this document. 219 5.1. Candidate List Generation 220 +---------------+ 221 | | 222 | Application | 223 | | 224 +-------+-------+ 225 | 226 +-------v-------+ +---------------+ 227 | | | | 228 | TAPS API +--+--|Policy Manager |<-+ 229 | | | | | | 230 +---------------+ | +-------^-------+ | 231 | | | 232 +---------------+ | +-------+-------+ | 233 | Transport |<-+ | Policy | | 234 | Probing | | Information | | 235 | +--+ | Base | | 236 +---------------+ | +---------------+ | 237 | | 238 | +---------------+ | 239 | |Characteristics| | 240 +--> Information |--+ 241 | Base | 242 +---------------+ 244 Figure 2: Principle Design of the NEAT Happy Eyeballs Framework. 246 There are several ways in which the list of candidate transport 247 solutions, L, could be created by the Policy Management component. 248 For example, L could be a list of all available transport solutions 249 in an order that, except for following the host's address preference, 250 is arbitrary; another, more sophisticated, way of creating the list 251 of candidate transport solutions is the one employed by the NEAT 252 System. 254 The NEAT System is developed as part of the EU Horizon 2020 project, 255 "A New, Evolutive API and Transport-Layer Architecture for the 256 Internet" (NEAT) [NEAT-Webb], and aims to provide a flexible and 257 evolvable transport system that aligns with the charter of the TAPS 258 Working Group. In the NEAT System [NEAT-Git], the HE framework is 259 realized as shown in Figure 2. As follows, the Policy Management 260 component comprises three components in the NEAT HE framework: a 261 Policy Manager (PM), a Policy Information Base (PIB), and a 262 Characteristics Information Base (CIB). PIB is a repository that 263 stores a collection of policies that map application requests to 264 transport solutions, i.e., map application requests to appropriately 265 configured transport protocols, and CIB is a repository that stores 266 information about previous connection attempts, available network 267 interfaces, supported transport protocols etc. The PM takes as input 268 application requirements from the TAPS API, and information from PIB 269 and CIB. On the basis of this input, the PM creates L. 271 5.2. Caching 273 As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste 274 networking resources by routinely making simultaneous connection 275 attempts. To this end, the HE algorithm should cache the outcome of 276 previous connection attempts to the same peer. The cache lifetime is 277 considered system dependent and should be set on a case-by-case 278 basis. The impact and efficiency of the HE algorithm have been 279 evaluated in [Papastergiou16]. The paper suggests that caching 280 significantly reduces the CPU load imposed by a HE mechanism. It 281 also indicates that the internal-memory footprint of a HE mechanism 282 is essentially the same as for single-flow establishments. 284 5.3. Concurrent Connection Attempts 286 As mentioned in Section 4, it is the responsibility of the Transport 287 Probing component to choose the most appropriate transport solution 288 on the list of candidate transport solutions, L. Often this implies 289 that several transport solutions need to be tried out, something 290 which should not be carried out sequentially, but concurrently or 291 partly overlapping depending on the transport-solution priorities. 292 The way this is done is implementation dependent and varies between 293 platforms. The NEAT library [NEAT-Git], which implements the HE 294 framework herein, is built around the libuv asynchronous I/O library 295 [LIBUV] and uses an event-based concurrency model to realize the 296 concurrent initialization of connection attempts. The rationale 297 behind using an event-based concurrency model is at least twofold: 298 The first is that correctly managing concurrency in multi-threaded 299 applications can be challenging with, for example, missing locks or 300 deadlocks. The second is that multi-threading typically offers 301 little or no control over what is scheduled at a given momemt in 302 time. Given the complexity of building a general-purpose scheduler 303 that works well in all cases, sometimes the OS will schedule work in 304 a manner that is less than optimal. Those in favor of threads argue 305 that threads are a natural extension of sequential programming in 306 that it maps work to be executed with individual threads. Threads 307 are also a well-known and understood parts of OSes, and are mandatory 308 for exploiting true CPU concurrency. 310 6. Example Happy Eyeballs Scenario 312 Consider a scenario in which an IPv6-enabled client using the NEAT 313 System wishes to setup a connection to a server. Assume both the 314 client and server support SCTP and TCP. The Policy Management is 315 queried about feasible transport solutions to connect to the server. 316 In the NEAT System, this results in PM retrieving information about 317 network connections against this server from the CIB, e.g., supported 318 transport protocols and the outcome of previous connection attempts. 319 In our scenario, the PM learns from the CIB that the server supports 320 SCTP and TCP, and, for the sake of this example, let us assume that 321 the PM is also informed that previous connection attempts against 322 this server, using both SCTP and TCP, were successful. Next, the PM 323 retrieves applicable policies from the PIB, and combines these 324 policies with the previously retrieved CIB information. We assume in 325 this example that the SCTP transport solution has a higher priority 326 than the TCP solution. As a next step, the PM puts together the 327 feasible candidate transport solutions in a list with SCTP over IPv6 328 placed at the head of the list followed by TCP over IPv6, and 329 supplies this list to the Transport Probing component. The Transport 330 Probing component traverses the candidate list, and initiates a 331 connection attempt with SCTP against the server followed after a 332 short while (governed by the difference in priorities between the 333 SCTP and TCP transport solutions) by a connection attempt with TCP 334 against the server. In our example, assume both connection attempts 335 are successful, however, the SCTP connection attempt completes before 336 the TCP attempt. The Transport Probing component caches in the CIB 337 the SCTP connection attempt as successful, and returns the SCTP 338 connection as the winning connection. When the TCP connection is 339 established some time later, the Transport Probing component caches 340 that connection attempt as successful as well. 342 7. IANA Considerations 344 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 346 This memo includes no request to IANA. 348 8. Security Considerations 350 Security will be considered in future versions of this document. 352 9. Acknowledgements 354 This work has received funding from the European Union's Horizon 2020 355 research and innovation programme under grant agreement No. 644334 356 (NEAT). The views expressed are solely those of the author(s). 358 10. References 359 10.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 367 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 368 2012, . 370 10.2. Informative References 372 [I-D.wing-tsvwg-happy-eyeballs-sctp] 373 Wing, D. and P. Natarajan, "Happy Eyeballs: Trending 374 Towards Success with SCTP", draft-wing-tsvwg-happy- 375 eyeballs-sctp-02 (work in progress), October 2010. 377 [LIBUV] libuv -- Asynchronous I/O Made Simple, "http://libuv.org", 378 March 2017. 380 [NEAT-Git] 381 A New, Evolutive API and Transport-Layer Architecture for 382 the Internet (NEAT), "https://github.com/NEAT-project/ 383 neat", March 2017. 385 [NEAT-Webb] 386 NEAT -- A New, Evolutive API and Transport-Layer 387 Architecture for the Internet, "https://www.neat- 388 project.org", March 2017. 390 [Papastergiou16] 391 Papastergiou, G., Grinnemo, K-J., Brunstrom, A., Ros, D., 392 Tuexen, M., Khademi, N., and P. Hurtig, "On the Cost of 393 Using Happy Eyeballs for Transport Protocol Selection", 394 July 2016. 396 Authors' Addresses 398 Karl-Johan Grinnemo 399 Karlstad University 400 Universitetsgatan 2 401 Karlstad 651 88 402 Sweden 404 Phone: +46 54 700 24 40 405 Email: karl-johan.grinnemo@kau.se 406 Anna Brunstrom 407 Karlstad University 408 Universitetsgatan 2 409 Karlstad 651 88 410 Sweden 412 Phone: +46 54 700 17 95 413 Email: anna.brunstrom@kau.se 415 Per Hurtig 416 Karlstad University 417 Universitetsgatan 2 418 Karlstad 651 88 419 Sweden 421 Phone: +46 54 700 23 35 422 Email: per.hurtig@kau.se 424 Naeem Khademi 425 University of Oslo 426 PO Box 1080 Blindern 427 Oslo N-0316 428 Norway 430 Email: naeemk@ifi.uio.no 432 Zdravko Bozakov 433 Dell EMC Research Europe 434 Ovens, Co. 435 Cork 436 Ireland 438 Phone: +353 21 4945733 439 Email: Zdravko.Bozakov@dell.com