idnits 2.17.1
draft-dawkins-panrg-what-not-to-do-01.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 18, 2018) is 2110 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 2581
(Obsoleted by RFC 5681)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PANRG S. Dawkins, Ed.
3 Internet-Draft Huawei Technologies
4 Intended status: Informational June 18, 2018
5 Expires: December 20, 2018
7 Path Aware Networking: A Bestiary of Roads Not Taken
8 draft-dawkins-panrg-what-not-to-do-01
10 Abstract
12 At the first meeting of the proposed Path Aware Networking Research
13 Group, Oliver Bonaventure led a discussion of our mostly-unsuccessful
14 attempts to exploit Path Awareness to achieve a variety of goals,
15 over the past decade. At the end of that discussion, the research
16 group agreed to catalog and analyze these ideas, to extract insights
17 and lessons for path-aware networking 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 December 20, 2018.
38 Copyright Notice
40 Copyright (c) 2018 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. About this Document . . . . . . . . . . . . . . . . . . . 3
54 1.2. A Note for Contributors (Consider removing after
55 approval) . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.3. A Note for the Editor (Remove after taking these actions) 3
57 1.4. Architectural Guidance . . . . . . . . . . . . . . . . . 3
58 2. Summary of Lessons Learned . . . . . . . . . . . . . . . . . 4
59 3. Template for Contributions . . . . . . . . . . . . . . . . . 4
60 4. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 5
61 4.1. Integrated Services (IntServ) . . . . . . . . . . . . . . 5
62 4.1.1. Reasons for Non-deployment . . . . . . . . . . . . . 6
63 4.1.2. Lessons Learned. . . . . . . . . . . . . . . . . . . 6
64 4.2. Quick-Start TCP . . . . . . . . . . . . . . . . . . . . . 6
65 4.2.1. Reasons for Non-deployment . . . . . . . . . . . . . 7
66 4.2.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 8
67 4.3. Triggers for Transport (TRIGTRAN) . . . . . . . . . . . . 8
68 4.3.1. Reasons for Non-deployment . . . . . . . . . . . . . 9
69 4.3.2. Lessons Learned. . . . . . . . . . . . . . . . . . . 9
70 4.4. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
71 4.4.1. Reasons for Non-deployment . . . . . . . . . . . . . 10
72 4.4.2. Lessons Learned . . . . . . . . . . . . . . . . . . . 11
73 4.5. Next Steps in Signaling (NSIS) . . . . . . . . . . . . . 11
74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
77 8. Informative References . . . . . . . . . . . . . . . . . . . 12
78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
80 1. Introduction
82 At IETF 99, the proposed Path Aware Networking Research Group [PANRG]
83 held its first meeting [PANRG-99], and the first presentation in that
84 session was "A Decade of Path Awareness" [PATH-Decade]. At the end
85 of this discussion, two things were abundantly clear.
87 o The Internet community has accumulated considerable experience
88 with many Path Awareness ideas over a long period of time, and
90 o Although some Path Awareness ideas have been successfully deployed
91 (for example, Differentiated Services, or DiffServ [RFC2475]),
92 most of these ideas haven't seen widespread adoption. The reasons
93 for this non-adoption are many, and are worthy of study.
95 The meta-lessons from this experience are
96 o Path Aware Networking is more Research than Engineering, so
97 establishing an IRTF Research Group for Path Aware Networking is
98 the right thing to do [RFC7418], and
100 o Cataloging and analyzing our experience to learn the reasons for
101 non-adoption is a great first step for the proposed Research
102 Group.
104 This document contains that catalog and analysis.
106 1.1. About this Document
108 This document is not intended to include every idea about Path Aware
109 Networking that we can find. Instead, we include enough ideas to
110 provide background for new lessons to guide researchers in their
111 work, in order to add those lessons to Section 2.
113 1.2. A Note for Contributors (Consider removing after approval)
115 There is no shame to having your idea included in this document.
116 When these proposals were made, we were trying to engineer something
117 that was research. The document editor started with a subsection on
118 his own idea. The only shame is not learning from experience, and
119 not sharing that experience with other networking researchers and
120 engineers.
122 This document is being built collaboratively. To contribute your
123 experience, please send a Github pull request to
124 https://github.com/panrg/draft-dawkins-panrg-what-not-to-do.
126 Discussion of specific contributed experiences and this document in
127 general should take place on the PANRG mailing list.
129 1.3. A Note for the Editor (Remove after taking these actions)
131 The to-do list for upcoming revisions includes
133 o Rearrange the Summary of Lessons Learned so that it flows (the
134 current revision is more or less in the order of contributions).
136 o Tag the Lessons Learned so that they are tied to one or more
137 specific contributions.
139 1.4. Architectural Guidance
141 As background for understanding the Lessons Learned contained in this
142 document, the reader is encouraged to become familiar with the
143 Internet Architecture Board's documents on "What Makes for a
144 Successful Protocol?" [RFC5218] and "Planning for Protocol Adoption
145 and Subsequent Transitions" [RFC8170].
147 Although these two documents do not specifically target path-aware
148 networking protocols, they are helpful resources on successful
149 protocol adoption and deployment.
151 2. Summary of Lessons Learned
153 This section summarizes the Lessons Learned from the contributed
154 sections in Section 4.
156 o The benefit of Path Awareness has to be great enough to overcome
157 entropy for already-deployed devices. The colloquial American
158 English expression, "If it ain't broke, don't fix it" is in full
159 flower on today's Internet.
161 o If intermediate devices along the path can't be trusted, it's
162 difficult to rely on intermediate devices to drive changes to
163 endpoint behaviors.
165 o If operators can't charge for a Path Aware technology in order to
166 recover the costs of deploying it, the benefits must be really
167 significant.
169 o Impact of a Path Aware technology on operational practices can
170 prevent deployment of promising technology.
172 o Per-connection state in intermediate devices is an impediment to
173 adoption and deployment.
175 o Providing benefits for early adopters is key - if everyone must
176 deploy a technology in order for the topology to provide benefits,
177 or even to work at all, the technology is unlikely to be adopted.
179 o The Internet is a distributed system, so the more a technology
180 relies on information propagated from distant hosts and routers,
181 the less likely that information is to be accurate.
183 o Transport protocol technologies may require information from
184 applications, in order to work effectively, but applications may
185 not know the information they need to provide.
187 3. Template for Contributions
189 There are many things that could be said about the Path Aware
190 networking technologies that have been developed. For the purposes
191 of this document, contributors are requested to provide
192 o the name of a technology, including an abbreviation if one was
193 used
195 o if available, a long-term pointer to the best reference describing
196 the technology
198 o a short description of the problem the technology was intended to
199 solve
201 o a short description of the reasons why the technology wasn't
202 adopted
204 o a short statement of the lessons that researchers can learn from
205 our experience with this technology.
207 4. Contributions
209 The editor has added some suggested subsections as a starting place,
210 but others are solicited and welcome.
212 4.1. Integrated Services (IntServ)
214 The suggested references for IntServ are:
216 o RFC 1633 Integrated Services in the Internet Architecture: an
217 Overview [RFC1633]
219 o RFC 2211 Specification of the Controlled-Load Network Element
220 Service [RFC2211]
222 o RFC 2212 Specification of Guaranteed Quality of Service [RFC2212]
224 o RFC 2215 General Characterization Parameters for Integrated
225 Service Network Elements [RFC2215]
227 o RFC 2205 Resource ReSerVation Protocol (RSVP) [RFC2205]
229 In 1994, when the IntServ architecture document [RFC1633] was
230 published, real-time traffic was first appearing on the Internet. At
231 that time, bandwidth was a scarce commodity. Internet Service
232 Providers built networks over DS3 (45 Mbps) infrastructure, and sub-
233 rate (< 1 Mpbs) access was common. Therefore, the IETF anticipated a
234 need for a fine-grained QoS mechanism.
236 In the IntServ architecture, some applications require service
237 guarantees. Therefore, those applications use the Resource
238 Reservation Protocol (RSVP) [RFC2205] to signal bandwidth
239 reservations across the network. Every router in the network
240 maintains per-flow state in order to a) perform call admission
241 control and b) deliver guaranteed service.
243 Applications use Flow Specification (Flow Specs) [RFC2210] to
244 describe the traffic that they emit. RSVP reserves bandwidth for
245 traffic on a per Flow Spec basis.
247 4.1.1. Reasons for Non-deployment
249 IntServ was never widely deployed because of its cost. The following
250 factors contributed to cost:
252 o IntServ must be deployed on every router within the QoS domain
254 o IntServ maintained per flow state
256 As IntServ was being discussed, the following occurred:
258 o It became more cost effective to solve the QoS problem by adding
259 bandwidth. Between 1994 and 2000, Internet Service Providers
260 upgraded their infrastructures from DS3 ( 45 Mbps ) to OC-48 ( 2.4
261 Gbps )
263 o DiffServ [RFC2475] offered a more cost-effective, albeit less
264 fine-grained, solution to the QoS problem.
266 4.1.2. Lessons Learned.
268 The following lessons were learned:
270 o Any mechanism that requires a router to maintain state is not
271 likely to succeed.
273 o Any mechanism that requires an operator to upgrade all of its
274 routers is not likely to succeed.
276 IntServ was never widely deployed. However, the technology that it
277 produced was deployed for reasons other than bandwidth management.
278 RSVP is widely deployed as an MPLS signaling mechanism. BGP uses
279 Flow Specs to distribute firewall filters.
281 4.2. Quick-Start TCP
283 Quick-Start [RFC4782] is an experimental TCP extension that leverages
284 support from the routers on the path to determine an allowed sending
285 rate, either at the start of data transfers or after idle periods.
286 In these cases, a TCP sender cannot easily determine an appropriate
287 sending rate, given the lack of information about the path. The
288 default TCP congestion control therefore uses the time-consuming
289 slow-start algorithm. With Quick-Start, connections are allowed to
290 use higher sending rates if there is significant unused bandwidth
291 along the path, and if the sender and all of the routers along the
292 path approve the request. By examining Time To Live (TTL) fields, a
293 sender can determine if all routers have approved the Quick-Start
294 request. The protocol also includes a nonce that provides protection
295 against cheating routers and receivers. If the Quick-Start request
296 is explicitly approved by all routers along the path, the TCP host
297 can send at up to the approved rate; otherwise TCP would use the
298 default congestion control. Quick-Start requires modifications in
299 the involved end-systems as well in routers. Due to the resulting
300 deployment challenges, Quick-Start has been being proposed in
301 [RFC4782] for controlled environments such as intranets only.
303 The Quick-Start protocol is a lightweight, coarse-grained, in-band,
304 network-assisted fast startup mechanism. The benefits are studied by
305 simulation in a research paper [SAF07] that complements the protocol
306 specification. The study confirms that Quick-Start can significantly
307 speed up mid-sized data transfers. That paper also presents router
308 algorithms that do not require keeping per-flow state. Later studies
309 [Sch11] comprehensively analyzes Quick-Start with a full Linux
310 implementation and with a router fast path prototype using a network
311 processor. In both cases, Quick-Start could be implemented with
312 limited additional complexity.
314 4.2.1. Reasons for Non-deployment
316 However, the experiments with Quick-Start in [Sch11] reveal several
317 challenges:
319 o Having information from the routers along the path can reduce the
320 risk of congestion, but it cannot avoid it entirely. Determining
321 whether there is unused capacity is not trivial in actual router
322 and host implementations. Data about available bandwidth visible
323 at the IP layer may be imprecise, and due to the propagation
324 delay, information can already be outdated when it reaches the
325 sender. There is a trade-off between the speedup of data
326 transfers and the risk of congestion even with Quick-Start.
328 o For scalable router fast path implementation, it is important to
329 enable parallel processing of packets, as this is a widely used
330 method e.g. in network processors. One challenge is
331 synchronization of information between different packets, which
332 should be avoided as much as possible.
334 o Only selected applications can benefit from Quick-Start. For
335 achieving an overall benefit, it is important that senders avoid
336 sending unnecessary Quick-Start requests, e.g. for connections
337 that will only send a small amount of data. This typically
338 requires application-internal knowledge. It is a mostly unsolved
339 question how a sender can indeed determine the data rate that
340 Quick-Start shall request for.
342 After completion of the Quick-Start specification, there have been
343 large-scale experiments with an initial window of up to 10 MSS
344 [RFC6928]. This alternative "IW10" approach can also ramp up data
345 transfers faster than the standard TCP congestion control, but it
346 only requires sender-side TCP modifications. As a result, this
347 approach can be easier and incrementally deployed in the Internet.
348 While theoretically Quick-Start can outperform "IW10", the absolute
349 improvement of data transfer times is rather small in many cases.
350 After publication of [RFC6928], most modern TCP stacks have increased
351 their default initial window. There is no known deployment of Quick-
352 Start TCP.
354 4.2.2. Lessons Learned
356 There are some lessons learned from Quick-Start. Despite being a
357 very light-weight protocol, Quick-Start suffers from poor incremental
358 deployment properties, both regarding the required modifications in
359 network infrastructure as well as its interactions with applications.
360 Except for corner cases, congestion control can be quite efficiently
361 performed end-to-end in the Internet, and in modern TCP stacks there
362 is not much room for significant improvement by additional network
363 support.
365 4.3. Triggers for Transport (TRIGTRAN)
367 TCP [RFC0793] has a well-known weakness - the end-to-end flow control
368 mechanism has only a single signal, the loss of a segment, and semi-
369 modern TCPs (since the late 1980s) have interpreted the loss of a
370 segment as evidence that the path between two endpoints has become
371 congested enough to exhaust buffers on intermediate hops, so that the
372 TCP sender should "back off" - reduce its sending rate until it knows
373 that its segments are now being delivered without loss [RFC2581].
374 More modern TCPs have added a growing array of strategies about how
375 to establish the sending rate [RFC5681], but when a path is no longer
376 operational, TCPs can wait many seconds before retrying a segment,
377 even if the path becomes operational while the sender is waiting to
378 retry.
380 The thinking in Triggers for Transport was that if a path completely
381 stopped working because its first-hop link was "down", that somehow
382 TCP could be signaled when the first-hop link returned to service,
383 and the sending TCP could retry immediately, without waiting for a
384 full Retransmission Time Out (RTO).
386 4.3.1. Reasons for Non-deployment
388 Two TRIGTRAN BOFs were held, at IETF 55 [TRIGTRAN-55] and IETF 56
389 [TRIGTRAN-56], but this work was not chartered, and there was no
390 interest in deploying TRIGTRAN unless it was chartered in the IETF.
392 4.3.2. Lessons Learned.
394 The reasons why this work was not chartered provide several useful
395 lessons for researchers.
397 o TRIGTRAN triggers are only provided when the first-hop link is
398 "down", so TRIGTRAN triggers couldn't replace normal TCP
399 retransmission behavior if the path failed because some link
400 further along the network path was "down". So TRIGTRAN triggers
401 added complexity to an already complex TCP state machine, and
402 didn't allow any existing complexity to be removed.
404 o The state of the art in the early 2000s was that TRIGTRAN triggers
405 were assumed to be unauthenticated, so they couldn't be trusted to
406 tell a sender to "speed up", only to "slow down". This reduced
407 the potential benefit to implementers.
409 o intermediate forwarding devices required modification to provide
410 TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN
411 triggers, so there was no way to recover the cost of modifying,
412 testing, and deploying updated intermediate devices.
414 4.4. Shim6
416 The IPv6 routing architecture [RFC1887] assumed that most sites on
417 the Internet would be identified by Provider Assigned IPv6 prefixes,
418 so that Default-Free Zone routers only contained routes to other
419 providers, resulting in a very small routing table.
421 For a single-homed site, this could work well. A multi-homed site
422 with only one upstream provider could also work well, although BGP
423 multihoming from a single upstream provider was often a premium
424 service (costing more than twice as much as two single-homed sites),
425 and if the single upstream provider went out of service, all of the
426 multi-homed paths could fail simultaneously.
428 IPv4 sites often multihomed by obtaining Provider Independent
429 prefixes, and advertising these prefixes through multiple upstream
430 providers. With the assumption that any multihomed IPv4 site would
431 also multihome in IPv6, it seemed likely that IPv6 routing would be
432 subject to the same pressures to announce Provider Independent
433 prefixes, resulting in a global IPv6 routing table that exhibited the
434 same problems as the global IPv4 routing table. During the early
435 2000s, work began on a protocol that would provide the same benefits
436 for multihomed IPv6 sites without requiring sites to advertise
437 Provider Independent prefixes into the global routing table.
439 This protocol, called Shim6, allowed two endpoints to exchange
440 multiple addresses ("Locators") that all mapped to the same endpoint
441 ("Identity"). After an endpoint learned multiple Locators for the
442 other endpoint, it could send to any of those Locators with the
443 expectation that those packets would all be delivered to the endpoint
444 with the same Identity. Shim6 was an example of an "Identity/Locator
445 Split" protocol.
447 Shim6, as defined in [RFC5533] and related RFCs, provided a workable
448 solution for IPv6 multihoming using Provider Assigned prefixes,
449 including capability discovery and negotiation, and allowing end-to-
450 end application communication to continue even in the face of path
451 failure, because applications don't see Locator failures, and
452 continue to communicate with the same Identity using a different
453 Locator.
455 4.4.1. Reasons for Non-deployment
457 Note that the problem being addressed was "site multihoming", but
458 Shim6 was providing "host multihoming". That meant that the decision
459 about what path would be used was under host control, not under
460 router control.
462 Although more work could have been done to provide a better technical
463 solution, the biggest impediments to Shim6 deployment were
464 operational and business considerations. These impediments were
465 discussed at multiple network operator group meetings, including
466 [Shim6-35] at [NANOG-35].
468 The technology issues centered around scaling concerns that Shim6
469 relied on the host to track all the TCP connections and the file
470 descriptions with associated HTTP state, while also tracking
471 Identity/Locator mappings in the kernel, and tracking failures to
472 recognize that a backup path has failed.
474 The operator issues centered around concerns that operators were
475 performing traffic engineering, but would have no visibility or
476 control over hosts when they chose to begin using another path, and
477 relying on hosts to engineer traffic exposed their networks to
478 oscillation based on feedback loops, as hosts move from path to path.
480 At a minimum, traffic engineering policies must be pushed down to
481 individual hosts. In addition, the usual concerns about firewalls
482 that expected to find a transport-level protocol header in the IP
483 payload, and won't be able to perform firewalling functions because
484 its processing logic would have to look past the Identity header.
486 The business issues centered removing or reducing the ability to sell
487 BGP multihoming service, which is often more expensive than single-
488 homed connectivity.
490 4.4.2. Lessons Learned
492 It is extremely important to take operational concerns into account
493 when a path-aware protocol is making decisions about path selection
494 that may conflict with existing operational practices and business
495 considerations.
497 We also note that some path-aware networking ideas recycle. Although
498 Shim6 did not achieve significant deployment, the IETF chartered a
499 working group to specify "Multipath TCP" [MP-TCP] in 2009, and
500 Multipath TCP allows TCP applications to control path selection, with
501 many of the same advantages and disadvantages of Shim6.
503 4.5. Next Steps in Signaling (NSIS)
505 Write-up of Next Steps in Signaling (NSIS) [RFC5974]
507 Your description could be here.
509 5. Security Considerations
511 This document describes ideas that were not adopted and widely
512 deployed on the Internet, so it doesn't affect the security of the
513 Internet.
515 If this document meets its goals, we may develop new ideas for Path
516 Aware Networking that would affect the security of the Internet, but
517 security considerations for those ideas will be described in the
518 corresponding RFCs that propose them.
520 6. IANA Considerations
522 This document makes no requests of IANA.
524 7. Acknowledgements
526 The section on IntServ was provided by Ron Bonica.
528 The section on Quick-Start TCP was provided by Michael Scharf.
530 The section on Shim6 builds on input provided by Erik Nordmark, with
531 background added by Spencer Dawkins.
533 The section on Triggers for Transport (TRIGTRAN) was provided by
534 Spencer Dawkins.
536 Review comments were provided by (your name could be here).
538 8. Informative References
540 [MP-TCP] "Multipath TCP Working Group Home Page", n.d.,
541 .
543 [NANOG-35]
544 "North American Network Operators Group NANOG-35 Agenda",
545 October 2005,
546 .
548 [PANRG] "Path Aware Networking Research Group (Home Page)", n.d.,
549 .
551 [PANRG-99]
552 "Path Aware Networking Research Group - IETF-99", July
553 2017,
554 .
556 [PATH-Decade]
557 Bonaventure, O., "A Decade of Path Awareness", July 2017,
558 .
561 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
562 RFC 793, DOI 10.17487/RFC0793, September 1981,
563 .
565 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
566 Services in the Internet Architecture: an Overview",
567 RFC 1633, DOI 10.17487/RFC1633, June 1994,
568 .
570 [RFC1887] Rekhter, Y., Ed. and T. Li, Ed., "An Architecture for IPv6
571 Unicast Address Allocation", RFC 1887,
572 DOI 10.17487/RFC1887, December 1995,
573 .
575 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
576 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
577 Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
578 September 1997, .
580 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
581 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997,
582 .
584 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
585 Network Element Service", RFC 2211, DOI 10.17487/RFC2211,
586 September 1997, .
588 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
589 of Guaranteed Quality of Service", RFC 2212,
590 DOI 10.17487/RFC2212, September 1997,
591 .
593 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
594 Parameters for Integrated Service Network Elements",
595 RFC 2215, DOI 10.17487/RFC2215, September 1997,
596 .
598 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
599 and W. Weiss, "An Architecture for Differentiated
600 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
601 .
603 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
604 Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
605 .
607 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
608 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
609 January 2007, .
611 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
612 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
613 .
615 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
616 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
617 June 2009, .
619 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
620 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
621 .
623 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
624 Signaling Layer Protocol (NSLP) for Quality-of-Service
625 Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010,
626 .
628 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
629 "Increasing TCP's Initial Window", RFC 6928,
630 DOI 10.17487/RFC6928, April 2013,
631 .
633 [RFC7418] Dawkins, S., Ed., "An IRTF Primer for IETF Participants",
634 RFC 7418, DOI 10.17487/RFC7418, December 2014,
635 .
637 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
638 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
639 May 2017, .
641 [SAF07] Sarolahti, P., Allman, M., and S. Floyd, "Determining an
642 appropriate sending rate over an underutilized network
643 path", Computer Networking Volume 51, Number 7, May 2007.
645 [Sch11] Scharf, M., "Fast Startup Internet Congestion Control for
646 Broadband Interactive Applications", Ph.D. Thesis,
647 University of Stuttgart, April 2011.
649 [Shim6-35]
650 Meyer, D., Huston, G., Schiller, J., and V. Gill, "IAB
651 IPv6 Multihoming Panel at NANOG 35", NANOG North American
652 Network Operator Group, October 2005,
653 .
655 [TRIGTRAN-55]
656 "Triggers for Transport BOF at IETF 55", July 2003,
657 .
659 [TRIGTRAN-56]
660 "Triggers for Transport BOF at IETF 56", November 2003,
661 .
663 Author's Address
665 Spencer Dawkins (editor)
666 Huawei Technologies
668 Email: spencerdawkins.ietf@gmail.com