idnits 2.17.1 draft-grinnemo-taps-he-02.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 (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational P. Hurtig 5 Expires: September 14, 2017 Karlstad University 6 N. Khademi 7 University of Oslo 8 Z. Bozakov 9 Dell EMC Research Europe 10 March 13, 2017 12 Happy Eyeballs for Transport Selection 13 draft-grinnemo-taps-he-02 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 September 14, 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 . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 8 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 transport Happy Eyeballs (HE) mechanism 110 proposed in Wing et al. [RFC6555] which addresses the selection of 111 complete transport solutions, and which lends itself to arbitrary 112 transport selection criterias. 114 The HE mechanism was introduced as a means to facilitate IPv6 115 adoption. Dual-stack client applications should be encouraged to try 116 setting up connections over IPv6 first, and fall back to using IPv4 117 if IPv6 connection attempts fail. However, serializing tests for 118 IPv6 and IPv4 connectivity can result in large connection latencies. 119 HE for IPv6 minimizes the cost in delay by parallelizing attempts 120 over IPv6 and IPv4. HE has also been proposed as an efficient way to 121 find out the optimal combination of IPv4/IPv6 and TCP/SCTP to use to 122 connect to a server [I-D.wing-tsvwg-happy-eyeballs-sctp]. The HE 123 framework suggested in this document could be seen as a natural 124 continuation of this proposal. 126 3. Problem Statement 128 Currently, there is no agreed-upon way for a source end host to 129 select an appropriate transport service for a given application. In 130 fact, there is no common way for a source end-host to find out if a 131 transport stack is supported along a network path between itself and 132 a destination end host. As a consequence, it has become increasingly 133 difficult to introduce new transport stacks, and several 134 applications, including many web applications, run over TCP although 135 there are other transport protocols that better meet the requirements 136 of these applications. 138 4. The Happy Eyeballs Framework 139 +---------------+ 140 | | 141 | Application | 142 | | 143 +-------+-------+ 144 | 145 +-------v-------+ +---------------+ 146 | | | | 147 | TAPS API +-----> | 148 | | | | 149 +---------------+ | Policy | 150 +--| Management | 151 +---------------+ | | | 152 | Transport |<-+ | | 153 | Probing | | | 154 | +-----> | 155 +---------------+ +---------------+ 157 Figure 1: The Happy Eyeballs Framework. 159 The generalized HE mechanism proposed in this draft is carried out 160 within the framework depicted in Figure 1. It comprises the 161 following steps: 163 1. The Policy Management component takes as input application 164 requirements from the TAPS API, stored information about previous 165 connection attempts (e.g., whether previous connection attempts 166 succeeded or not), and network conditions and configurations. On 167 the basis of this input, the Policy Management component creates 168 a list of candidate transport solutions, L, sorted in decreasing 169 priority order. To be compliant with RFC 6555 [RFC6555], the 170 Policy Management component SHOULD, in those cases there are no 171 policies telling otherwise, give priority to IPv6 over IPv4. 172 2. It is the responsibility of the Transport Probing component to 173 select the most appropriate transport solution. This is done by 174 initiating connection attempts for each transport solution on L. 175 To minimize the number of connection attempts that are initiated, 176 the Transport Probing component SHOULD cache the outcome of 177 connection attempts in a repository kept by the Policy Management 178 component. The Policy Management component SHOULD in turn only 179 include those transport solutions on L that have not been 180 previously attempted, have valid successful connection-attempt 181 cache entries, or have previously been attempted but whose cached 182 connection-attempt entries have expired. Cached connection- 183 attempt results SHOULD be valid for a configurable amount of time 184 after which they SHOULD expire and have to be repeated. The 185 transport solutions on L are initiated in priority order. The 186 difference in priority between two consecutive candidates, C1 and 187 C2, is translated according to some criteria to a delay, D. D 188 then governs the delay between the initiation of the connection 189 attempts C1 and C2. 190 3. After the initiation of the connection attempts, the Transport 191 Probing component waits for the first or winning connection to be 192 established, which becomes the selected transport solution. For 193 the Transport Probing component to be able to efficiently use the 194 connection-attempt cache, already-initiated, non-winning 195 transport solutions SHOULD NOT be terminated as soon as a winning 196 connection has been established. Instead, they SHOULD themselves 197 be given a fair chance to establish connections. In that way, 198 the connection-attempt cache will be provided with a fairly 199 accurate knowledge of which transport solutions work and does not 200 work against frequently visited transport endpoints. Moreover, 201 it MAY be beneficial to let those transport solutions which have 202 a higher priority than the winning transport solution, live a 203 predetermined amount of time after their establishment, since 204 this enables the reuse of already established connections in 205 later application requests. 207 5. Design and Implementation Considerations 209 This section discusses implementation issues that should be 210 considered when a HE mechanism is designed and implemented on the 211 basis of the HE framework proposed in this document. 213 5.1. Candidate List Generation 214 +---------------+ 215 | | 216 | Application | 217 | | 218 +-------+-------+ 219 | 220 +-------v-------+ +---------------+ 221 | | | | 222 | TAPS API +--+--|Policy Manager |<-+ 223 | | | | | | 224 +---------------+ | +-------^-------+ | 225 | | | 226 +---------------+ | +-------+-------+ | 227 | Transport |<-+ | Policy | | 228 | Probing | | Information | | 229 | +--+ | Base | | 230 +---------------+ | +---------------+ | 231 | | 232 | +---------------+ | 233 | |Characteristics| | 234 +--> Information |--+ 235 | Base | 236 +---------------+ 238 Figure 2: The NEAT Happy Eyeballs Framework. 240 There are several ways in which the list of candidate transport 241 solutions, L, could be created by the Policy Management component. 242 For example, L could be a list of all available transport solutions 243 in an order that except for giving priority to IPv6 is arbitrary. 245 The NEAT System is developed as part of the EU Horizon 2020 project, 246 "A New, Evolutive API and Transport-Layer Architecture for the 247 Internet" (NEAT) [NEAT-Webb], and aims to provide a flexible and 248 evolvable transport system that aligns with the charter of the TAPS 249 Working Group. In the NEAT System [NEAT-Git], the HE framework is 250 realized as shown in Figure 2. As follows, the Policy Management 251 component comprises three components in the NEAT HE framework: a 252 Policy Manager (PM), a Policy Information Base (PIB), and a 253 Characteristics Information Base (CIB). PIB is a repository that 254 stores a collection of policies that map application requests to 255 transport solutions, i.e., map application requests to appropriately 256 configured transport protocols, and CIB is a repository that stores 257 information about previous connection attempts, available network 258 interfaces, supported transport protocols etc. The PM takes as input 259 application requirements from the TAPS API, and information from PIB 260 and CIB. On the basis of this input, the PM creates L. 262 5.2. Caching 264 As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste 265 networking resources by routinely making simultaneous connection 266 attempts. To this end, the HE algorithm should cache the outcome of 267 previous connection attempts to the same peer. The impact and 268 efficiency of the HE algorithm has been evaluated in 269 [Papastergiou16]. The paper suggests that caching significantly 270 reduces the CPU load imposed by a HE mechanism. 272 5.3. Concurrent Connection Attempts 274 As mentioned in Section 4, it is the responsibility of the Transport 275 Probing component to choose the most appropriate transport solution 276 on the list of candidate transport solutions, L. Often this implies 277 that several transport solutions need to be tried out, something 278 which should not be carried out sequentially, but concurrently or 279 partly overlapping depending on the transport-solution priorities. 280 The way this is done is implementation dependent and varies between 281 platforms. The NEAT library [NEAT-Git], which implements the HE 282 framework herein, is built around the libuv asynchronous I/O library 283 [LIBUV] and uses an event-based concurrency model to realize the 284 concurrent initialization of connection attempts. The rationale 285 behind using an event-based concurrency model is at least twofold: 286 The first is that correctly managing concurrency in multi-threaded 287 applications can be challenging with, for example, missing locks or 288 deadlocks. The second is that multi-threading typically offers 289 little or no control over what is scheduled at a given momemt in 290 time. Given the complexity of building a general-purpose scheduler 291 that works well in all cases, sometimes the OS will schedule work in 292 a manner that is less than optimal. Proponents of threads argue that 293 threads are a natural extension of sequential programming in that it 294 maps work to be executed with individual threads. Threads are also a 295 well-known and understood parts of OSes, and are mandatory for 296 exploiting true CPU concurrency. 298 6. Example Happy Eyeballs Scenario 300 Consider a scenario in which an IPv4-only client using the NEAT 301 System wishes to setup a connection to a server. Assume both the 302 client and server support SCTP and TCP. The PM is queried about 303 feasible transport solutions to connect to the server. This results 304 in the PM retrieving information about network connections against 305 this server from the CIB, e.g., supported transport protocols and the 306 outcome of previous connection attempts. In our scenario, the PM 307 learns from the CIB that the server supports SCTP and TCP, and, for 308 the sake of this example, let us assume that the PM is also informed 309 that previous connection attempts against this server, using both 310 SCTP and TCP, were successful. Next, the PM retrieves applicable 311 policies from the PIB, and combines these policies with the 312 previously retrieved CIB information. We assume in this example that 313 the SCTP transport solution has a higher priority than the TCP 314 solution. As a next step, the PM puts together the feasible 315 candidate transport solutions in a list with SCTP over IPv4 placed at 316 the head of the list followed by TCP over IPv4, and supplies this 317 list to the Transport Probing component. The Transport Probing 318 component traverses the candidate list, and initiates a connection 319 attempt with SCTP against the server followed after a short while 320 (governed by the difference in priorities between the SCTP and TCP 321 transport solutions) by a connection attempt with TCP against the 322 server. In our example, assume both connection attempts are 323 successful, however, the SCTP connection attempt completes before the 324 TCP attempt. The Transport Probing component caches in the CIB the 325 SCTP connection attempt as successful, and returns the SCTP 326 connection as the winning connection. When the TCP connection is 327 established some time later, the Transport Probing component caches 328 that connection attempt as successful as well. 330 7. IANA Considerations 332 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 334 This memo includes no request to IANA. 336 8. Security Considerations 338 Security will be considered in future versions of this document. 340 9. Acknowledgements 342 This work has received funding from the European Union's Horizon 2020 343 research and innovation programme under grant agreement No. 644334 344 (NEAT). The views expressed are solely those of the author(s). 346 10. References 348 10.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 356 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 357 2012, . 359 10.2. Informative References 361 [I-D.wing-tsvwg-happy-eyeballs-sctp] 362 Wing, D. and P. Natarajan, "Happy Eyeballs: Trending 363 Towards Success with SCTP", draft-wing-tsvwg-happy- 364 eyeballs-sctp-02 (work in progress), October 2010. 366 [LIBUV] libuv -- Asynchronous I/O Made Simple, "http://libuv.org", 367 March 2017. 369 [NEAT-Git] 370 A New, Evolutive API and Transport-Layer Architecture for 371 the Internet (NEAT), "https://github.com/NEAT-project/ 372 neat", March 2017. 374 [NEAT-Webb] 375 NEAT -- A New, Evolutive API and Transport-Layer 376 Architecture for the Internet, "https://www.neat- 377 project.org", March 2017. 379 [Papastergiou16] 380 Papastergiou, G., Grinnemo, K-J., Brunstrom, A., Ros, D., 381 Tuexen, M., Khademi, N., and P. Hurtig, "On the Cost of 382 Using Happy Eyeballs for Transport Protocol Selection", 383 July 2016. 385 Authors' Addresses 387 Karl-Johan Grinnemo 388 Karlstad University 389 Universitetsgatan 2 390 Karlstad 651 88 391 Sweden 393 Phone: +46 54 700 24 40 394 Email: karl-johan.grinnemo@kau.se 396 Anna Brunstrom 397 Karlstad University 398 Universitetsgatan 2 399 Karlstad 651 88 400 Sweden 402 Phone: +46 54 700 17 95 403 Email: anna.brunstrom@kau.se 404 Per Hurtig 405 Karlstad University 406 Universitetsgatan 2 407 Karlstad 651 88 408 Sweden 410 Phone: +46 54 700 23 35 411 Email: per.hurtig@kau.se 413 Naeem Khademi 414 University of Oslo 415 PO Box 1080 Blindern 416 Oslo N-0316 417 Norway 419 Email: naeemk@ifi.uio.no 421 Zdravko Bozakov 422 Dell EMC Research Europe 423 Ovens, Co. 424 Cork 425 Ireland 427 Phone: +353 21 4945733 428 Email: Zdravko.Bozakov@dell.com