idnits 2.17.1 draft-irtf-panrg-what-not-to-do-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 31, 2019) is 1852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-thomson-use-it-or-lose-it-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1190 (Obsoleted by RFC 1819) -- Obsolete informational reference (is this intentional?): RFC 2001 (Obsoleted by RFC 2581) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG S. Dawkins, Ed. 3 Internet-Draft Wonder Hamster Internetworking 4 Intended status: Informational March 31, 2019 5 Expires: October 2, 2019 7 Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not 8 Taken) 9 draft-irtf-panrg-what-not-to-do-02 11 Abstract 13 At the first meeting of the Path Aware Networking Research Group, the 14 research group agreed to catalog and analyze past efforts to develop 15 and deploy Path Aware technologies, most of which were unsuccessful, 16 in order to extract insights and lessons for path-aware networking 17 researchers. 19 This document contains that catalog and analysis. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 2, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. A Note About Path-Aware Technologies Included In This 54 Document . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Venue for Discussion of this Document . . . . . . . . . . 4 56 1.3. A Note for the Research Group . . . . . . . . . . . . . . 4 57 1.4. A Note for the Editor . . . . . . . . . . . . . . . . . . 4 58 1.5. Architectural Guidance . . . . . . . . . . . . . . . . . 4 59 2. Summary of Lessons Learned . . . . . . . . . . . . . . . . . 5 60 3. Template for Contributions . . . . . . . . . . . . . . . . . 6 61 4. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Stream Transport (ST, ST2, ST2+) . . . . . . . . . . . . 7 63 4.1.1. Reasons for Non-deployment . . . . . . . . . . . . . 8 64 4.1.2. Lessons Learned. . . . . . . . . . . . . . . . . . . 8 65 4.2. Integrated Services (IntServ) . . . . . . . . . . . . . . 8 66 4.2.1. Reasons for Non-deployment . . . . . . . . . . . . . 9 67 4.2.2. Lessons Learned. . . . . . . . . . . . . . . . . . . 9 68 4.3. Quick-Start TCP . . . . . . . . . . . . . . . . . . . . . 10 69 4.3.1. Reasons for Non-deployment . . . . . . . . . . . . . 11 70 4.3.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 12 71 4.4. ICMP Source Quench . . . . . . . . . . . . . . . . . . . 12 72 4.4.1. Reasons for Non-deployment . . . . . . . . . . . . . 13 73 4.4.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 13 74 4.5. Triggers for Transport (TRIGTRAN) . . . . . . . . . . . . 14 75 4.5.1. Reasons for Non-deployment . . . . . . . . . . . . . 14 76 4.5.2. Lessons Learned. . . . . . . . . . . . . . . . . . . 15 77 4.6. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 4.6.1. Reasons for Non-deployment . . . . . . . . . . . . . 17 79 4.6.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 18 80 4.6.3. Addendum on MultiPath TCP . . . . . . . . . . . . . . 18 81 4.7. Next Steps in Signaling (NSIS) . . . . . . . . . . . . . 18 82 4.7.1. Reasons for Non-deployment . . . . . . . . . . . . . 19 83 4.7.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 20 84 4.8. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . . 21 85 4.8.1. Reasons for Non-deployment . . . . . . . . . . . . . 21 86 4.8.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 90 8. Informative References . . . . . . . . . . . . . . . . . . . 24 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 At the first meeting of the Path Aware Networking Research Group 96 [PANRG], at IETF 99 [PANRG-99], Oliver Bonaventure led a discussion 97 of "A Decade of Path Awareness" [PATH-Decade], on attempts, which 98 were mostly unsuccessful for a variety of reasons, to exploit Path 99 Aware technologies and achieve a variety of goals over the past 100 decade. At the end of this discussion, two things were abundantly 101 clear. 103 o The Internet community has accumulated considerable experience 104 with many Path Aware technologies over a long period of time, and 106 o Although some Path Aware technologies have been successfully 107 deployed (for example, Differentiated Services, or DiffServ 108 [RFC2475]), most of these technologies haven't seen widespread 109 adoption. The reasons for non-adoption are many, and are worthy 110 of study. 112 The meta-lessons from that experience were 114 o Path Aware Networking has been more Research than Engineering, so 115 establishing an IRTF Research Group for Path Aware Networking is 116 the right thing to do [RFC7418]. 118 o Analyzing a catalog of past experience to learn the reasons for 119 non-adoption would be a great first step for the Research Group. 121 Allison Mankin, as IRTF Chair, officially chartered the Path Aware 122 Networking Research Group in July, 2018. 124 This document contains the analysis performed by that research group 125 (see Section 2), based on that catalog (see Section 4). 127 1.1. A Note About Path-Aware Technologies Included In This Document 129 This document does not catalog every technology about Path Aware 130 Networking that was not implemented and deployed. Instead, we 131 include enough technologies to provide background for the lessons 132 included in Section 2 to guide researchers and protocol engineers in 133 their work. 135 No shame is intended for the technologies included in this document. 136 As shown in Section 2, the quality of specific technologies had 137 little to do with whether they were deployed or not. Based on the 138 technologies cataloged in this document, it is likely that when these 139 technologies were put forward, the proponents were trying to engineer 140 something that could not be engineered without first carrying out 141 research. Actual shame would be failing to learn from experience, 142 and failing to share that experience with other networking 143 researchers and engineers. 145 1.2. Venue for Discussion of this Document 147 (RFC Editor: please remove this section before publication) 149 Discussion of specific contributed experiences and this document in 150 general should take place on the PANRG mailing list. 152 1.3. A Note for the Research Group 154 (RFC Editor: please remove this section before publication) 156 The editor and research group chairs are aware that the current 157 version of this document is tilted toward transport-level Path Aware 158 technologies, and would like to interact with other IETF protocol 159 communities who have experience with Path Aware technologies. 161 It is worth looking at the Lessons Learned in Section 2 to see 162 whether the Internet has changed in ways that would make some lessons 163 less applicable for future protocol design. 165 1.4. A Note for the Editor 167 (Remove after taking these actions) 169 The to-do list for upcoming revisions includes 171 o Confirm that the Summary of Lessons Learned makes sense and is 172 complete, in consultation with the Research Group. 174 o If the Research Group identifies technologies that provided 175 lessons that aren't included in Section 2, solicit contributions 176 for those technologies. 178 o Provide better context for Section 2, to make sure that individual 179 lessons aren't considered in isolation, and to distinguish between 180 impediments to deployment. 182 1.5. Architectural Guidance 184 As background for understanding the Lessons Learned contained in this 185 document, the reader is encouraged to become familiar with the 186 Internet Architecture Board's documents on "What Makes for a 187 Successful Protocol?" [RFC5218] and "Planning for Protocol Adoption 188 and Subsequent Transitions" [RFC8170]. 190 Although these two documents do not specifically target path-aware 191 networking protocols, they are helpful resources for readers seeing 192 to improve their understanding of considerations for successful and 193 deployment of any protocol. 195 Because there is an economic aspect to decisions about deployment, 196 the IAB Workshop on Internet Technology Adoption and Transition 197 [ITAT] report [RFC7305] also provides food for thought. 199 2. Summary of Lessons Learned 201 This section summarizes the Lessons Learned from the contributed 202 sections in Section 4. 204 Each Lesson Learned is tagged with one or more contributions that 205 encountered this obstacle as a significant impediment to deployment. 206 Other contributed technologies may have also encountered this 207 obstacle, but this obstacle may not have been the biggest impediment 208 to deployment. 210 o The benefit of Path Awareness must be great enough to overcome 211 entropy for already-deployed devices. The colloquial American 212 English expression, "If it ain't broke, don't fix it" is a "best 213 current practice" on today's Internet. (See Section 4.3, 214 Section 4.5, and Section 4.4). 216 o Providing benefits for early adopters can be key - if everyone 217 must deploy a technology in order for the technology to provide 218 benefits, or even to work at all, the technology is unlikely to be 219 adopted. (See Section 4.2 and Section 4.3). 221 o Adaptive end-to-end protocol mechanisms may respond to feedback 222 quickly enough that the additional realizable benefit from a new 223 Path Aware mechanism may be much smaller than anticipated (see 224 Section 4.3 and Section 4.5). 226 o "Follow the money." If operators can't charge for a Path Aware 227 technology to recover the costs of deploying it, the benefits to 228 the operator must be really significant. (See Section 4.5, 229 Section 4.1, and Section 4.2). 231 o Impact of a Path Aware technology requiring changes to operational 232 practices can prevent deployment of promising technology. (See 233 Section 4.6, including Section 4.6.3). 235 o Per-connection state in intermediate devices can be an impediment 236 to adoption and deployment. (See Section 4.1 and Section 4.2). 238 o Many modern routers, especially high-end routers, have not been 239 designed to make heavy use of in-band mechanisms such as IPv4 and 240 IPv6 Router Alert Options (RAO), so operators can be reluctant to 241 deploy technologies that rely on these mechanisms. (See 242 Section 4.7). 244 o If the endpoints do not have any trust relationship with the 245 intermediate devices along a path, operators can be reluctant to 246 deploy technologies that rely on endpoints sending unauthenticated 247 control signals to routers. (See Section 4.2 and Section 4.7. We 248 also note this still remains a factor hindering deployment of 249 DiffServ). 251 o If intermediate devices along the path can't be trusted, it's 252 unlikely that endpoints will rely on signals from intermediate 253 devices to drive changes to endpoint behaviors. (See Section 4.5, 254 Section 4.4). The lowest level of trust is sufficient for a 255 device issuing a message to confirm that it has visibility of the 256 packets on the path it is seeking to control [RFC8085] (e.g., an 257 ICMP message included a quoted packet from the source). A higher 258 level of trust can arise when a network device could have a long 259 or short term trust relationship with the sender it controls. 261 o Because the Internet is a distributed system, if the distance that 262 information from distant hosts and routers travels to a Path Aware 263 host or router is sufficiently large, the information may no 264 longer represent the state and situation at the distant host or 265 router when it is received. In this case, the benefit that a Path 266 Aware technology provides likely decreases. (See Section 4.3). 268 o Providing a new feature/signal does not mean that it will be used. 269 Endpoint stacks may not know how to effectively utilize Path-Aware 270 transport protocol technologies, because the technology may 271 require information from applications to permit them to work 272 effectively, but applications may not a-priori know that 273 information. Even if the application does know that information, 274 the de-facto API has no way of signaling the expectations of 275 applications for the network path. Providing this awareness 276 requires an API that signals more than the packets to be sent. 277 TAPS is exploring such an API [TAPS-WG], yet even with such an 278 API, policy is needed to bind the application expectations to the 279 network characteristics. (See Section 4.1 and Section 4.2). 281 3. Template for Contributions 283 There are many things that could be said about the Path Aware 284 networking technologies that have been developed. For the purposes 285 of this document, contributors are requested to provide 286 o the name of a technology, including an abbreviation if one was 287 used 289 o if available, a long-term pointer to the best reference describing 290 the technology 292 o a short description of the problem the technology was intended to 293 solve 295 o a short description of the reasons why the technology wasn't 296 adopted 298 o a short statement of the lessons that researchers can learn from 299 our experience with this technology. 301 This document is being built collaboratively. To contribute your 302 experience, please send a Github pull request to 303 https://github.com/panrg/draft-dawkins-panrg-what-not-to-do. 305 4. Contributions 307 Additional contributions that provide Lessons Learned beyond those 308 already captured in Section 2 are welcomed. 310 4.1. Stream Transport (ST, ST2, ST2+) 312 The suggested references for IntServ are: 314 o ST - A Proposed Internet Stream Protocol [IEN-119] 316 o Experimental Internet Stream Protocol, Version 2 (ST-II) [RFC1190] 318 o Internet Stream Protocol Version 2 (ST2) Protocol Specification - 319 Version ST2+ [RFC1819] 321 The first version of Stream Transport, ST [IEN-119], was published in 322 the late 1970's and was implemented and deployed on the ARPANET at 323 small scale. It was used throughout the 1980's for experimental 324 transmission of voice, video, and distributed simulation. 326 The second version of the ST specification (ST2) [RFC1190] [RFC1819] 327 was an experimental connection-oriented internetworking protocol that 328 operated at the same layer as connectionless IP. ST2 packets could 329 be distinguished by their IP header protocol numbers (IP, at that 330 time, used protocol number 4, while ST2 used protocol number 5). 332 ST2 used a control plane layered over IP to select routes and reserve 333 capacity for real-time streams across a network path, based on a flow 334 specification communicated by a separate protocol. The flow 335 specification could be associated with QoS state in routers, 336 producing an experimental resource reservation protocol. This 337 allowed ST2 routers along a path to offer end-to-end guarantees, 338 primarily to satisfy the QoS requirements for realtime services over 339 the Internet. 341 4.1.1. Reasons for Non-deployment 343 Although implemented in a range of equipment, ST2 was not widely used 344 after completion of the experiments. It did not offer the 345 scalability and fate-sharing properties that have come to be desired 346 by the Internet community. 348 The ST2 protocol is no longer in use. 350 4.1.2. Lessons Learned. 352 As time passed, the trade-off between router processing and link 353 capacity changed. Links became faster and the cost of router 354 processing became comparatively more expensive. 356 The ST2 control protocol used "hard state" - once a route was 357 established, and resources were reserved, routes and resources 358 existing until they were explicitly released via signaling. A soft- 359 state approach was thought superior to this hard-state approach, and 360 led to development of the IntServ model described in Section 4.2. 362 4.2. Integrated Services (IntServ) 364 The suggested references for IntServ are: 366 o RFC 1633 Integrated Services in the Internet Architecture: an 367 Overview [RFC1633] 369 o RFC 2211 Specification of the Controlled-Load Network Element 370 Service [RFC2211] 372 o RFC 2212 Specification of Guaranteed Quality of Service [RFC2212] 374 o RFC 2215 General Characterization Parameters for Integrated 375 Service Network Elements [RFC2215] 377 o RFC 2205 Resource ReSerVation Protocol (RSVP) [RFC2205] 379 In 1994, when the IntServ architecture document [RFC1633] was 380 published, real-time traffic was first appearing on the Internet. At 381 that time, bandwidth was still a scarce commodity. Internet Service 382 Providers built networks over DS3 (45 Mbps) infrastructure, and sub- 383 rate (< 1 Mpbs) access was common. Therefore, the IETF anticipated a 384 need for a fine-grained QoS mechanism. 386 In the IntServ architecture, some applications can require service 387 guarantees. Therefore, those applications use the Resource 388 Reservation Protocol (RSVP) [RFC2205] to signal QoS reservations 389 across network paths. Every router in the network maintains per-flow 390 soft-state to a) perform call admission control and b) deliver 391 guaranteed service. 393 Applications use Flow Specification (Flow Specs) [RFC2210] to 394 describe the traffic that they emit. RSVP reserves capacity for 395 traffic on a per Flow Spec basis. 397 4.2.1. Reasons for Non-deployment 399 Although IntServ has been used in enterprise and government networks, 400 IntServ was never widely deployed on the Internet because of its 401 cost. The following factors contributed to operational cost: 403 o IntServ must be deployed on every router that is on a path where 404 IntServ is to be used 406 o IntServ maintained per flow state 408 As IntServ was being discussed, the following occurred: 410 o For many expected uses, it became more cost effective to solve the 411 QoS problem by adding bandwidth. Between 1994 and 2000, Internet 412 Service Providers upgraded their infrastructures from DS3 (45 413 Mbps) to OC-48 (2.4 Gbps). This meant that even if an endpoint 414 was using IntServ in an IntServ-enabled network, its requests 415 would never be denied, so endpoints and Internet Service Providers 416 had little reason to enable IntServ. 418 o DiffServ [RFC2475] offered a more cost-effective, albeit less 419 fine-grained, solution to the QoS problem. 421 4.2.2. Lessons Learned. 423 The following lessons were learned: 425 o Any mechanism that requires a router to maintain per-flow state is 426 not likely to succeed, unless the additional cost for offering the 427 feature can be recovered from the user. 429 o Any mechanism that requires an operator to upgrade all of its 430 routers is not likely to succeed, unless the additional cost for 431 offering the feature can be recovered from the user. 433 In environments where IntServ has been deployed, trust relationships 434 with endpoints are very different from trust relationships on the 435 Internet itself, and there are often clearly-defined hierarchies in 436 Service Level Agreements (SLAs), and well-defined transport flows 437 operating with pre-determined capacity and latency requirements over 438 paths where capacity or other attributes are constrained. 440 IntServ was never widely deployed to manage capacity across the 441 Internet. However, the technology that it produced was deployed for 442 reasons other than bandwidth management. RSVP is widely deployed as 443 an MPLS signaling mechanism. BGP reuses the RSVP concept of Filter 444 Specs to distribute firewall filters, although they are called Flow 445 Spec Component Types in BGP [RFC5575]. 447 4.3. Quick-Start TCP 449 The suggested references for Quick-Start TCP are: 451 o RFC 4782 Quick-Start for TCP and IP [RFC4782] 453 o Determining an appropriate initial sending rate over an 454 underutilized network path [SAF07] 456 o Fast Startup Internet Congestion Control for Broadband Interactive 457 Applications [Sch11] 459 o RFC 5634 Quick-Start for the Datagram Congestion Control Protocol 460 (DCCP) [RFC5634] 462 o Using Quick-Start to enhance TCP-friendly rate control performance 463 in bidirectional satellite networks [QS-SAT] 465 Quick-Start [RFC4782] is an Experimental TCP extension that leverages 466 support from the routers on the path to determine an allowed initial 467 sending rate for a path through the Internet, either at the start of 468 data transfers or after idle periods. A corresponding mechanism was 469 also specified for other congestion controllers (e.g., "Quick-Start 470 for the Datagram Congestion Control Protocol (DCCP)" [RFC5634]). In 471 these cases, a sender cannot easily determine an appropriate initial 472 sending rate, given the lack of information about the path. The 473 default TCP congestion control therefore uses the time-consuming 474 slow-start algorithm. With Quick-Start, connections are allowed to 475 use higher initial sending rates if there is significant unused 476 bandwidth along the path, and if the sender and all of the routers 477 along the path approve the request. 479 By examining the Time To Live (TTL) field in Quick-Start packets, a 480 sender can determine if routers on the path have approved the Quick- 481 Start request. However, this method is unable to take into account 482 the routers hidden by tunnels or other network devices invisible at 483 the IP layer. 485 The protocol also includes a nonce that provides protection against 486 cheating routers and receivers. If the Quick-Start request is 487 explicitly approved by all routers along the path, the TCP host can 488 send at up to the approved rate; otherwise TCP would use the default 489 congestion control. Quick-Start requires modifications in the 490 involved end-systems as well in routers. Due to the resulting 491 deployment challenges, Quick-Start was only proposed in [RFC4782] for 492 controlled environments. 494 The Quick-Start mechanism is a lightweight, coarse-grained, in-band, 495 network-assisted fast startup mechanism. The benefits are studied by 496 simulation in a research paper [SAF07] that complements the protocol 497 specification. The study confirms that Quick-Start can significantly 498 speed up mid-sized data transfers. That paper also presents router 499 algorithms that do not require keeping per-flow state. Later studies 500 [Sch11] comprehensively analyzes Quick-Start with a full Linux 501 implementation and with a router fast path prototype using a network 502 processor. In both cases, Quick-Start could be implemented with 503 limited additional complexity. 505 4.3.1. Reasons for Non-deployment 507 However, experiments with Quick-Start in [Sch11] revealed several 508 challenges: 510 o Having information from the routers along the path can reduce the 511 risk of congestion, but cannot avoid it entirely. Determining 512 whether there is unused capacity is not trivial in actual router 513 and host implementations. Data about available capacity visible 514 at the IP layer may be imprecise, and due to the propagation 515 delay, information can already be outdated when it reaches a 516 sender. There is a trade-off between the speedup of data 517 transfers and the risk of congestion even with Quick-Start. This 518 could be mitigated by only allowing Quick-Start to access a 519 proportion of the unused capacity along a path. 521 o For scalable router fast path implementation, it is important to 522 enable parallel processing of packets, as this is a widely used 523 method e.g. in network processors. One challenge is 524 synchronization of information between different packets, which 525 should be avoided as much as possible. 527 o Only some types of application traffic can benefit from Quick- 528 Start. Capacity needs to be requested and discovered. The 529 discovered capacity needs to be utilized by the flow, or it 530 implicitly becomes available for other flows. Failing to use the 531 requested capacity may have already reduced the pool of Quick- 532 Start capacity that was made available to other competing Quick- 533 Start requests. The benefit is greatest when senders use this 534 only for bulk flows and avoid sending unnecessary Quick-Start 535 requests, e.g. for flows that only send a small amount of data. 536 Choosing an appropriate request size requires application-internal 537 knowledge that is not commonly expressed by the transport API. 538 How a sender can determine the rate for an initial Quick-Start 539 request is still a largely unsolved problem. 541 There is no known deployment of Quick-Start for TCP or other IETF 542 transports. 544 4.3.2. Lessons Learned 546 Some lessons can be learned from Quick-Start. Despite being a very 547 light-weight protocol, Quick-Start suffers from poor incremental 548 deployment properties, both regarding the required modifications in 549 network infrastructure as well as its interactions with applications. 550 Except for corner cases, congestion control can be quite efficiently 551 performed end-to-end in the Internet, and in modern stacks there is 552 not much room for significant improvement by additional network 553 support. 555 After publication of the Quick-Start specification, there have been 556 large-scale experiments with an initial window of up to 10 MSS 557 [RFC6928]. This alternative "IW10" approach can also ramp-up data 558 transfers faster than the standard congestion control, but it only 559 requires sender-side modifications. As a result, this approach can 560 be easier and incrementally deployed in the Internet. While 561 theoretically Quick-Start can outperform "IW10", the improvement in 562 completion time for data transfer times can, in many cases, be small. 563 After publication of [RFC6928], most modern TCP stacks have increased 564 their default initial window. 566 4.4. ICMP Source Quench 568 The suggested references for ICMP Source Quench are: 570 o INTERNET CONTROL MESSAGE PROTOCOL [RFC0792] 571 The ICMP Source Quench message [RFC0792] allowed an on-path router to 572 request the source of a flow to reduce its sending rate. This method 573 allowed a router to provide an early indication of impending 574 congestion on a path to the sources that contribute to that 575 congestion. 577 4.4.1. Reasons for Non-deployment 579 This method was deployed in Internet routers over a period of time, 580 the reaction of endpoints to receiving this signal has varied. For 581 low speed links, with low multiplexing of flows the method could be 582 used to regulate (momentarily reduce) the transmission rate. 583 However, the simple signal does not scale with link speed, or the 584 number of flows sharing a link. 586 The approach was overtaken by the evolution of congestion control 587 methods in TCP [RFC2001], and later also by other IETF transports. 588 Because these methods were based upon measurement of the end-to-end 589 path and an algorithm in the endpoint, they were able to evolve and 590 mature more rapidly than methods relying on interactions between 591 operational routers and endpoint stacks. 593 After ICMP Source Quench was specified, the IETF began to recommend 594 that transports provide end-to-end congestion control [RFC2001]. The 595 Source Quench method has been obsoleted by the IETF [RFC6633], and 596 both hosts and routers must now silently discard this message. 598 4.4.2. Lessons Learned 600 This method had several problems: 602 First, [RFC0792] did not sufficiently specify how the sender would 603 react to the ICMP Source Quench signal from the path (e.g., 604 [RFC1016]). There was ambiguity in how the sender should utilize 605 this additional information. This could lead to unfairness in the 606 way that receivers (or routers) responded to this message. 608 Second, while the message did provide additional information, the 609 Explicit Congestion Notification (ECN) mechanism [RFC3168] provided a 610 more robust and informative signal for network devices to provide 611 early indication that a path has become congested. 613 The mechanism originated at a time when the Internet trust model was 614 very different. Most endpoint implementations did not attempt to 615 verify that the message originated from an on-path device before they 616 utilized the message. This made it vulnerable to denial of service 617 attacks. In theory, routers might have chosen to use the quoted 618 packet contained in the ICMP payload to validate that the message 619 originated from an on-path device, but this would have increased per- 620 packet processing overhead for each router along the path, would have 621 required transport functionality in the router to verify whether the 622 quoted packet header corresponded to a packet the router had sent. 623 In addition, section 5.2 of [RFC4443] noted ICMPv6-based attacks on 624 hosts that would also have threatened routers processing ICMPv6 625 Source Quench payloads. As time passed, it became increasingly 626 obvious that the lack of validation of the messages exposed receivers 627 to a security vulnerability where the messages could be forged to 628 create a tangible denial of service opportunity. 630 4.5. Triggers for Transport (TRIGTRAN) 632 The suggested references for TRIGTRAN are: 634 o TRIGTRAN BOF at IETF 55 [TRIGTRAN-55] 636 o TRIGTRAN BOF at IETF 56 [TRIGTRAN-56] 638 TCP [RFC0793] has a well-known weakness - the end-to-end flow control 639 mechanism has only a single signal, the loss of a segment, and TCP 640 implementations since the late 1980s have interpreted the loss of a 641 segment as evidence that the path between two endpoints may have 642 become congested enough to exhaust buffers on intermediate hops, so 643 that the TCP sender should "back off" - reduce its sending rate until 644 it knows that its segments are now being delivered without loss 645 [RFC2581]. More modern TCP stacks have added a growing array of 646 strategies about how to establish the sending rate [RFC5681], but 647 when a path is no longer operational, TCP would continue to retry 648 transmissions, which would fail, again, and double their 649 Retransmission Time Out (RTO) timers with each failed transmission, 650 with the result that TCP would wait many seconds before retrying a 651 segment, even if the path becomes operational while the sender is 652 waiting for its next retry. 654 The thinking behind TRIGTRAN was that if a path completely stopped 655 working because a link along the path was "down", somehow TCP could 656 be signaled when that link returned to service, and the sending TCP 657 could retry immediately, without waiting for a full retransmission 658 timeout (RTO) period. 660 4.5.1. Reasons for Non-deployment 662 The early dreams for TRIGTRAN were dashed because of an assumption 663 that TRIGTRAN triggers would be unauthenticated. This meant that any 664 "safe" TRIGTRAN mechanism would have relied on a mechanism such as 665 setting the IPv4 TTL or IPv6 Hop Count to 255 at a sender and testing 666 that it was 254 upon receipt, so that a receiver could verify that a 667 signal was generated by an adjacent sender known to be on the path 668 being used, and not some unknown sender which might not even be on 669 the path (e.g., "The Generalized TTL Security Mechanism (GTSM)" 670 [RFC5082]). This situation is very similar to the case for ICMP 671 Source Quench messages as described in Section 4.4, which were also 672 unauthenticated, and could be sent by an off-path attacker, resulting 673 in deprecation of ICMP Source Quench message processing [RFC6633]. 675 TRIGTRAN's scope shrunk from "the path is down" to "the first-hop 676 link is down". 678 But things got worse. 680 Because TRIGTRAN triggers would only be provided when the first-hop 681 link was "down", TRIGTRAN triggers couldn't replace normal TCP 682 retransmission behavior if the path failed because some link further 683 along the network path was "down". So TRIGTRAN triggers added 684 complexity to an already complex TCP state machine, and did not allow 685 any existing complexity to be removed. 687 There was also an issue that the TRIGTRAN signal was not sent in 688 response to a specific host that had been sending packets, and was 689 instead a signal that stimulated a response by any sender on the 690 link. This needs to scale when there are multiple flows trying to 691 use the same resource, yet the sender of a trigger has no 692 understanding how many of the potential traffic sources will respond 693 by sending packets - if recipients of the signal back-off their 694 responses to a trigger to improve scaling, then that immediately 695 mitigates the benefit of the signal. 697 Finally, intermediate forwarding devices required modification to 698 provide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN 699 triggers, so there was no way to recover the cost of modifying, 700 testing, and deploying updated intermediate devices. 702 Two TRIGTRAN BOFs were held, at IETF 55 [TRIGTRAN-55] and IETF 56 703 [TRIGTRAN-56], but this work was not chartered, and there was no 704 interest in deploying TRIGTRAN unless it was chartered and 705 standardized in the IETF. 707 4.5.2. Lessons Learned. 709 The reasons why this work was not chartered, much less deployed, 710 provide several useful lessons for researchers. 712 o TRIGTRAN started with a plausible value proposition, but 713 networking realities in the early 2000s forced reductions in scope 714 that led directly to reductions in potential benefits, but no 715 corresponding reductions in costs and complexity. 717 o These reductions in scope were the direct result of an inability 718 for hosts to trust or authenticate TRIGTRAN signals they received 719 from the network. 721 o Operators did not believe they could charge for TRIGTRAN 722 signaling, because first-hop links didn't fail frequently, and 723 TRIGTRAN provided no reduction in operating expenses, so there was 724 little incentive to purchase and deploy TRIGTRAN-capable network 725 equipment. 727 It is also worth noting that the targeted environment for TRIGTRAN in 728 the late 1990s contained links with a relatively small number of 729 directly-connected hosts - for instance, cellular or satellite links. 730 The transport community was well aware of the dangers of sender 731 synchronization based on multiple senders receiving the same stimulus 732 at the same time, but the working assumption for TRIGTRAN was that 733 there wouldn't be enough senders for this to be a meaningful problem. 734 In the 2010s, it is common for a single "link" to support many 735 senders and receivers on a single link, likely requiring TRIGTRAN 736 senders to wait some random amount of time before sending after 737 receiving a TRIGTRAN signal, which would have reduced the benefits of 738 TRIGTRAN even more. 740 4.6. Shim6 742 The suggested references for Shim6 are: 744 o RFC5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6 745 [RFC5533] 747 The IPv6 routing architecture [RFC1887] assumed that most sites on 748 the Internet would be identified by Provider Assigned IPv6 prefixes, 749 so that Default-Free Zone routers only contained routes to other 750 providers, resulting in a very small routing table. 752 For a single-homed site, this could work well. A multihomed site 753 with only one upstream provider could also work well, although BGP 754 multihoming from a single upstream provider was often a premium 755 service (costing more than twice as much as two single-homed sites), 756 and if the single upstream provider went out of service, all of the 757 multihomed paths could fail simultaneously. 759 IPv4 sites often multihomed by obtaining Provider Independent 760 prefixes, and advertising these prefixes through multiple upstream 761 providers. With the assumption that any multihomed IPv4 site would 762 also multihome in IPv6, it seemed likely that IPv6 routing would be 763 subject to the same pressures to announce Provider Independent 764 prefixes, resulting in a global IPv6 routing table that exhibited the 765 same problems as the global IPv4 routing table. During the early 766 2000s, work began on a protocol that would provide the same benefits 767 for multihomed IPv6 sites without requiring sites to advertise 768 Provider Independent prefixes into the global routing table. 770 This protocol, called Shim6, allowed two endpoints to exchange 771 multiple addresses ("Locators") that all mapped to the same endpoint 772 ("Identity"). After an endpoint learned multiple Locators for the 773 other endpoint, it could send to any of those Locators with the 774 expectation that those packets would all be delivered to the endpoint 775 with the same Identity. Shim6 was an example of an "Identity/Locator 776 Split" protocol. 778 Shim6, as defined in [RFC5533] and related RFCs, provided a workable 779 solution for IPv6 multihoming using Provider Assigned prefixes, 780 including capability discovery and negotiation, and allowing end-to- 781 end application communication to continue even in the face of path 782 failure, because applications don't see Locator failures, and 783 continue to communicate with the same Identity using a different 784 Locator. 786 4.6.1. Reasons for Non-deployment 788 Note that the problem being addressed was "site multihoming", but 789 Shim6 was providing "host multihoming". That meant that the decision 790 about what path would be used was under host control, not under 791 router control. 793 Although more work could have been done to provide a better technical 794 solution, the biggest impediments to Shim6 deployment were 795 operational and business considerations. These impediments were 796 discussed at multiple network operator group meetings, including 797 [Shim6-35] at [NANOG-35]. 799 The technology issues centered around concerns that Shim6 relied on 800 the host to track all the connections, while also tracking Identity/ 801 Locator mappings in the kernel, and tracking failures to recognize 802 that a backup path has failed. 804 The operator issues centered around concerns that operators were 805 performing traffic engineering, but would have no visibility or 806 control over hosts when they chose to begin using another path, and 807 relying on hosts to engineer traffic exposed their networks to 808 oscillation based on feedback loops, as hosts move from path to path. 809 At a minimum, traffic engineering policies must be pushed down to 810 individual hosts. In addition, the usual concerns about firewalls 811 that expected to find a transport-level protocol header in the IP 812 payload, and won't be able to perform firewalling functions because 813 its processing logic would have to look past the Identity header. 815 The business issues centered removing or reducing the ability to sell 816 BGP multihoming service, which is often more expensive than single- 817 homed connectivity. 819 4.6.2. Lessons Learned 821 It is extremely important to take operational concerns into account 822 when a path-aware protocol is making decisions about path selection 823 that may conflict with existing operational practices and business 824 considerations. 826 4.6.3. Addendum on MultiPath TCP 828 During discussions in the PANRG session at IETF 103 [PANRG-103-Min], 829 Lars Eggert, past Transport Area Director, pointed out that during 830 charter discussions for the Multipath TCP working group [MP-TCP], 831 operators expressed concerns that customers could use Multipath TCP 832 to loadshare TCP connections across operators simultaneously and 833 compare passive performance measurements across network paths in real 834 time, changing the balance of power in those business relationships. 835 Although the Multipath TCP working group was chartered, this concern 836 could have acted as an obstacle to deployment. 838 Operator objections to Shim6 were focused on technical concerns, but 839 this concern could have also been an obstacle to Shim6 deployment if 840 the technical concerns had been overcome. 842 4.7. Next Steps in Signaling (NSIS) 844 The suggested references for NSIS are: 846 o the concluded working group charter [NSIS-CHARTER-2001] 848 o RFC 5971 GIST: General Internet Signalling Transport [RFC5971] 850 o RFC 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 851 [RFC5973] 853 o RFC 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of- 854 Service Signaling [RFC5974] 856 o RFC 5981 "Authorization for NSIS Signaling Layer Protocols 857 [RFC5981] 859 The Next Steps in Signaling (NSIS) Working Group worked on signaling 860 technologies for network layer resources (e.g., QoS resource 861 reservations, Firewall and NAT traversal). 863 When RSVP [RFC2205] was used in deployments, a number of questions 864 came up about its perceived limitations and potential missing 865 features. The issues noted in the NSIS Working Group charter 866 [NSIS-CHARTER-2001] include interworking between domains with 867 different QoS architectures, mobility and roaming for IP interfaces, 868 and complexity. Later, the lack of security in RSVP was also 869 recognized ([RFC4094]). 871 The NSIS Working Group was chartered to tackle those issues and 872 initially focused on QoS signaling as its primary use case. However, 873 over time a new approach evolved that introduced a modular 874 architecture using application-specific signaling protocols (the NSIS 875 Signaling Layer Protocol (NSLP)) on top of a generic signaling 876 transport protocol (the NSIS Transport Layer Protocol (NTLP)). 878 The NTLP is defined in [RFC5971]. Two NSLPs are defined: the NSIS 879 Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling 880 [RFC5974] as well as the NAT/Firewall NSIS Signaling Layer Protocol 881 (NSLP) [RFC5973]. 883 4.7.1. Reasons for Non-deployment 885 The obstacles for deployment can be grouped into implementation- 886 related aspects and operational aspects. 888 o Implementation-related aspects: 890 Although NSIS provides benefits with respect to flexibility, 891 mobility, and security compared to other network signaling 892 technologies, hardware vendors were reluctant to deploy this 893 solution, because it would require additional implementation effort 894 and would result in additional complexity for router implementations. 896 The NTLP mainly operates as path-coupled signaling protocol, i.e, its 897 messages are processed at the intermediate node's control plane that 898 are also forwarding the data flows. This requires a mechanism to 899 intercept signaling packets while they are forwarded in the same 900 manner (especially along the same path) as data packets. One reason 901 for the non-deployment of NSIS is the usage of the IPv4 and IPv6 902 Router Alert Option (RAO) to allow for an efficient interception of 903 those path-coupled signaling messages: This option requires router 904 implementations to correctly understand and implement the handling of 905 RAOs, e.g., to only process packet with RAOs of interest and to leave 906 packets with irrelevant RAOs in the fast forwarding processing path 907 (a comprehensive discussion of these issues can be found in 908 [RFC6398]). The latter was an issue with some router implementations 909 at the time of standardization. 911 Another reason is that path-coupled signaling protocols that interact 912 with routers and request manipulation of state at these routers (or 913 any other network element in general) are under scrutiny: a packet 914 (or sequence of packets) out of the mainly untrusted data path is 915 requesting creation and manipulation of network state. This is seen 916 as potentially dangerous (e.g., opens up a Denial of Service (DoS) 917 threat to a router's control plane) and difficult for an operator to 918 control. End-to-end signaling approaches were considered problematic 919 (see also section 3 of [RFC6398]). There are recommendations on how 920 to secure NSIS nodes and deployments (e.g., [RFC5981]). 922 o Operational Aspects: 924 End-to-end signaling technologies not only require trust between 925 customers and their provider, but also among different providers. 926 Especially, QoS signaling technologies would require some kind of 927 dynamic service level agreement support that would imply (potentially 928 quite complex) bilateral negotiations between different Internet 929 service providers. This complexity was not considered to be 930 justified and increasing the bandwidth (and thus avoiding 931 bottlenecks) was cheaper than actively managing network resource 932 bottlenecks by using path-coupled QoS signaling technologies. 933 Furthermore, an end-to-end path typically involves several provider 934 domains and these providers need to closely cooperate in cases of 935 failures. 937 4.7.2. Lessons Learned 939 One goal of NSIS was to decrease the complexity of the signaling 940 protocol, but a path-coupled signaling protocol comes with the 941 intrinsic complexity of IP-based networks, beyond the complexity of 942 the signaling protocol itself. Sources of intrinsic complexity 943 include: 945 o the presence of asymmetric routes between endpoints and routers 947 o the lack of security and trust at large in the Internet 948 infrastructure 950 o the presence of different trust boundaries 952 o the effects of best-effort networks (e.g., robustness to packet 953 loss) 955 o divergence from the fate sharing principle (e.g., state within the 956 network). 958 Any path-coupled signaling protocol has to deal with these realities. 960 Operators view the use of IPv4 and IPv6 Router Alert Option (RAO) to 961 signal routers along the path from end systems with suspicion, 962 because these end systems are usually not authenticated and heavy use 963 of RAOs can easily increase the CPU load on routers that are designed 964 to process most packets using a hardware "fast path". 966 4.8. IPv6 Flow Label 968 The suggested references for IPv6 Flow Label are: 970 o IPv6 Flow Label Specification [RFC6437] 972 IPv6 specifies a 20-bit field Flow Label field [RFC6437], included in 973 the fixed part of the IPv6 header and hence present in every IPv6 974 packet. An endpoint sets the value in this field to one of a set of 975 pseudo-randomly assigned values. If a packet is not part of any 976 flow, the flow label value is set to zero [RFC3697]. A number of 977 Standards Track and Best Current Practice RFCs (e.g., [RFC8085], 978 [RFC6437], [RFC6438]) encourage IPv6 endpoints to set a non-zero 979 value in this field. A multiplexing transport could choose to use 980 multiple flow labels to allow the network to independently forward 981 its subflows, or to use one common value for the traffic aggregate. 982 The flow label is present in all fragments. IPsec was originally put 983 forward as one important use-case for this mechanism and does encrypt 984 the field [RFC6438]. 986 Once set, the flow label can provide information that can help inform 987 network devices about subflows present at the transport layer, 988 without needing to interpret the setting of upper layer protocol 989 fields [RFC6294]. This information can also be used to coordinate 990 how aggregates of transport subflows are grouped when queued in the 991 network and to select appropriate per-flow forwarding when choosing 992 between alternate paths [RFC6438] (e.g. for Equal Cost Multipath 993 Routing (ECMP) and Link Aggregation (LAG)). 995 4.8.1. Reasons for Non-deployment 997 Despite the field being present in every IPv6 packet, the mechanism 998 did not receive as much use as originally envisioned. One reason is 999 that to be useful it requires engagement by two different 1000 stakeholders: 1002 o Endpoint Implementation: 1004 For network devices along a path to utilize the flow label there 1005 needs to be a non-zero value value inserted in the field [RFC6437] at 1006 the sending endpoint. There needs to be an incentive for an endpoint 1007 to set an appropriate non-zero value. The value should appropriately 1008 reflect the level of aggregation the traffic expects to be provided 1009 by the network. However, this requires the stack to know granularity 1010 at which flows should be identified (or conversely which flows should 1011 receive aggregated treatment), i.e., which packets carry the same 1012 flow label. Therefore, setting a non-zero value may result in 1013 additional choices that need to be made by an application developer. 1015 Although the standard [RFC3697] forbids any encoding of meaning into 1016 the flow label value, the opportunity to use the flow label as a 1017 covert channel or to signal other meta-information may have raised 1018 concerns about setting a non-zero value [RFC6437]. 1020 Before methods are widely deployed to use this method, there could be 1021 no incentive for an endpoint to set the field. 1023 o Operational support in network devices: 1025 A benefit can only be realized when a network device along the path 1026 also uses this information to inform its decisions. Network 1027 equipment (routers and/or middleboxes) need to include appropriate 1028 support so they can utilize the field when making decisions about how 1029 to classify flows, or to inform forwarding choices. Use of any 1030 optional feature in a network device also requires corresponding 1031 updates to operational procedures, and therefore is normally only 1032 introduced when the cost can be justified. 1034 A benefit from utilizing the flow label is expected to be increased 1035 quality of experience for applications - but this comes at some 1036 operational cost to an operator, and requires endpoints to set the 1037 field. 1039 4.8.2. Lessons Learned 1041 The flow label is a general purpose header field for use by the path. 1042 Multiple uses have been proposed. One candidate use was to reduce 1043 the complexity of forwarding decisions. However, modern routers can 1044 use a "fast path", often taking advantage of hardware to accelerate 1045 processing. The method can assist in more complex forwarding, such 1046 as ECMP and load balancing. 1048 Although [RFC6437] recommended that endpoints should by default 1049 choose uniformly-distributed labels for their traffic, the 1050 specification permitted an endpoint to choose to set a zero value. 1052 This ability of endpoints to choose to set a flow label of zero has 1053 had consequences on deployability: 1055 o Before wide-scale support by endpoints, it would be impossible to 1056 rely on a non-zero flow label being set. Network devices 1057 therefore would need to also employ other techniques to realize 1058 equivalent functions. An example of a method is one assuming 1059 semantics of the source port field to provide entropy input to a 1060 network-layer hash. This use of a 5-tuple to classify a packet 1061 represents a layering violation [RFC6294]. When other methods 1062 have been deployed, they increase the cost of deploying standards- 1063 based methods, even though they may offer less control to 1064 endpoints and result in potential interaction with other uses/ 1065 interpretation of the field. 1067 o Even though the flow label is specified as an end-to-end field, 1068 some network paths have been observed to not transparently forward 1069 the flow label. This could result from non-conformant equipment, 1070 or could indicate that some operational networks have chosen to 1071 re-use the protocol field for other (e.g. internal purposes). 1072 This results in lack of transparency, and a deployment hurdle to 1073 endpoints expecting that they can set a flow label that is 1074 utilized by the network. The more recent practice of "greasing" 1075 [GREASE] would suggest that a different outcome could have been 1076 achieved if endpoints were always required to set a non-zero 1077 value. 1079 o [RFC1809] noted that setting the choice of the flow label value 1080 can depend on the expectations of the traffic generated by an 1081 application, which suggests an API should be presented to control 1082 the setting or policy that is used. However, many currently 1083 available APIs do not have this support. 1085 A growth in the use of encrypted transports, (e.g. QUIC [QUIC-WG]) 1086 seems likely to raise similar issues to those discussed above and 1087 could motivate renewed interest in utilizing the flow label. 1089 5. Security Considerations 1091 This document describes Path Aware technologies that were not adopted 1092 and widely deployed on the Internet, so it doesn't affect the 1093 security of the Internet. 1095 If this document meets its goals, we may develop new technologies for 1096 Path Aware Networking that would affect the security of the Internet, 1097 but security considerations for those technologies will be described 1098 in the corresponding RFCs that specify them. 1100 6. IANA Considerations 1102 This document makes no requests of IANA. 1104 7. Acknowledgments 1106 Initial material for Section 4.1 on ST2 was provided by Gorry 1107 Fairhurst. 1109 Initial material for Section 4.2 on IntServ was provided by Ron 1110 Bonica. 1112 Initial material for Section 4.3 on Quick-Start TCP was provided by 1113 Michael Scharf. 1115 Initial material for Section 4.4 on ICMP Source Quench was provided 1116 by Gorry Fairhurst. 1118 Initial material for Section 4.5 on Triggers for Transport (TRIGTRAN) 1119 was provided by Spencer Dawkins. 1121 Section 4.6 on Shim6 builds on initial material describing obstacles 1122 provided by Erik Nordmark, with background added by Spencer Dawkins. 1124 Initial material for Section 4.7 on Next Steps In Signaling (NSIS) 1125 was provided by Roland Bless and Martin Stiemerling. 1127 Initial material for Section 4.8 on IPv6 Flow Labels was provided by 1128 Gorry Fairhurst. 1130 Our thanks to Gorry Fairhurst, Joe Touch, Joeri de Ruiter, Roland 1131 Bless, Ruediger Geib, and Wes Eddy, who provided review comments on 1132 previous versions. 1134 Special thanks to Adrian Farrel for helping Spencer navigate the 1135 twisty little passages of Flow Specs and Filter Specs in IntServ, 1136 RSVP, MPLS, and BGP. They are all alike, except for the differences 1137 [Colossal-Cave]. 1139 8. Informative References 1141 [Colossal-Cave] 1142 "Wikipedia Page for Colossal Cave Adventure", January 1143 2019, 1144 . 1146 [GREASE] Thomson, M., "Long-term Viability of Protocol Extension 1147 Mechanisms", January 2019, . 1150 [IEN-119] Forgie, J., "ST - A Proposed Internet Stream Protocol", 1151 September 1979, 1152 . 1154 [ITAT] "IAB Workshop on Internet Technology Adoption and 1155 Transition (ITAT)", December 2013, 1156 . 1158 [MP-TCP] "Multipath TCP Working Group Home Page", n.d., 1159 . 1161 [NANOG-35] 1162 "North American Network Operators Group NANOG-35 Agenda", 1163 October 2005, 1164 . 1166 [NSIS-CHARTER-2001] 1167 "Next Steps In Signaling Working Group Charter", March 1168 2011, 1169 . 1171 [PANRG] "Path Aware Networking Research Group (Home Page)", n.d., 1172 . 1174 [PANRG-103-Min] 1175 "Path Aware Networking Research Group - IETF-103 Minutes", 1176 November 2018, 1177 . 1179 [PANRG-99] 1180 "Path Aware Networking Research Group - IETF-99", July 1181 2017, 1182 . 1184 [PATH-Decade] 1185 Bonaventure, O., "A Decade of Path Awareness", July 2017, 1186 . 1189 [QS-SAT] Secchi, R., Sathiaseelan, A., Potorti, F., Gotta, A., and 1190 G. Fairhurst, "Using Quick-Start to enhance TCP-friendly 1191 rate control performance in bidirectional satellite 1192 networks", 2009, 1193 . 1195 [QUIC-WG] "QUIC Working Group Home Page", n.d., 1196 . 1198 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1199 RFC 792, DOI 10.17487/RFC0792, September 1981, 1200 . 1202 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1203 RFC 793, DOI 10.17487/RFC0793, September 1981, 1204 . 1206 [RFC1016] Prue, W. and J. Postel, "Something a Host Could Do with 1207 Source Quench: The Source Quench Introduced Delay 1208 (SQuID)", RFC 1016, DOI 10.17487/RFC1016, July 1987, 1209 . 1211 [RFC1190] Topolcic, C., "Experimental Internet Stream Protocol: 1212 Version 2 (ST-II)", RFC 1190, DOI 10.17487/RFC1190, 1213 October 1990, . 1215 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 1216 Services in the Internet Architecture: an Overview", 1217 RFC 1633, DOI 10.17487/RFC1633, June 1994, 1218 . 1220 [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", 1221 RFC 1809, DOI 10.17487/RFC1809, June 1995, 1222 . 1224 [RFC1819] Delgrossi, L., Ed. and L. Berger, Ed., "Internet Stream 1225 Protocol Version 2 (ST2) Protocol Specification - Version 1226 ST2+", RFC 1819, DOI 10.17487/RFC1819, August 1995, 1227 . 1229 [RFC1887] Rekhter, Y., Ed. and T. Li, Ed., "An Architecture for IPv6 1230 Unicast Address Allocation", RFC 1887, 1231 DOI 10.17487/RFC1887, December 1995, 1232 . 1234 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 1235 Retransmit, and Fast Recovery Algorithms", RFC 2001, 1236 DOI 10.17487/RFC2001, January 1997, 1237 . 1239 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1240 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1241 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1242 September 1997, . 1244 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1245 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 1246 . 1248 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1249 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 1250 September 1997, . 1252 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1253 of Guaranteed Quality of Service", RFC 2212, 1254 DOI 10.17487/RFC2212, September 1997, 1255 . 1257 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 1258 Parameters for Integrated Service Network Elements", 1259 RFC 2215, DOI 10.17487/RFC2215, September 1997, 1260 . 1262 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1263 and W. Weiss, "An Architecture for Differentiated 1264 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1265 . 1267 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1268 Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, 1269 . 1271 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1272 of Explicit Congestion Notification (ECN) to IP", 1273 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1274 . 1276 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 1277 "IPv6 Flow Label Specification", RFC 3697, 1278 DOI 10.17487/RFC3697, March 2004, 1279 . 1281 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 1282 Service Signaling Protocols", RFC 4094, 1283 DOI 10.17487/RFC4094, May 2005, 1284 . 1286 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1287 Control Message Protocol (ICMPv6) for the Internet 1288 Protocol Version 6 (IPv6) Specification", STD 89, 1289 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1290 . 1292 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 1293 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 1294 January 2007, . 1296 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 1297 Pignataro, "The Generalized TTL Security Mechanism 1298 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 1299 . 1301 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1302 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1303 . 1305 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1306 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1307 June 2009, . 1309 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1310 and D. McPherson, "Dissemination of Flow Specification 1311 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1312 . 1314 [RFC5634] Fairhurst, G. and A. Sathiaseelan, "Quick-Start for the 1315 Datagram Congestion Control Protocol (DCCP)", RFC 5634, 1316 DOI 10.17487/RFC5634, August 2009, 1317 . 1319 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1320 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1321 . 1323 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1324 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 1325 October 2010, . 1327 [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1328 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1329 RFC 5973, DOI 10.17487/RFC5973, October 2010, 1330 . 1332 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 1333 Signaling Layer Protocol (NSLP) for Quality-of-Service 1334 Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, 1335 . 1337 [RFC5981] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 1338 Ed., "Authorization for NSIS Signaling Layer Protocols", 1339 RFC 5981, DOI 10.17487/RFC5981, February 2011, 1340 . 1342 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 1343 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 1344 2011, . 1346 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1347 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1348 2011, . 1350 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1351 "IPv6 Flow Label Specification", RFC 6437, 1352 DOI 10.17487/RFC6437, November 2011, 1353 . 1355 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1356 for Equal Cost Multipath Routing and Link Aggregation in 1357 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1358 . 1360 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 1361 RFC 6633, DOI 10.17487/RFC6633, May 2012, 1362 . 1364 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1365 "Increasing TCP's Initial Window", RFC 6928, 1366 DOI 10.17487/RFC6928, April 2013, 1367 . 1369 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 1370 Technology Adoption and Transition (ITAT)", RFC 7305, 1371 DOI 10.17487/RFC7305, July 2014, 1372 . 1374 [RFC7418] Dawkins, S., Ed., "An IRTF Primer for IETF Participants", 1375 RFC 7418, DOI 10.17487/RFC7418, December 2014, 1376 . 1378 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1379 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1380 March 2017, . 1382 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1383 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1384 May 2017, . 1386 [SAF07] Sarolahti, P., Allman, M., and S. Floyd, "Determining an 1387 appropriate sending rate over an underutilized network 1388 path", Computer Networking Volume 51, Number 7, May 2007. 1390 [Sch11] Scharf, M., "Fast Startup Internet Congestion Control for 1391 Broadband Interactive Applications", Ph.D. Thesis, 1392 University of Stuttgart, April 2011. 1394 [Shim6-35] 1395 Meyer, D., Huston, G., Schiller, J., and V. Gill, "IAB 1396 IPv6 Multihoming Panel at NANOG 35", NANOG North American 1397 Network Operator Group, October 2005, 1398 . 1400 [TAPS-WG] "Transport Services Working Group Home Page", n.d., 1401 . 1403 [TRIGTRAN-55] 1404 "Triggers for Transport BOF at IETF 55", July 2003, 1405 . 1407 [TRIGTRAN-56] 1408 "Triggers for Transport BOF at IETF 56", November 2003, 1409 . 1411 Author's Address 1413 Spencer Dawkins (editor) 1414 Wonder Hamster Internetworking 1416 Email: spencerdawkins.ietf@gmail.com