idnits 2.17.1 draft-iab-qos-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 59 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 530 has weird spacing: '...e field as th...' -- 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 (June 2000) is 8716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board G.Huston 2 Internet Draft Telstra 3 Document: draft-iab-qos-01.txt June 2000 4 Category: Informational 6 Next Steps for the IP QoS Architecture 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 While there has been significant progress in the definition of QoS 31 architectures for internet networks, there are a number of aspects 32 of QoS that appear to need further elaboration as they relate to 33 translating a set of tools into a coherent platform for end-to-end 34 service delivery. This document highlights the outstanding 35 architectural issues relating to the deployment and use of QoS 36 mechanisms within internet networks, noting those areas where 37 further standards work may assist with the deployment of QoS 38 internets. 40 2. Introduction 42 The default service offering associated with the Internet is 43 characterized as a best-effort variable service response. Within 44 this service profile the network makes no attempt to actively 45 differentiate its service response between the traffic streams 46 generated by concurrent users of the network. As the load generated 47 by the active traffic flows within the network varies, the network's 48 best effort service response will also vary. 50 The objective of various Internet Quality of Service (QoS) efforts 51 is to augment this base service with a number of selectable service 52 responses. These service responses may be distinguished from the 54 Huston Informational - Expires November 2000 1 55 best-effort service by some form of superior service level, or they 56 may be distinguished by providing a predictable service response 57 which is unaffected by external conditions such as the number of 58 concurrent traffic flows, or their generated traffic load. 60 Any network service response is an outcome of the resources 61 available to service a load, and the level of the load itself. To 62 offer such distinguished services there is not only a requirement to 63 provide a differentiated service response within the network, there 64 is also a requirement to control the service-qualified load admitted 65 into the network, so that the resources allocated by the network to 66 support a particular service response are capable of providing that 67 response for the imposed load. This combination of admission control 68 agents and service management elements can be summarized as "rules 69 plus behaviors". 71 As a general observation of QoS architectures, the service load 72 control aspect of QoS is perhaps the most troubling component of the 73 architecture. While there are a wide array of well understood 74 service response mechanisms that are available to IP networks, 75 matching a set of such mechanisms within a controlled environment to 76 respond to a set of service loads to achieve a completely consistent 77 service response remains an area of weakness within existing IP QoS 78 architectures. The control elements span a number of generic 79 requirements, including end-to-end application signaling, end-to- 80 network service signaling and resource management signaling to allow 81 policy-based control of network resources. 83 One way of implementing this control of imposed load to match the 84 level of available resources is through an application-driven 85 process of service level negotiation (also known as application 86 signaled QoS). Here, the application first signals its service 87 requirements to the network, and the network responds to this 88 request. The application will proceed if the network has indicated 89 that it is able to carry the additional load at the requested 90 service level. If the network indicates that it cannot accommodate 91 the service requirements the application may proceed in any case, on 92 the basis that the network will service the application's data on a 93 best effort basis. This negotiation between the application and the 94 network can take the form of explicit negotiation and commitment, 95 where there is a single negotiation phase, followed by a commitment 96 to the service level on the part of the network. This application- 97 signaled approach can be used within the Integrated Services 98 architecture, where the application frames its service request 99 within the resource reservation protocol (RSVP), and then passes 100 this request into the network. The network can either respond 101 positively in terms of its agreement to commit to this service 102 profile, or it can reject the request. If the network commits to the 103 request with a resource reservation, the application can then pass 104 traffic into the network with the expectation that as long as the 105 traffic remains within the traffic load profile that was originally 106 associated with the request, the network will meet the requested 107 service levels. There is no requirement for the application to 109 Huston Informational - Expires November 2000 2 110 periodically reconfirm the service reservation itself, as the 111 interaction between RSVP and the network constantly refreshes the 112 reservation while it remains active. The reservation remains in 113 force until the application explicitly requests termination of the 114 reservation, or the network signals to the application that it is 115 unable to continue with a service commitment to the reservation [3]. 116 There are variations to this model, including an aggregation model 117 where a proxy agent can fold a number of application-signaled 118 reservations into a common aggregate reservation along a common sub- 119 path, and a matching deaggregator can reestablish the collection of 120 individual resource reservations upon leaving the aggregate region 121 [5]. The essential feature of this Integrated Services model is the 122 "all or nothing" nature of the model. Either the network commits to 123 the reservation, in which case the requestor does not have to 124 subsequently monitor the network's level of response to the service, 125 or the network indicates that it cannot meet the resource 126 reservation. 128 An alternative approach to load control is to decouple the network 129 load control function from the application. This is the basis of the 130 Differentiated Services architecture. Here, a network implements a 131 load control function as part of the function of admission of 132 traffic into the network, admitting no more traffic within each 133 service category as there are assumed to be resources in the network 134 to deliver the intended service response. Necessarily there is some 135 element of imprecision in this function given that traffic may take 136 an arbitrary path through the network. In terms of the interaction 137 between the network and the application, this takes the form of a 138 service request without prior negotiation, where the application 139 requests a particular service response by simply marking each packet 140 with a code to indicate the desired service. Architecturally, this 141 approach decouples the end systems and the network, allowing a 142 network to implement an active admission function in order to 143 moderate the workload that is placed upon the network's resources 144 without specific reference to individual resource requests from end 145 systems. While this decoupling of control allows a network's 146 operator greater ability to manage its resources and a greater 147 ability to ensure the integrity of its services, there is a greater 148 potential level of imprecision in attempting to match applications' 149 service requirements to the network's service capabilities. 151 3. State and Stateless QoS 153 These two approaches to load control can be characterized as state- 154 based and stateless approaches respectively. 156 The architecture of the Integrated Services model equates the 157 cumulative sum of honored service requests to the current reserved 158 resource levels of the network. In order for a resource reservation 159 to be honored by the network, the network must maintain some form of 160 remembered state to describe the resources that have been reserved, 161 and the network path over which the reserved service will operate. 163 Huston Informational - Expires November 2000 3 164 This is to ensure integrity of the reservation. In addition, each 165 active network element within the network path must maintain a local 166 state that allows incoming IP packets to be correctly classified 167 into a reservation class. This classification allows the packet to 168 be placed into a packet flow context that is associated with an 169 appropriate service response consistent with the original end-to-end 170 service reservation. 172 In the second approach, that of a Differentiated Services model, the 173 packet is marked with a code to trigger the appropriate service 174 response from the network elements that handles the packet, so that 175 there is no strict requirement to install a per-reservation state on 176 these network elements. Also, the end application or the service 177 requestor is not required to provide the network with advance notice 178 relating to the destination of the traffic, nor any indication of 179 the intended traffic profile or the associated service profile. In 180 the absence of such information any form of per-application or per- 181 path resource reservation is not feasible. In this model there is no 182 maintained per-flow state within the network. 184 The state-based Integrated Services architectural model admits the 185 potential to support greater level of accuracy, and a finer level of 186 granularity on the part of the network to respond to service 187 requests. Each individual application's service request can be used 188 to generate a reservation state within the network that is intended 189 to prevent the resources associated with the reservation to be 190 reassigned or otherwise preempted to service other reservations or 191 to service best effort traffic loads. The state-based model is 192 intended to be exclusionary, where other traffic is displaced in 193 order to meet the reservation's service targets. 195 As noted in RFC2208 [2], there are several areas of concern about 196 the deployment of this form of service architecture. With regard to 197 concerns of per-flow service scalability, the resource requirements 198 (computational processing and memory consumption) for running per- 199 flow resource reservations on routers increase in direct proportion 200 to the number of separate reservations that need to be accommodated. 201 By the same token, router forwarding performance may be impacted 202 adversely by the packet-classification and scheduling mechanisms 203 intended to provide differentiated services for these resource- 204 reserved flows. This service architecture also poses some challenges 205 to the queuing mechanisms, where there is the requirement to 206 allocate absolute levels of egress bandwidth to individual flows, 207 while still supporting an unmanaged low priority best effort traffic 208 class. 210 The stateless approach to service management is more approximate in 211 the nature of its outcomes. Here there is no explicit negotiation 212 between the application's signaling of the service request and the 213 network's capability to deliver a particular service response. If 214 the network is incapable of meeting the service request, then the 215 request simply will not be honored. In such a situation there is no 216 requirement for the network to inform the application that the 218 Huston Informational - Expires November 2000 4 219 request cannot be honored, and it is left to the application to 220 determine if the service has not been delivered. The major attribute 221 of this approach is that it can possess excellent scaling 222 properties. If the network is capable of supporting a limited number 223 of discrete service responses, and the routers uses per-packet 224 marking to trigger the service response, then the processor and 225 memory requirements in each router do not increase in proportion to 226 the level of traffic passed through the router. 228 It is not intended to describe these service architectures in 229 further detail within this document. The reader is referred to 230 RFC1633 [3] for an overview of the Integrated Services Architecture 231 (IntServ) and RFC2475 [4] for an overview of the Differentiated 232 Services architecture (DiffServ). 234 These two approaches are the endpoints of what can be seen as a 235 continuum of control models, where the fine-grained precision of the 236 per application invocation reservation model can be aggregated into 237 larger, more general and potentially more approximate aggregate 238 reservation states, and the end-to-end element-by-element 239 reservation control can be progressively approximated by treating a 240 collection of subnetworks or an entire transit network as an 241 aggregate service element. There are a number of work in progress 242 efforts which are directed towards these aggregated control models, 243 including aggregation of RSVP [5], the RSVP DCLASS Object [6] to 244 allow Differentiated Services Code Points (DSCPs) to be carried in 245 RSVP message objects, and operation of Integrated Services over 246 Differentiated Services networks [7]. 248 4. Next Steps for QoS Architectures 250 Both the Integrated Services architecture and the Differentiated 251 Services architecture have some critical elements in terms of their 252 current definition which appear to be acting as deterrents to 253 widespread deployment. Some of these issues will probably be 254 addressed within the efforts to introduce aggregated control and 255 response models into these QoS architectures, while others may 256 require further refinement through standards-related activities. 258 4.1 QoS-Enabled Applications 260 One of the basic areas of uncertainty with QoS architectures is 261 whether QoS is a per-application service, whether QoS is a 262 transport-layer option, or both. Per-application services have 263 obvious implications of extending the QoS architecture into some 264 form of Application Protocol Interface (API), so that applications 265 could negotiate a QoS response from the network and alter their 266 behavior according to the outcome of the response. Examples of this 267 approach include GQOS [8], and RAPI [9]. As a transport layer 268 option, it could be envisaged that any application could have its 269 traffic carried by some form of QoS-enabled network services by 271 Huston Informational - Expires November 2000 5 272 changing the host configuration, or by changing the configuration at 273 some other network control point, without making any explicit 274 changes to the application itself. The strength of the transport 275 layer approach is that there is no requirement to substantially 276 alter application behavior, as the application is itself unaware of 277 the administratively assigned QoS. 279 In the case of the Integrated Services architecture, this transport 280 layer approach does not appear to be an available option, as the 281 application does require some alteration to function correctly in 282 this environment. The application must be able to provide to the 283 service reservation module a profile of its anticipated traffic, or 284 in other words the application must be able to predict its traffic 285 load. In addition, the application must be able to share the 286 reservation state with the network, so that if the network state 287 fails, the application can be informed of the failure. The more 288 general observation is that a network can only formulate an accurate 289 response to an application's requirements if the application is 290 willing to offer precise statement of its traffic profile, and is 291 willing to be policed in order to have its traffic fit within this 292 profile. 294 In the case of the Differentiated Services architecture there is no 295 explicit provision for the application to communicate with the 296 network regarding service levels. This does allow the use of a 297 transport level option within the end system that does not require 298 explicit alteration of the application to mark its generated traffic 299 with one of the available Differentiated Services service profiles. 300 However, whether the application is aware of such service profiles 301 or not, there is no level of service assurance to the application in 302 such a model. If the Differentiated Services boundary traffic 303 conditioners enter a load shedding state, the application is not 304 signaled of this condition, and is not explicitly aware that the 305 requested service response is not being provided by the network. If 306 the network itself changes state and is unable to meet the 307 cumulative traffic loads admitted by the ingress traffic 308 conditioners, neither the ingress traffic conditioners, nor the 309 client applications, are informed of this failure to maintain the 310 associated service quality. While there is no explicit need to alter 311 application behavior in this architecture, as the basic DiffServ 312 mechanism is one that is managed within the network itself, the 313 consequence is that an application may not be aware whether a 314 particular service state is being delivered to the application. 316 An additional factor for QoS enabled applications is that of 317 receiver capability negotiation. There is no value in the sender 318 establishing a QoS-enabled path across a network to the receiver if 319 the receiver is incapable of absorbing the consequent data flow. 320 This implies that QoS enabled applications also require some form of 321 end-to-end capability negotiation, possibly through a generic 322 protocol to allow the sender to match its QoS requirements to the 323 minimum of the flow resources that can be provided by the network 324 and the flow resources that can be processed by the receiver. In the 326 Huston Informational - Expires November 2000 6 327 case of the Integrated services architecture the application end-to- 328 end interaction can be integrated into the RSVP negotiation. In the 329 case of the Differentiated Services architecture there is no clear 330 path of integrating such receiver control into the signaling model 331 of the architecture as it stands. 333 If high quality services are to be provided, where `high quality' is 334 implied as being `high precision with a fine level of granularity', 335 then the implication is that all parts of the network that may be 336 involved with servicing the request either have to be over- 337 provisioned such that no load state can compromise the service 338 quality, or the network element must undertake explicit allocation 339 of resources to each flow that is associated with each service 340 request. 342 For end-to-end service delivery it does appear that QoS 343 architectures will need to extend to the level of the application 344 requesting the service profile. It appears that further refinement 345 of the QoS architecture is required to integrate DiffServ network 346 services into an end-to-end service delivery model, as noted in [7]. 348 4.2 The Service Environment 350 The outcome of the considerations of these two approaches to QoS 351 architecture within the network is that there appears to be no 352 single comprehensive service environment that possesses both service 353 accuracy and scaling properties. 355 The maintained reservation state of the Integrated Services 356 architecture and the end-to-end signaling function of RSVP are part 357 of a service management architecture, but it is not cost effective, 358 or even feasible, to operate a per-application reservation and 359 classification state across the high speed core of a network [2]. 361 While the aggregated behavior state of the Differentiated Services 362 architecture does offer excellent scaling properties, the lack of 363 end-to-end signaling facilities makes such an approach one that 364 cannot operate in isolation within any environment. The 365 Differentiated Services architecture can be characterized as a 366 boundary-centric operational model. With this boundary-centric 367 architecture, the signaling of resource availability from the 368 interior of the network to the boundary traffic conditioners is not 369 defined, nor is the signaling from the traffic conditioners to the 370 application that is resident on the end system. This has been noted 371 as an additional work item in the IntServ operations over DiffServ 372 work, concerning "definition of mechanisms to efficiently and 373 dynamically provision resources in a DiffServ network region. This 374 might include protocols by which an "oracle" (...) conveys 375 information about resource availability within a DiffServ region to 376 border routers." [7] 378 Huston Informational - Expires November 2000 7 379 What appears to be required within the Differentiated Services 380 service model is both resource availability signaling from the core 381 of the network to the DiffServ boundary and some form of signaling 382 from the boundary to the client application. 384 4.3 QoS Discovery 386 There is no robust mechanism for network path discovery with 387 specific service performance attributes. The assumption within both 388 IntServ and DiffServ architectures is that the best effort routing 389 path is used, where the path is either capable of sustaining the 390 service load, or not. 392 Assuming that the deployment of service differentiating 393 infrastructure will be piecemeal, even if only in the initial stages 394 of a QoS rollout, such an assumption may be unwarranted. If this is 395 the case, then how can a host application determine if there is a 396 distinguished service path to the destination? No existing 397 mechanisms exist within either of these architectures to query the 398 network for the potential to support a specific service profile. 399 Such a query would need to examine a number of candidate paths, 400 rather than simply examining the lowest metric routing path, so that 401 this discovery function is likely to be associated with some form of 402 QoS routing functionality. 404 From this perspective, there is still further refinement that may be 405 required in the model of service discovery and the associated task 406 of resource reservation. 408 4.4 QoS Routing and Resource Management 410 To date QoS routing has been developed at some distance from the 411 task of development of QoS architectures. The implicit assumption 412 within the current QoS architectural models is that the routing best 413 effort path will be used for both best effort traffic and 414 distinguished service traffic. 416 There is no explicit architectural option to allow the network 417 service path to be aligned along other than the single best routing 418 metric path, so that available network resources can be efficiently 419 applied to meet service requests. Considerations of maximizing 420 network efficiency would imply that some form of path selection is 421 necessary within a QoS architecture, allowing the set of service 422 requirements to be optimally supported within the network's 423 aggregate resource capability. 425 In addition to path selection, SPF-based interior routing protocols 426 allow for the flooding of link metric information across all network 427 elements. This mechanism appears to be a productive direction to 428 provide the control-level signaling between the interior of the 429 network and the network admission elements, allowing the admission 430 systems to admit traffic based on current resource availability 432 Huston Informational - Expires November 2000 8 433 rather than on necessarily conservative statically defined admission 434 criteria. 436 There is a more fundamental issue here concerning resource 437 management and traffic engineering. The approach of single path 438 selection with static load characteristics does not match a 439 networked environment which contains a richer mesh of connectivity 440 and dynamic load characteristics. In order to make efficient use of 441 a rich connectivity mesh, it is necessary to be able to direct 442 traffic with a common ingress and egress point across a set of 443 available network paths, spreading the load across a broader 444 collection of network links. At its basic form this is essentially a 445 traffic engineering problem. To support this function it is 446 necessary to calculate per-path dynamic load metrics, and allow the 447 network's ingress system the ability to distribute incoming traffic 448 across these paths in accordance with some model of desired traffic 449 balance. To apply this approach to a QoS architecture would imply 450 that each path has some form of vector of quality attributes, and 451 incoming traffic is balanced across a subset of available paths 452 where the quality attribute of the traffic is matched with the 453 quality vector of each available path. This augmentation to the 454 semantics of the traffic engineering is matched by a corresponding 455 shift in the calculation and interpretation of the path's quality 456 vector. In this approach what needs to be measured is not the path's 457 resource availability level (or idle proportion), but the path's 458 potential to carry additional traffic at a certain level of quality. 459 This potential metric is one that allows existing lower priority 460 traffic to be displaced to alternative paths. The path's quality 461 metric can be interpreted as a metric describing the displacement 462 capability of the path, rather than a resource availability metric. 464 This area of active network resource management, coupled with 465 dynamic network resource discovery, and the associated control level 466 signaling to network admission systems appears to be a topic for 467 further research at this point in time. 469 4.5 TCP and QoS 471 A congestion-managed rate-adaptive traffic flow (such as used by 472 TCP) uses the feedback from the ACK packet stream to time subsequent 473 data transmissions. The resultant traffic flow rate is an outcome of 474 the service quality provided to both the forward data packets and 475 the reverse ACK packets. If the ACK stream is treated by the network 476 with a different service profile to the outgoing data packets, it 477 remains an open question as to what extent will the data forwarding 478 service be compromised in terms of achievable throughput. High rates 479 of jitter on the ACK stream can cause ACK compression, that in turn 480 will cause high burst rates on the subsequent data send. Such bursts 481 will stress the service capacity of the network and will compromise 482 TCP throughput rates. 484 Huston Informational - Expires November 2000 9 485 One way to address this is to use some form of symmetric service, 486 where the ACK packets are handled using the same service class as 487 the forward data packets. If symmetric service profiles are 488 important for TCP sessions, how can this be structured in a fashion 489 that does not incorrectly account for service usage? In other words, 490 how can both directions of a TCP flow be accurately accounted to one 491 party? 493 Additionally, there is the interaction between the routing system 494 and the two TCP data flows. The Internet routing architecture does 495 not intrinsically preserve TCP flow symmetry, and the network path 496 taken by the forward packets of a TCP session may not exactly 497 correspond to the path used by the reverse packet flow. 499 TCP also exposes an additional performance constraint in the manner 500 of the traffic conditioning elements in a QoS-enabled network. 501 Traffic conditioners within QoS architectures are typically 502 specified using a rate enforcement mechanism of token buckets. Token 503 bucket traffic conditioners behave in a manner that is analogous to 504 a First In First Out queue. Such traffic conditioning systems impose 505 tail drop behavior on TCP streams. This tail drop behavior can 506 produce TCP timeout retransmission, unduly penalizing the average 507 TCP goodput rate to a level that may be well below the level 508 specified by the token bucket traffic conditioner. Token buckets can 509 be considered as TCP-hostile network elements. 511 The larger issue exposed in this consideration is that provision of 512 some form of assured service to congestion-managed traffic flows 513 requires traffic conditioning elements that operate using weighted 514 RED-like control behaviors within the network, with less 515 deterministic traffic patterns as an outcome. A requirement to 516 manage TCP burst behavior through token bucket control mechanisms is 517 most appropriately managed in the sender's TCP stack. 519 4.6 Per-Flow States and Per-Packet classifiers 521 Both the IntServ and DiffServ architectures use packet classifiers 522 as an intrinsic part of their architecture. These classifiers can be 523 considered as coarse or fine level classifiers. Fine-grained 524 classifiers can be considered as classifiers that attempt to isolate 525 elements of traffic from an invocation of an application (a `micro- 526 flow') and use a number of fields in the IP packet header to assist 527 in this, typically including the source and destination IP addresses 528 and source and source and destination port addresses. Coarse-grained 529 classifiers attempt to isolate traffic that belongs to an aggregated 530 service state, and typically use the DiffServ code field as the 531 classifying field. In the case of DiffServ there is the potential to 532 use fine-grained classifiers as part of the network ingress element, 533 and coarse-gained classifiers within the interior of the network. 534 Within the IntServ architecture every active network element that 535 undertakes active service discrimination is required to operate 536 fine-grained packet classifiers. 538 Huston Informational - Expires November 2000 10 539 Within the IntServ architecture the fine-grained classifiers are 540 defined to the level of granularity of an individual traffic flow, 541 using the packet's 5-tuple of (source address, destination address, 542 source port, destination port, protocol) as the means to identify an 543 individual traffic flow. The DiffServ Multi-Field (MF) classifiers 544 are also able to use this 5-tuple to map individual traffic flows 545 into supported behavior aggregates. 547 The use of IPSEC, NAT and various forms of IP tunnels result in a 548 occlusion of the flow identification within the IP packet header, 549 combining individual flows into a larger aggregate state that may be 550 too coarse for the network's service policies. The issue with such 551 mechanisms is that they may occur within the network path in a 552 fashion that is not visible to the end application, compromising the 553 ability for the application to determine whether the requested 554 service profile is being delivered by the network. In the case of 555 IPSEC there is a proposal to carry the IPSEC Security Parameter 556 Index (SPI) in the RSVP object [10], as a surrogate for the port 557 addresses. In the case of NAT and various forms of IP tunnels, there 558 appears to be no coherent way to preserve fine-grained 559 classification characteristics across NAT devices, or across tunnel 560 encapsulation. 562 IP packet fragmentation also affects the ability of the network to 563 identify individual flows, as the trailing fragments of the IP 564 packet will not include the TCP or UDP port address information. 565 This admits the possibility of trailing fragments of a packet within 566 a distinguished service class being classified into the base best 567 effort service category, and delaying the ultimate delivery of the 568 IP packet to the destination until the trailing best effort 569 delivered fragments have arrived. 571 The observation made here is that QoS services do have a number of 572 caveats that should be placed on both the application and the 573 network. Applications should perform path MTU discovery in order to 574 avoid packet fragmentation. Deployment of various forms of payload 575 encryption, header address translation and header encapsulation 576 should be undertaken with due attention to their potential impacts 577 on service delivery packet classifiers. 579 4.7 The Service Set 581 The underlying question posed here is how many distinguished service 582 responses are adequate to provide a functionally adequate range of 583 service responses? 585 The Differentiated Services architecture does not make any limiting 586 restrictions on the number of potential services that a network 587 operator can offer. The network operator may be limited to a choice 588 of up to 64 discrete services in terms of the 6 bit service code 589 point in the IP header but as the mapping from service to code point 590 can be defined by each network operator, there can be any number of 591 potential services. 593 Huston Informational - Expires November 2000 11 594 As always, there is such a thing as too much of a good thing, and a 595 large number of potential services leads to a set of issues around 596 end-to-end service coherency when spanning multiple network domains. 597 A small set of distinguished services can be supported across a 598 large set of service providers by equipment vendors and by 599 application designers alike. An ill-defined large set of potential 600 services often serves little productive purpose. This does point to 601 a potential refinement of the QoS architecture to define a small 602 core set of service profiles as "well-known" service profiles, and 603 place all other profiles within a "private use" category. 605 4.8 Measuring Service Delivery 607 There is a strong requirement within any QoS architecture for 608 network management approaches that provide a coherent view of the 609 operating state of the network. This differs from a conventional 610 element-by-element management view of the network in that the desire 611 here is to be able to provide a view of the available resources 612 along a particular path within a network, and map this view to an 613 admission control function which can determine whether to admit a 614 service differentiated flow along the nominated network path. 616 As well as managing the admission systems through resource 617 availability measurement, there is a requirement to be able to 618 measure the operating parameters of the delivered service. Such 619 measurement methodologies are required in order to answer the 620 question of how the network operator provides objective measurements 621 to substantiate the claim that the delivered service quality 622 conformed to the service specifications. Equally, there is a 623 requirement for a measurement methodology to allow the client to 624 measure the delivered service quality so that any additional expense 625 that may be associated with the use of premium services can be 626 justified in terms of superior application performance. 628 Such measurement methodologies appear to fall within the realm of 629 additional refinement to the QoS architecture. 631 4.9 QoS Accounting 633 It is reasonable to anticipate that such forms of premium service 634 and customized service will attract an increment on the service 635 tariff. The provision of a distinguished service is undertaken with 636 some level of additional network resources to support the service, 637 and the tariff premium should reflect this altered resource 638 allocation. Not only does such an incremental tariff shift the added 639 cost burden to those clients who are requesting a disproportionate 640 level of resources, but it provides a means to control the level of 641 demand for premium service levels. 643 If there are to be incremental tariffs on the use of premium 644 services, then some accounting of the use of the premium service 645 would appear to be necessary relating use of the service to a 647 Huston Informational - Expires November 2000 12 648 particular client. So far there is no definition of such an 649 accounting model nor a definition as to how to gather the data to 650 support the resource accounting function. 652 The impact of this QoS service model may be quite profound to the 653 models of Internet service provision. The commonly adopted model in 654 both the public internet and within enterprise networks is that of a 655 model of access, where the clients service tariff is based on the 656 characteristics of access to the services, rather than that of the 657 actual use of the service. The introduction of QoS services creates 658 a strong impetus to move to usage-based tariffs, where the tariff is 659 based on the level of use of the network's resources. This, in turn, 660 generates a requirement to meter resource use, which is a form of 661 usage accounting. 663 4.10 QoS Deployment Diversity 665 It is extremely improbable that any single form of service 666 differentiation technology will be rolled out across the Internet 667 and across all enterprise networks. 669 Some networks will deploy some form of service differentiation 670 technology while others will not. Some of these service platforms 671 will interoperate seamlessly and other less so. To expect all 672 applications, host systems, network routers, network policies, and 673 inter-provider arrangements to coalesce into a single homogenous 674 service environment that can support a broad range of service 675 responses is an somewhat unlikely outcome given the diverse nature 676 of the available technologies and industry business models. It is 677 more likely that we will see a number of small scale deployment of 678 service differentiation mechanisms and some efforts to bridge these 679 environments together in some way. 681 In this heterogeneous service environment the task of service 682 capability discovery is as critical as being able to invoke service 683 responses and measure the service outcomes. QoS architectures will 684 need to include protocol capabilities in supporting service 685 discovery mechanisms. 687 In addition, such a heterogeneous deployment environment will create 688 further scaling pressure on the operational network as now there is 689 an additional dimension to the size of the network. Each potential 690 path to each host is potentially qualified by the service 691 capabilities of the path. While one path may be considered as a 692 candidate best effort path, another path may offer a more precise 693 match between the desired service attributes and the capabilities of 694 the path to sustain the service. Inter-domain policy also impacts 695 upon this path choice, where inter-domain transit agreements may 696 specifically limit the types and total level of quality requests 697 than may be supported between the domains. Much of the brunt of such 698 scaling pressures will be seen in the inter-domain and intra-domain 699 routing domain where there are pressures to increase the number of 701 Huston Informational - Expires November 2000 13 702 attributes of a routing entry, and also to use the routing protocol 703 in some form of service signaling role. 705 4.11 QoS Inter-Domain signaling 707 QoS Path selection is both an intra-domain (interior) and an inter- 708 domain (exterior) issue. Within the inter-domain space, the current 709 routing technologies allow each domain to connect to a number of 710 other domains, and to express its policies with respect to received 711 traffic in terms of inter-domain route object attributes. 712 Additionally, each domain may express its policies with respect to 713 sending traffic through the use of boundary route object filters, 714 allowing a domain to express its preference for selecting one 715 domain's advertised routes over another. The inter-domain routing 716 space is a state of dynamic equilibrium between these various route 717 policies. 719 The introduction of differentiated services adds a further dimension 720 to this policy space. For example, while a providers may execute an 721 interconnection agreement with one party to exchange best effort 722 traffic, it may execute another agreement with a second party to 723 exchange service qualified traffic. The outcome of this form of 724 interconnection is that the service provider will require external 725 route advertisements to be qualified by the accepted service 726 profiles. Generalizing from this scenario, it is reasonable to 727 suggest that we will require the qualification of routing 728 advertisements with some form of service quality attributes. This 729 implies that we will require some form of quality vector-based 730 forwarding function, at least in the inter-domain space, and some 731 associated routing protocol can pass a quality of service vector in 732 an operationally stable fashion. 734 The implication of this requirement is that the number of objects 735 being managed by routing systems must expand dramatically, as the 736 size and number of objects managed within the routing domain 737 increases, and the calculation of a dynamic equilibrium of import 738 and export policies between interconnected providers will also be 739 subject to the same level of scaling pressure. 741 This has implications within the inter-domain forwarding space as 742 well, as the forwarding decision in such a services differentiated 743 environment is then qualified by some form of service quality 744 vector. This is required in order to pass exterior traffic to the 745 appropriate exterior interconnection gateway. 747 4.12 QoS Deployment Logistics 749 How does the widespread deployment of service-aware networks 750 commence? Which gets built first - host applications or network 751 infrastructure? 753 Huston Informational - Expires November 2000 14 754 No network operator will make the significant investment in 755 deployment and support of distinguished service infrastructure 756 unless there is a set of clients and applications available to make 757 immediate use of such facilities. No application designer will 758 attempt to integrate service quality features into the application 759 unless there is a model of operation supported by widespread 760 deployment that makes the additional investment in application 761 complexity worthwhile. With both halves of the deployment scenario 762 waiting for the other to move, widespread deployment of 763 distinguished services may require some other external impetus. 765 Further aspects of this deployment picture lie in the issues of 766 network provisioning and the associated task of traffic engineering. 767 Engineering a network to meet the demands of best effort flows 768 follows a well understood pattern of matching network points of user 769 concentrations to content delivery network points with best effort 770 paths. Integrating QoS-mediated traffic engineering into the 771 provisioning model suggests a provisioning requirement that also 772 requires input from a QoS demand model. 774 5. The objective of the QoS architecture 776 What is the precise nature of the problem that QoS is attempting to 777 solve? Perhaps this is one of the more fundamental questions 778 underlying the QoS effort, and the diversity of potential responses 779 is a pointer to the breadth of scope of the QoS effort. 781 All of the following responses form a part of the QoS intention: 783 - To control the network service response such that the response 784 to a specific service element is consistent and predictable. 786 - To control the network service response such that a service 787 element is provided with a level of response equal to or above a 788 guaranteed minimum. 790 - To allow a service element to establish in advance the service 791 response that can or will be obtained from the network. 793 - To control the contention for network resources such that a 794 service element is provided with a superior level of network 795 resource. 797 - To control the contention for network resources such that a 798 service element does not obtain an unfair allocation of 799 resources (to some definition of 'fairness'). 801 Broadly speaking, the first three responses can be regarded as 802 'application-centric', and the latter as 'network-centric'. It is 803 critical to bear in mind that none of these responses can be 804 addressed in isolation within any effective QoS architecture. Within 805 the end-to-end architectural model of the Internet, applications 806 make minimal demands on the underlying IP network. In the case of 808 Huston Informational - Expires November 2000 15 809 TCP, the protocol uses an end-to-end control signal approach to 810 dynamically adjust to the prevailing network state. QoS 811 architectures add a somewhat different constraint, in that the 812 network is placed in an active role within the task of resource 813 allocation and service delivery, rather than being a passive object 814 that requires end systems to adapt. 816 6. Towards an end-to-end QoS architecture 818 The challenge facing the QoS architecture lies in addressing the 819 weaknesses noted above, and in integrating the various elements of 820 the architecture into a cohesive whole that is capable of sustaining 821 end-to-end service models across a wide diversity of internet 822 platforms. It should be noted that such an effort may not 823 necessarily result in a single resultant architecture, and that it 824 is possible to see a number of end-to-end approaches based on 825 different combinations of the existing components. 827 One approach is to attempt to combine both architectures into an 828 end-to-end model, using IntServ as the architecture which allows 829 applications to interact with the network, and DiffServ as the 830 architecture to manage admission the network's resources [7]. In 831 this approach, the basic tension that needs to be resolved lies in 832 difference between the per-application view of the IntServ 833 architecture and the network boundary-centric view of the DiffServ 834 architecture. 836 One building block for such an end-to-end service architecture is a 837 service signaling protocol. The RSVP signaling protocol can address 838 the needs of applications that require a per-service end-to-end 839 service signaling environment. The abstracted model of RSVP is that 840 of a discovery signaling protocol that allows an application to use 841 a single transaction to communicate its service requirements to both 842 the network and the remote party, and through the response 843 mechanism, to allow these network elements to commit to the service 844 requirements. The barriers to deployment for this model lie in an 845 element-by element approach to service commitment, implying that 846 each network element must undertake per-flow signaling and per-flow 847 processing to support this service model. This fine-grained high 848 precision approach to service management is seen as imposing an 849 unacceptable level of overhead on the central core elements of large 850 carrier networks. 852 The DiffServ approach uses a model of abstraction which attempts to 853 create an external view of a compound network as a single 854 subnetwork. From this external perspective the network can be 855 perceived as two boundary service points, ingress and egress. The 856 advantage of this approach is that there exists the potential to 857 eliminate the requirement for per-flow state and per-flow processing 858 on the interior elements of such a network, and instead provide 859 aggregate service responses. 861 Huston Informational - Expires November 2000 16 862 One approach is for applications to use RSVP to request that their 863 flows be admitted into the network. If a request is accepted, it 864 would imply that there is a committed resource reservation within 865 the IntServ-capable components of the network, and that the service 866 requirements have been mapped into a compatible aggregate service 867 class within the DiffServ-capable network [7]. The DiffServ core 868 must be capable of carrying the RSVP messages across the DiffServ 869 network, so that further resource reservation is possible within the 870 IntServ network upon egress from the DiffServ environment. The 871 approach calls for the DiffServ network to use per-flow multi-field 872 (MF) classifier, where the MF classification is based on the RSVP- 873 signaled flow specification. The service specification of the RSVP- 874 signaled resource reservation is mapped into a compatible aggregate 875 DiffServ behavior aggregate and the MF classifier marks packets 876 according to the selected behavior. Alternatively the boundary of 877 the IntServ and DiffServ networks can use the IntServ egress to mark 878 the flow packets with the appropriate DSCP, allowing the DiffServ 879 ingress element to use the BA classifier, and dispense with the per- 880 flow MF classifier. 882 A high precision end-to-end QoS model requires that any admission 883 failure within the DiffServ network be communicated to the end 884 application, presumably via RSVP. This allows the application to 885 take some form of corrective action, either by modifying it's 886 service requirements or terminating the application. If the service 887 agreement between the DiffServ network is statically provisioned, 888 then this static information can be loaded into the IntServ boundary 889 systems, and IntServ can manage the allocation of available DiffServ 890 behavior aggregate resources. If the service agreement is 891 dynamically variable, some form of signaling is required between the 892 two networks to pass this resource availability information back 893 into the RSVP signaling environment. 895 7. Conclusions 897 None of these observations are intended to be any reason to condemn 898 the QoS architectures as completely impractical, nor are they 899 intended to provide any reason to believe that the efforts of 900 deploying QoS architectures will not come to fruition. 902 What this document is intended to illustrate is that there are still 903 a number of activities that are essential precursors to widespread 904 deployment and use of such QoS networks, and that there is a need to 905 fill in the missing sections with something substantial in terms of 906 adoption of additional refinements to the existing QoS model. 908 The architectural direction that appears to offer the most promising 909 outcome for QoS is not one of universal adoption of a single 910 architecture, but instead use a tailored approach where aggregated 911 service elements are used in the core of a network where scalability 912 is a major design objective and use per-flow service elements at the 914 Huston Informational - Expires November 2000 17 915 edge of the network where accuracy of the service response is a 916 sustainable outcome. 918 Architecturally, this points to no single QoS architecture, but 919 rather to a set of QoS mechanisms and a number of ways these 920 mechanisms can be configured to interoperate in a stable and 921 consistent fashion. 923 8. Security Considerations 925 The Internet is not an architecture that includes a strict 926 implementation of fairness of access to the common transmission and 927 switching resource. The introduction of any form of fairness, and, 928 in the case of QoS, weighted fairness, implies a requirement for 929 transparency in the implementation of the fairness contract between 930 the network provider and the network's users. This requires some 931 form of resource accounting and auditing, which, in turn, requires 932 the use of authentication and access control. The balancing factor 933 is that a shared resource should not overtly expose the level of 934 resource usage of any one user to any other, so that some level of 935 secrecy is required in this environment 937 The QoS environment also exposes the potential of theft of resources 938 through the unauthorized admission of traffic with an associated 939 service profile. QoS signaling protocols which are intended to 940 undertake resource management and admission control require the use 941 of identity authentication and integrity protection in order to 942 mitigate this potential for theft of resources. 944 Both forms of QoS architecture require the internal elements of the 945 network to be able to undertake classification of traffic based on 946 some form of identification that is carried in the packet header in 947 the clear. Classifications systems that use multi-field specifiers, 948 or per-flow specifiers rely on the carriage of end-to-end packet 949 header fields being carried in the clear. This has conflicting 950 requirements for security architectures that attempt to mask such 951 end-to-end identifiers within an encrypted payload. 953 QoS architectures can be considered as a means of exerting control 954 over network resource allocation. In the event of a rapid change in 955 resource availability (e.g. disaster) it is an undesirable outcome 956 if the remaining resources are completely allocated to a single 957 class of service to the exclusion of all other classes. Such an 958 outcome constitutes a denial of service, where the traffic control 959 system (routing) selects paths that are incapable of carrying any 960 traffic of a particular service class. 962 Huston Informational - Expires November 2000 18 963 9. References 965 [1] Bradner, S., "The Internet Standards Process " Revision 3", 966 BCP9, RFC2026, October 1996. 968 [2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., 969 Weinrib, A., Zhang, L., "Resource ReSerVation Protocol (RSVP) 970 Version 1 Applicability Statement", RFC2208, September 1997. 972 [3] Braden. R., Clark, D., Shenker, S., "Integrated Services in the 973 Internet Architecture: an Overview", RFC1633, June 1994. 975 [4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, 976 W., "An Architecture for Differentiated Services", RFC2475, December 977 1998. 979 [5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B., 980 "Aggregation of RSVP for IPv4 and IPv6 Reservations", work in 981 progress, March 2000. 983 [6] Bernet, Y., "Format of the RSVP DCLASS Object", work in 984 progress, October 1999. 986 [7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 987 Speer, M., Baden, R., Davie, B., Wroclawski, J., Felstaine, E., "A 988 Framework for Integrated Services Operation Over DiffServ Networks", 989 work in progress, May 2000. 991 [8] "Quality of Service Technical Overview", Microsoft Technical 992 Library, Microsoft Corporation, September 1999. 994 [9] "Resource Reservation Protocol API (RAPI)", Open Group 995 Technical Standard, C809 ISBN 1-85912-226-4, The Open Group, 996 December 1998. 998 [10] Berger, L., O'Malley, T., "RSVP Extensions for IPSEC Data 999 Flows", RFC 2007, September 1997. 1001 10. Acknowledgments 1003 Valuable contributions to this draft came from Yoram Bernet, Brian 1004 Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne. 1006 11. Author's Addresses 1008 Geoff Huston 1009 Telstra 1010 5/490 Northbourne Ave 1011 Dickson ACT 2602 1012 AUSTRALIA 1013 Email: gih@telstra.net 1015 Huston Informational - Expires November 2000 19 1016 Full Copyright Statement 1018 "Copyright (C) The Internet Society (date). All Rights Reserved. 1019 This document and translations of it may be copied and furnished to 1020 others, and derivative works that comment on or otherwise explain it 1021 or assist in its implementation may be prepared, copied, published 1022 and distributed, in whole or in part, without restriction of any 1023 kind, provided that the above copyright notice and this paragraph 1024 are included on all such copies and derivative works. However, this 1025 document itself may not be modified in any way, such as by removing 1026 the copyright notice or references to the Internet Society or other 1027 Internet organizations, except as needed for the purpose of 1028 developing Internet standards in which case the procedures for 1029 copyrights defined in the Internet Standards process must be 1030 followed, or as required to translate it into