idnits 2.17.1 draft-harper-inband-signalling-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 463. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 390: '... 1. The protocol MUST be carried withi...' RFC 2119 keyword, line 394: '... 2. The protocol MUST be capable of op...' RFC 2119 keyword, line 397: '... 3. The protocol MUST provide a means ...' RFC 2119 keyword, line 401: '... 4. The protocol MUST provide a means ...' RFC 2119 keyword, line 404: '... 5. The protocol MUST provide a means ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6310 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group John Harper 3 Internet-Draft Anagran Inc 4 Patrick McGeer 5 Hewlett Packard Corp 6 January 2007 8 Requirements for In-Band QoS Signalling 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 19th, 2007. 36 Abstract 38 This document describes the raionale and requirements for in-band 39 signalling of Quality of Service (QoS) characteristics for the 40 Internet Protocol (IP) There has been extensive work on QoS for IP, 41 leading to the development of RSVP, NSIS and other protocols. New 42 requirements emerging from the use of IP to carry services such as 43 video and voice are leading in turn to additional requirements for 44 QoS signalling. The authors believe that these can best be met by 45 adding in-band signalling to IP, complementing the existing protocols 46 for QoS signalling. 48 Copyright Notice 49 Copyright (C) The Internet Society. (2007) 51 1. Introduction 53 The TCP/IP protocol suite was originally designed to support purely 54 best-effort data transmission. As congestion started to become a 55 practical problem, mechanisms were added in TCP to allow end systems 56 to react to congestion and to slow down their transmission 57 accordingly. As quality-sensitive applications began to use TCP/IP, 58 work was undertaken to provide for explicit signalling of QoS 59 requirements, resulting initially in RSVP and later in the start of 60 work on NSIS. RSVP and NSIS are both out-of-band signalling 61 protocols, i.e. the signalling flow takes place over a separate 62 packet flow from the information itself. This works well for some 63 classes of applications, such as the establishment of MPLS tunnels 64 for traffic engineering. 66 The TCP/IP protocol suite is increasingly becoming a universal way to 67 move all kinds of information, including those which have previously 68 relied on dedicated analog or digital circuits, such as voice and 69 video. Some of these have more stringent quality requirements than 70 traditional data traffic, requiring a certain minimum bandwidth and 71 maximum delay variance ("jitter") if the user requirements are to be 72 met. Where large numbers of sessions are involved, for example when 73 providing domestic video services, it is difficult to design 74 equipment such that out-of-band protocols can operate quickly enough. 76 TCP´s ability to react to network congestion, and hence adapt its 77 transmission speed to available capacity, depends heavily on the fact 78 that in traditional data networks, packet loss due to transmission 79 errors is a rare event. It also depends on gradual ramp-up to the 80 available capacity, using the "slow-start" technique. These have both 81 been appropriate for the networks which have predominated until 82 recently, where links are provided by optical or electrical means and 83 where the bandwidth required for an individual TCP connection is no 84 more than a few megabits/second. Current technological trends mean 85 that these assumptions do not necessarily apply any longer. Wireless 86 links are becoming commonplace. These have significant error rates, 87 enough to force TCP into low throughput as it incorrectly reacts to 88 lost packets as though they signal congestion. This is particularly 89 serious when the wireless links have high bandwidth, for example in 90 the case of third and fourth generation mobile systems. 92 Bandwidths available to all classes of user are steadily increasing. 93 For example, domestic users in many parts of Asia now have access 94 rates of 45 or 100 Mbit/sec. Commercial and industrial users are now 95 often connected via links having instantaneous bandwidth of 100 96 Mbit/sec or 1 Gbit/sec. TCP slow-start and TCP´s reaction to 97 occasional packet loss mean that practical achievement of these kinds 98 of bandwidths will often not occur. In order to achieve these 99 bandwidths, especially in the presence of errors, explicit signalling 100 of available bandwidth in the network is required. 102 For all the above reasons, it is considered desirable to add means to 103 the TCP/IP protocol suite to allow efficient signalling of QoS 104 requirements and availability in close association with the IP 105 traffic itself. While this could in principle be done using out-of- 106 band signalling, the scale of the signalling to be undertaken makes 107 it harder to achieve the necessary responsiveness and performance by 108 this means. Additionally, in high-speed routers and switches, 109 signalling at the envisaged scale must be performed in hardware if 110 the performance is to be achieved. This is simpler if an in-band 111 signalling protocol, with a simple and well-structured format, is 112 used. 114 In the remainder of this draft, we present specific rationale for an 115 in-band QoS signalling protocol, and set out the requirements that 116 must be achieved by the architecture and the corresponding protocol. 118 2. QoS Service Goals 120 2.1 Definition of a Flow 122 In the remainder of this document, the term "flow" is used to mean a 123 sequence of packets belonging to the same host-to-host association, 124 typically either a TCP connection, or where a connectionless 125 transport protocol is in use, a sequence of packets corresponding to 126 the same information stream. In an IPv4 network, a flow is generally 127 considered be a sequence of packets sharing the same source and 128 destination IP addresses, transport protocol and transport protocol 129 source and destination ports (if applicable). In an IPv6 network, a 130 flow is a sequence of packets sharing the same source and destination 131 IP addresses and the same Flow Identifier. The presence of the Flow 132 Identifier in IPv6 means that inspection of transport layer port 133 information is not required in order to determine flow membership. 134 However this does depend upon the consistent use of the Flow 135 Identifier. It is also possible to make explicit use of transport 136 layer port information, if IPv6 payload encryption is not in use. 138 2.2 Types of Flow 140 IP applications can be broadly divided into two categories, when 141 considering QoS: 143 - those that will use whatever bandwidth is available, adjusting 144 their rate accordingly. Such applications normally run over TCP (or 145 other connection-mode transport protocols such as SCTP). Flows having 146 this characteristic are called AR ("Available Rate") flows. Because 147 available capacity in the network is constantly changing, AR flows 148 need to be able to receive periodic updates about the current 149 capacity, so they can change their behavior. 151 - those that have a predetermined bandwidth requirement, which may be 152 fixed or may vary. If the required bandwidth is not available then 153 the service as seen by the user deteriorates and may become 154 completely unusable. Applications such as voice and streaming video 155 fall into this class. These applications can in turn be divided into 156 three categories, as described below. 158 GR - Guaranteed Rate service specifies a reserved rate and is 159 intended for those cases where bandwidth must be reserved by the 160 network, even when it is unused. The network should not oversubscribe 161 the allocations for any given preemption level. It requires explicit 162 signalling of reservation and release, which are only used with the 163 Guaranteed Rate service. 165 MR - Maximum Rate service has no fixed reservation. It specifies the 166 maximum rate the flow might use and makes every attempt to assure no 167 packet loss if the flow remains under this rate. The flow may be 168 variable in rate, not to exceed the specified maximum rate. Flows may 169 be policed or shaped to ensure that this rate is not exceeded. Flows 170 may be dropped if it is known to be impossible to deliver the stated 171 maximum rate, for example dut to congestion. Unlike guaranteed rate 172 traffic, the bandwidth is available subject to traffic statistics; it 173 is not an absolute guarantee. The flow is dropped if no traffic is 174 seen for a preset period and so no explicit release is required. The 175 service can be used for individual video, voice or streaming media 176 flows where very low loss and/or low delay jitter is required. 178 VR - Variable Rate service, where part of the rate is guaranteed and 179 part is determined by network capacity (available rate). This is 180 typically the case, when streaming media cannot function below a base 181 rate but can take advantage of additional capacity if it is 182 available. This capability is signaled as a maximum rate plus an 183 available rate. Traffic up to the maximum rate plus the available 184 rate will be supported. The available rate may be changed from time 185 to time as the network capacity changes. 187 2.3 Other QoS Goals 189 In addition to the bandwidth-related QoS flow attributes described in 190 section 2.1, there are other requirements associated with the service 191 applied to a particular flow. 193 PP - Preemption Priority indicates which flows should survive when 194 the network capacity is insufficient to support the required quality 195 of all the flows. It is necessary to support civilian emergency 196 services, military services, and will also have applications in other 197 aspects of networking. 199 BT - Burst Tolerance specifies how much the actual rate may exceed 200 the stated rate before policing is enforced. This not only applies to 201 rate bursts the user may introduce at the source but is necessary to 202 allow for bunching the network routers may introduce. 204 DP - Delay Priority permits explicit signalling of the relative 205 importance of flows with respect to limiting delay variation. 207 CH - Charge Direction specifies who is paying for this flow, the 208 sender or the receiver. This allows IP to provide 800 type services 209 like the PSTN and allows for peering between networks of different 210 sizes with fair charging. 212 3. Problems with Current QoS Signalling Techniques 214 3.1 Diffserv and its Limitations 216 Diffserv provides a Class of Service (COS) marking in 6 bits in the 217 IP header. Only a subset of the 64 possible values has a globally 218 recognised definition. Due to the low range of values, there is no 219 way to have globally unified definitions of the meaning of the 220 codepoints. Also there are too few bits to specify explicitly a rate 221 for either guaranteed rate flows or for available rate feedback. This 222 limits the utility of Diffserv to a few delay categories and some 223 local link-by-link agreements. As we move into video and streaming 224 media as well as improving TCP performance, Diffserv provides 225 insufficient flexibility. 227 3.2 IntServ and its Limitations 229 The current proposals for IntServ type QoS support (as opposed to CoS 230 support via Diffserv) revolve around a round trip call setup request 231 using complex protocols like RSVP. These protocols require more 232 processing than can be done in hardware and are thus obliged to 233 operate in relativey slow software processes. This limits the total 234 end-to-end call processing that can be made to either very large 235 flows or to composite (VPN) flows since processor speeds are 236 insufficient for processing all IP flows. 238 What is desirable is a protocol that permits the router to process 239 QoS requests for each individual flow, including parameters such as 240 bandwidth, delay priority, preemption priority, burst tolerance, and 241 charging direction. Many common flows like file transfers may not 242 require all this information. However, increasingly flows are 243 becoming voice, video, gaming, or streaming media where such 244 requirements do apply. 246 Also, as the IP becomes the predominant protocol for the provision of 247 voice and emergency communications, the need for call rejection and 248 preemption priority become important and may even be life and death 249 issues. These capabilities are therefore required as part of the IP 250 protocol, for both TCP and UDP. 252 3.3 Issues Regarding TCP 254 TCP slow-start has worked well over the past 20 years when the 255 individual flows were generally in the kilobits/second. However, as 256 wideband corporate access and broadband residential access have 257 proliferated, the desired flow rate has increased into the 258 megabits/second up to several gigabits/second. TCP was not designed 259 for these rates at any significant distance. 261 TCP depends on detecting packet loss to adjust its rate; any packet 262 loss at high rates over long distances creates a major slow down of 263 the flow. Even at normal cross-country distances, maximum TCP 264 throughput is limited to megabits/second rather than gigabits/second. 265 The performance of TCP when operating over satellite links is poor 266 enough that TCP "spoofing" devices are frequently used at either end 267 of any satellite link. However, this will not work when the data is 268 encrypted as in IPv6, in IPv4 with IPSEC or in either with encryptors 269 inserted. 271 Another problem with using packet loss as a rate control mechanism is 272 that the typical method of dealing with congestion is to discard 273 random packets, even if the flow in question is not yet up to the 274 speed of other flows. This is usually done using Random Early 275 Detection (RED) or Weighted Random Early Detection (WRED). This 276 procedure slows down the TCP rate so that it does not get up to the 277 maximum network speed as fast as possible. This problem has been 278 magnified as the network speeds have increased such that an average 279 120 K byte web page transfer over a 10 Mbps access line can take many 280 seconds rather than the fraction of a second actually required. 282 The TCP situation is improved by marking packets for congestion, 283 using Explicit Congestion Notification (ECN) before discarding 284 becomes necessary. ECN avoids discarding the packet, but the search 285 for the rate the network can support is still a binary search that 286 leads to significant loss of throughput and does not improve the 287 slow-start problem. Marking packets in this way, also presumes that 288 the network has sufficient storage to signal congestion well before 289 the problem becomes critical. This in turn leads to either additional 290 network delays due to long queue traversals, or exacerbates the 291 existing problem of lower network utilization. 293 When the concept of marking packets is coupled with the feedback of 294 the maximum rate the network could support, it is feasible for the 295 TCP source to avoid slow-start and achieve extremely high-speed 296 throughput. Instead of marking or discarding packets when congestion 297 occurs, the network can inform all TCP sources as soon as possible of 298 the rate that they can operate at safely. As conditions change, 299 additional feedback is required. This concept was simulated and 300 tested extensively in ATM systems. It was found to substantially 301 decrease the time to transfer a web page and significantly decrease 302 the buffering required in the network. 304 3.4 Considerations for Streaming Protocols 306 While many applications use TCP, there are others which do not 307 require the benefits it brings with regard to error recovery, 308 reordering and flow control. Such applications typically use UDP as a 309 connectionless transport protocol. In particular, real-time streaming 310 applications such as video and voice operate in this way. These 311 applications are not, in general, able to adjust their transmission 312 rate in response to the capacity of the network. For example, an 313 uncompressed voice flow using G.711 encoding requires a bandwidth of 314 64 kbit/sec for the voice payload. Similarly, real-time compressed 315 video typically requires a bandwidth in the range 2-6 Mbit/sec, 316 depending on the encoding and the content. A given flow will simply 317 not work if the available bandwidth turns out to be less than this. 318 (There are approaches to dealing with this, for example by switching 319 to a lower-rate codec with lower quality, but they require an 320 additional management layer and also require explicit knowledge of 321 the available bandwidth, unlike TCP which adjusts continuously). 322 Hence, if the total bandwidth available is enough to support say 100 323 such flows, and another one presents itself, it is better to block 324 the new flow, than to accept it and downgrade the quality of the 325 service provided to all 101 users. The capability to control 326 admission in this way is referred to as Call Admission Control (CAC). 328 RSVP was designed to perform admission control, but the limited 329 practical experience with RSVP as a generic admission control 330 protocol shows that it does not scale to handle very large numbers of 331 individual flows. It is adequate for handling aggregated flows (for 332 example, VPN connections through a service provider network) but not 333 for handling individual flows. 335 3.5 Protocol Complexity and Hardware Processing 336 A high-speed router, operating at link speeds of 1 Gbit/sec or 337 higher, will handle a very large number of flows and flow-setup 338 operations. If many of those flows include explicit QoS signalling, 339 the handling of this signalling needs to be performed at very high 340 speed. In a practical implementation, this means that it must take 341 place in the data plane and be performed by the same system elements 342 that perform packet forwarding operations, i.e. hardware logic 343 implemented in an ASIC or programmable logic, or in code executed in 344 special-purpose Network Processors (NPUs). This logic or code is 345 highly optimised and is not amenable to the kinds of operations 346 typically performed in general-purpose CPUs by software. In 347 considerations of protocol design, this means that the QoS signalling 348 protocol should have a simple fixed structure. The very flexible 349 structures used in existing QoS signalling protocols, such as type- 350 length-value encoding supporting a multiplicity of optional features, 351 cannot be implemented in hardware or NPU-based systems. 353 4. Implications for Signalling Protocol Design 355 4.1 Benefits of In-band Signalling 357 Signalling of QoS requirements can in principle be effected using 358 either out-of-band signalling, like RSVP, or in-band signalling. To 359 date, there has been no implementation of RSVP which can perform 360 large numbers of flow-setup operations at a high rate, which suggests 361 that such an implementation would be difficult. 363 In-band signalling, using a simple protocol, has the following 364 benefits in addition to those described above. 366 1. In-band signalling is guaranteed to follow the same path through 367 the network as the flow on whose behalf it is signalling. This is 368 very difficult to achieve for an out-of-band protocol, taking into 369 account realities of network design such as equal cost multipath 370 routes. 372 2. Since in-band signalling is carried along with the payload of the 373 flow, it is unaffected by en-route changes to network addressing such 374 as NAT. In principle an out-of-band protocol can deal with this, but 375 it is a complex problem which has been under study in the IETF 376 (MidCom) for several years. 378 3. Accurate detection of congestion in the network requires frequent 379 updates about the available capacity. A simple protocol carried along 380 with the payload can provide this through an efficient data-plane 381 implementation. Given the difficulty of scaling current out-of-band 382 protocols to handle large numbers of flows, it would be even harder 383 to provide frequent real-time updates about the state of the network. 385 4.2 Requirements for an In-band Signalling Protocol 387 From the above considerations, the following requirements apply to an 388 in-band protocol for QoS signalling. 390 1. The protocol MUST be carried within packets which form part of the 391 flow for which QoS information is being conveyed. This is inherent in 392 the nature of an in-band protocol. 394 2. The protocol MUST be capable of operating with both IPv4 and IPv6, 395 although variations may be required to make this possible. 397 3. The protocol MUST provide a means for an AR flow to signal its 398 requested bandwidth, and to receive information from the network 399 about the bandwidth actually available. 401 4. The protocol MUST provide a means for a GR, MR or VR flow to 402 signal its requested bandwidth. 404 5. The protocol MUST provide a means to signal other QoS information, 405 specifically Burst Tolerance, Preemption Priority, Delay Priority, 406 and Charging Information. 408 6. The protocol MUST provide a means for a flow to periodically 409 determine the currently available bandwidth in the network. 411 7. The protocol MUST provide a means for GR flows to perform explicit 412 bandwidth reservation and release, in a confirmed and reliable way. 414 8. The protocol MUST define an encoding which lends itself readily to 415 implementation in hardware, programmable logic or high-performance 416 dedicated network processors. 418 5. Security Considerations 420 A QoS signalling protocol is capable of reserving network resources, 421 or of providing information to a host which will lead it to make use 422 of network resources. The protocol which is defined in support of the 423 requirements decsribed in this document needs to address how such 424 resources can be protected in an appropriate fashion, either through 425 elements of the protocol itself, or through associated configuration 426 of the systems which implement it, or both. 428 6. Editors´s Addresses 430 John Harper 431 Anagran Inc 432 2055 Woodside Road 433 Redwood City, CA 94065 434 USA 436 Phone: +1 650 587 8276 437 EMail: john@anagran.com 439 Patrick McGeer 440 Hewlett-PAckard Laboratories 441 1501 Page Mill Road 442 Palo Alto, CA 94304 443 USA 445 Email: rick.mcgeer@hp.com 447 This Internet-Draft will expire on July 19th, 2007. 449 7. Full copyright statement 451 Copyright (C) The Internet Society (2007). 453 This document is subject to the rights, licenses and restrictions 454 contained in BCP 78, and except as set forth therein, the authors 455 retain all their rights. 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 460 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 461 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 462 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.