idnits 2.17.1 draft-iab-qos-00.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 8 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. ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2000) is 8808 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 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-00.txt March 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 IP 31 QoS architecture, there are a number of aspects of QoS that appear 32 to need further elaboration as they relate to translating a set of 33 tools into a coherent platform for end-to-end service delivery. This 34 document highlights the outstanding issues relating to the 35 deployment and use of QoS mechanisms within the Internet, noting 36 those areas where further standards work may be required. 38 2. Introduction 40 The default service offering associated with the Internet is 41 characterized as a best-effort variable service response. Within 42 this service profile the network makes no attempt to actively 43 differentiate its service response between the traffic streams 44 generated by concurrent users of the network. As the load generated 45 by the active traffic flows within the network varies, the network's 46 best effort service response will also vary. 48 The objective of various Internet Quality of Service (QoS) efforts 49 is to augment this base service with a number of selectable service 50 responses. These service responses may be distinguished from the 52 Huston Informational - Expires August 2000 1 53 best-effort service by some form of superior service level, or they 54 may be distinguished by providing a predictable service response 55 which is unaffected by external conditions such as the number of 56 concurrent traffic flows or their generated traffic load. 58 Any network service response is an outcome of the resources 59 available to service a load, and the level of the load itself. To 60 offer such distinguished services there is not only a requirement to 61 provide a differentiated service response within the network, there 62 is also a requirement to control the service-qualified load admitted 63 into the network, so that the resources allocated by the network to 64 support a particular service response are capable of providing that 65 response for the imposed load. This combination of load control 66 elements and service management elements can be summarized as "rules 67 plus behaviours". 69 As a general observation of QoS architectures, the service load 70 control aspect of QoS is perhaps the most troubling component of the 71 architecture. While there are a wide array of well understood 72 service response mechanisms that are available to IP networks, 73 matching a set of such mechanisms within a controlled environment to 74 respond to a set of service loads to achieve a completely consistent 75 service response remains an area of weakness within existing IP QoS 76 architectures. The control elements span a number of requirements, 77 including end-to-end application signalling, end-to-network service 78 signalling and resource management signalling to allow policy-based 79 control of network resources. 81 One way of implementing this control of imposed load to match the 82 level of available resources is through service level negotiation. 83 Here, the application first signals its service requirements to the 84 network, and the network responds to this request. The application 85 only proceeds if the network has indicated that it is able to carry 86 the additional load at the requested service level. This can take 87 the form of explicit negotiation and commitment, where there is a 88 single negotiation phase, followed by a commitment to the service 89 level on the part of the network. This approach is used by the 90 Integrated Services architecture, where the application frames its 91 service request within the resource reservation protocol (RSVP), and 92 then passes this request into the network. The network can either 93 respond positively in terms of its agreement to commit to this 94 service profile, or it can reject the request. If the network 95 commits to the request with a resource reservation, the application 96 can then pass traffic into the network with the expectation that as 97 long as the traffic remains within the traffic load profile that was 98 originally associated with the request, the network will meet the 99 requested service levels. There is no requirement for the 100 application to reconfirm the service reservation itself, as the 101 interaction between RSVP and the network constantly refresh the 102 reservation while it remains active. The reservation remains in 103 force until the application explicitly requests termination of the 104 reservation, or the network signals to the application that it is 105 unable to continue with a service commitment to the reservation. The 107 Huston Informational - Expires August 2000 2 108 essential feature of this model is the "all or nothing" nature of 109 the service model. Either the network commits to the reservation, in 110 which case the application does not have to monitor the network's 111 level of response to the service, or the network indicates that it 112 cannot meet the reservation. 114 An alternative approach to load control is to decouple the network 115 load control function from the application. This is the basis of the 116 Differentiated Services architecture. Here, the network implements a 117 load control function as part of the function of admission of 118 traffic into the network, admitting no more traffic within each 119 service category as there are assumed to be resources in the network 120 to deliver the intended service response. Necessarily there is some 121 element of imprecision in this function given that traffic may take 122 an arbitrary path through the network. In terms of the interaction 123 between the network and the application, this takes the form of a 124 service request without prior negotiation, where the application 125 requests a particular service response by simply marking each packet 126 with a code to indicate the desired service. 128 3. State and Stateless QoS 130 These two approaches to load control can be characterized as state- 131 based and stateless approaches respectively. 133 In order for a resource reservation to be honored by the network, 134 the network must maintain some form of remembered state to describe 135 the resources that have been reserved, and the network path over 136 which the reserved service will operate. This is to ensure integrity 137 of the reservation. In addition, each active network element within 138 the network path must maintain a local state that allows incoming IP 139 packets to be correctly classified and then associated with an 140 appropriate service response that is consistent with the end-to-end 141 service reservation. 143 In the second approach the packet is marked with a code to trigger 144 the appropriate service response from every network element that 145 handles the packet, so that there is no need to install a per-flow 146 state on these network elements. Also, the application is not 147 required to provide the network with advance notice relating to the 148 destination of the traffic, nor any indication of the intended 149 traffic profile or the associated service profile, so any form of 150 per-application or per-path resource reservation is not feasible. In 151 this model there is no maintained per-flow state within the network. 153 The state-based Integrated Services architectural model admits a 154 greater level of accuracy, and a finer level of granularity on the 155 part of the network to respond to service requests. Each service 156 request can be used to generate a reservation state within the 157 network that is intended to prevent the resources associated with 158 the reservation to be pre-empted to service other reservations or to 159 service best effort traffic loads. The state-based model is intended 161 Huston Informational - Expires August 2000 3 162 to be exclusionary, where other traffic is displaced in order to 163 meet the reservation's service targets. 165 As noted in RFC2208 [2], there are several areas of concern about 166 the deployment of this form of service architecture. With regard to 167 concerns of per-flow service scalability, the resource requirements 168 (computational processing and memory consumption) for running per- 169 flow resource reservations on routers increase in direct proportion 170 to the number of separate reservations that need to be accommodated. 171 By the same token, router forwarding performance may be impacted 172 adversely by the packet-classification and scheduling mechanisms 173 intended to provide differentiated services for these resource- 174 reserved flows. This service architecture also poses some challenges 175 to the queuing mechanisms, where there is the requirement to 176 allocate absolute levels of egress bandwidth to individual flows, 177 while still supporting an unmanaged low priority best effort traffic 178 class. 180 The stateless approach to service management is more approximate in 181 the nature of its outcomes. Here there is no explicit negotiation 182 between the application's signaling of the service request and the 183 network's capability to deliver a particular service response. If 184 the network is incapable of meeting the service request, then the 185 request simply will not be honored. In such a situation there is no 186 requirement for the network to inform the application that the 187 request cannot be honored, and it is left to the application to 188 determine if the service has not been delivered. The major attribute 189 of this approach is that it can possess excellent scaling 190 properties. If the network is capable of supporting a limited number 191 of discrete service responses, and the routers uses per-packet 192 marking to trigger the service response, then the processor and 193 memory requirements in each router do not increase in proportion to 194 the level of traffic passed through the router. 196 It is not intended to describe these service architectures in 197 further detail within this document. The reader is referred to 198 RFC1633 [3] for an overview of the Integrated Services Architecture 199 (IntServ) and RFC2475 [4] for an overview of the Differentiated 200 Services architecture (DiffServ). 202 4. Next Steps for QoS Architectures 204 Both the Integrated Services architecture and the Differentiated 205 Services architecture have some missing elements in terms of their 206 current definition. The more critical elements are highlighted in 207 this section, as they are likely to form the next steps in the 208 refinement of the QoS architecture. 210 4.1 QoS-Enabled Applications 212 One of the basic areas of uncertainty with QoS architectures is 213 whether QoS is a per-application service, or whether QoS is a 214 transport-layer option. Per-application services have obvious 216 Huston Informational - Expires August 2000 4 217 implications of extending the QoS architecture into some form of 218 Application Protocol Interface (API), so that applications could 219 negotiate a QoS response from the network and alter their behaviour 220 according to the outcome of the response. As a transport layer 221 option, it could be envisaged that any application could have its 222 traffic carried by some form of QoS-enabled network services by 223 changing the host configuration, or by changing the configuration at 224 some other network control point, without making any explicit 225 changes to the application itself. The strength of the transport 226 layer approach is that there is no requirement to substantially 227 alter application behaviour, as the application is itself unaware of 228 the administratively assigned QoS. 230 In the case of the Integrated Services architecture, this transport 231 layer approach does not appear to be an available option, as the 232 application does require some alteration to function correctly in 233 this environment. The application must be able to provide to the 234 service reservation module a profile of its anticipated traffic, or 235 in other words the application must be able to predict its traffic 236 load. In addition the application must be able to share the 237 reservation state with the network, so that if the network state 238 fails, the application can be informed of the failure. 240 In the case of the Differentiated Services architecture there is no 241 explicit provision for the application to communicate with the 242 network regarding service levels. This does allow the use of a 243 transport level option within the end system that does not require 244 explicit alteration of the application to mark its generated traffic 245 with one of the available Differentiated Services service profiles. 246 However, whether the application is aware of such service profiles 247 or not, there is no level of service assurance to the application in 248 such a model. If the Differentiated Services boundary traffic 249 conditioners enter a load shedding state, the application is not 250 signalled of this condition, and is not explicitly aware that the 251 requested service response is not being provided by the network. If 252 the network itself changes state and is unable to meet the 253 cumulative traffic loads admitted by the ingress traffic 254 conditioners, neither the ingress traffic conditioners, nor the 255 client applications, are informed of this failure to maintain the 256 associated service quality. While there is no explicit need to alter 257 application behavior in this architecture, as the basic DiffServ 258 mechanism is one that is managed within the network itself, the 259 consequence is that an application may not be aware whether a 260 particular service state is being delivered to the application. 262 An additional factor for QoS enabled applications is that of 263 receiver capability negotiation. There is no value in the sender 264 establishing a QoS-enabled path across a network to the receiver if 265 the receiver is incapable of absorbing the consequent data flow. 266 This implies that QoS enabled applications also require some form of 267 end-to-end capability negotiation, possibly through a generic 268 protocol to allow the sender to match its QoS requirements to the 269 minimum of the flow resources that can be provided by the network 271 Huston Informational - Expires August 2000 5 272 and the flow resources that can be processed by the receiver. In the 273 case of the Integrated services architecture the application end-to- 274 end interaction can be integrated into the RSVP negotiation. In the 275 case of the Differentiated Services architecture there is no clear 276 path of integrating such receiver control into the signalling model 277 of the architecture as it stands. 279 For end-to-end service delivery it does appear that QoS 280 architectures will need to extend to the level of the application 281 requesting the service profile. It appears that further refinement 282 of the QoS architecture is required to integrate DiffServ network 283 services into an end-to-end service delivery model. 285 4.2 The Service Environment 287 The outcome of the considerations of these two approaches to QoS 288 architecture within the network is that there appears to be no 289 single comprehensive service environment that possesses both service 290 accuracy and scaling properties. 292 The maintained reservation state of the Integrated Services 293 architecture and the end-to-end signaling function of RSVP are part 294 of a service management architecture, but it is not cost effective, 295 or even feasible, to operate a per-application reservation and 296 classification state across the high speed core of a network. 298 While the aggregated behavior state of the Differentiated Services 299 architecture does offer excellent scaling properties, the lack of 300 end-to-end signaling facilities makes such an approach one that 301 cannot operate in isolation within any environment. The 302 Differentiated Services architecture can be characterized as a 303 boundary-centric operational model. With this boundary-centric 304 architecture, the signalling of resource availability from the 305 interior of the network to the boundary traffic conditioners is not 306 defined, nor is the signalling from the traffic conditioners to the 307 application that is resident on the end system. What appears to be 308 required within the Differentiated Services service model is both 309 resource availability signaling from the core of the network to the 310 DiffServ boundary and signaling from the boundary to the client 311 application. 313 4.3 QoS Discovery 315 There is no robust mechanism for network path discovery with 316 specific service performance attributes. The assumption within both 317 IntServ and DiffServ architectures is that the best effort routing 318 path is used, where the path is either capable of sustaining the 319 service load, or not. 321 Assuming that the deployment of service differentiating 322 infrastructure will be piecemeal, even if only in the initial stages 323 of a QoS rollout, such an assumption may be unwarranted. If this is 324 the case, then how can a host application determine if there is a 326 Huston Informational - Expires August 2000 6 327 distinguished service path to the destination? No mechanisms exist 328 within either architecture to query the network for the potential to 329 support a specific service profile. Such a query would potentially 330 examine a number of candidate paths, rather than simply examining 331 the lowest metric routing path, so that this discovery function is 332 likely to be associated with some form of QoS routing functionality. 333 From this perspective, there is still further refinement that may be 334 required in the model of service discovery and the associated task 335 of resource reservation. 337 4.4 QoS Routing and Resource Management 339 To date QoS routing has been developed at some distance from the 340 task of development of QoS architectures. The implicit assumption 341 within the current QoS architectural models is that the routing best 342 effort path will be used for both best effort traffic and 343 distinguished service traffic. 345 There is no explicit architectural option to allow the network 346 service path to be aligned along other than the single best routing 347 metric path, so that available network resources can be efficiently 348 applied to meet service requests. Considerations of maximizing 349 network efficiency would imply that some form of path selection is 350 necessary within a QoS architecture, allowing the set of service 351 requirements to be optimally supported within the network's 352 aggregate resource capability. 354 In addition to path selection, SPF-based interior routing protocols 355 allow for the flooding of link metric information across all network 356 elements. This mechanism appears to be a productive direction to 357 provide the control-level signalling between the interior of the 358 network and the network admission elements, allowing the admission 359 systems to admit traffic based on current resource availability 360 rather than on necessarily conservative statically defined admission 361 criteria. 363 There is a more fundamental issue here concerning resource 364 management and traffic engineering. The approach of single path 365 selection with static load characteristics does not match a 366 networked environment which contains a richer mesh of connectivity 367 and dynamic load characteristics. In order to make efficient use of 368 a rich connectivity mesh, it is necessary to be able to direct 369 traffic with a common ingress and egress point across a set of 370 available network paths, spreading the load across a broader 371 collection of network links. At its basic form this is essentially a 372 traffic engineering problem. To support this function it is 373 necessary to calculate per-path dynamic load metrics, and allow the 374 network's ingress system the ability to distribute incoming traffic 375 across these paths in accordance with some model of desired traffic 376 balance. To apply this approach to a QoS architecture would imply 377 that each path has some form of vector of quality attributes, and 378 incoming traffic is balanced across a subset of available paths 379 where the quality attribute of the traffic is matched with the 381 Huston Informational - Expires August 2000 7 382 quality vector of each available path. This augmentation to the 383 semantics of the traffic engineering is matched by a corresponding 384 shift in the calculation and interpretation of the path's quality 385 vector. In this approach what needs to be measured is not the path's 386 resource availability level (or idle proportion), but the path's 387 potential to carry additional traffic at a certain level of quality. 388 This potential metric is one that allows existing lower priority 389 traffic to be displaced to alternative paths. The path's quality 390 metric can be interpreted as a metric describing the displacement 391 capability of the path, rather than a resource availability metric. 393 This area of active network resource management, coupled with 394 dynamic network resource discovery, and the associated control level 395 signalling to network admission systems appears to be a topic for 396 further research at this point in time. 398 4.5 TCP and QoS 400 A congestion-managed rate-adaptive traffic flow (such as used by 401 TCP) uses the feedback from the ACK packet stream to time subsequent 402 data transmissions. The resultant traffic flow rate is an outcome of 403 the service quality provided to both the forward data packets and 404 the reverse ACK packets. If the ACK stream is treated by the network 405 with a different service profile to the outgoing data packets, it 406 remains an open question as to what extent will the data forwarding 407 service be compromised in terms of achievable throughput. High rates 408 of jitter on the ACK stream can cause ACK compression, that in turn 409 will cause high burst rates on the subsequent data send. Such bursts 410 will stress the service capacity of the network and will compromise 411 TCP throughput rates. 413 One way to address this is to use some form of symmetric service, 414 where the ACK packets are handled using the same service class as 415 the forward data packets. If symmetric service profiles are 416 important for TCP sessions, how can this be structured in a fashion 417 that does not incorrectly account for service usage? In other words, 418 how can both directions of a TCP flow be accurately accounted to one 419 party? 421 Additionally, there is the interaction between the routing system 422 and the two TCP data flows. The Internet routing architecture does 423 not intrinsically preserve TCP flow symmetry, and the network path 424 taken by the forward packets of a TCP session may not exactly 425 correspond to the path used by the reverse packet flow. 427 TCP also exposes an additional performance constraint in the manner 428 of the traffic conditioning elements in a QoS-enabled network. 429 Traffic conditioners within QoS architectures are typically 430 specified using a rate enforcement mechanism of token buckets. Token 431 bucket traffic conditioners behave in a manner that is analogous to 432 a First In First Out queue. Such traffic conditioning systems impose 433 tail drop behavior on TCP streams. This tail drop behavior can 435 Huston Informational - Expires August 2000 8 436 produce TCP timeout retransmission, unduly penalizing the average 437 TCP goodput rate to a level that may be well below the level 438 specified by the token bucket traffic conditioner. Token buckets can 439 be considered as TCP-hostile network elements. 441 The larger issue exposed in this consideration is that provision of 442 some form of assured service to congestion-managed traffic flows 443 requires traffic conditioning elements that operate using weighted 444 RED-like control behaviors within the network, with less 445 deterministic traffic patterns as an outcome. A requirement to 446 manage TCP burst behavior through token bucket control mechanisms is 447 most appropriately managed in the sender's TCP stack. 449 4.6 Per-Flow States and Per-Packet classifiers 451 Both the IntServ and DiffServ architectures use packet classifiers 452 as an intrinsic part of their architecture. In the case of DiffServ 453 the classifiers are part of the network ingress element, while 454 within the IntServ architecture every active network element is 455 required to operate packet classifiers. 457 Within the IntServ architecture the classifiers are defined to the 458 level of granularity of an individual traffic flow, using the 459 packet's 5-tuple of (source address, destination address, source 460 port, destination port, protocol) as the means to identify an 461 individual traffic flow. The DiffServ Multi-Field (MF) classifiers 462 are also able to use this 5-tuple to map individual traffic flows 463 into supported behavior aggregates. 465 The use of IPSEC, NAT and various forms of IP tunnels result in a 466 occlusion of the flow identification within the IP packet header, 467 combining individual flows into a larger aggregate state that may be 468 too coarse for the network's service policies. The issue with such 469 mechanisms is that they may occur within the network path in a 470 fashion that is not visible to the end application, compromising the 471 ability for the application to determine whether the requested 472 service profile is being delivered by the network. 474 IP packet fragmentation also affects the ability of the network to 475 identify individual flows, as the trailing fragments of the IP 476 packet will not include the TCP or UDP port address information. 477 This admits the possibility of trailing fragments of a packet within 478 a distinguished service class being classified into the base best 479 effort service category, and delaying the ultimate delivery of the 480 IP packet to the destination until the trailing best effort 481 delivered fragments have arrived. 483 The observation made here is that QoS services do have a number of 484 caveats that should be placed on both the application and the 485 network. Applications should perform path MTU discovery in order to 486 avoid packet fragmentation. Deployment of various forms of payload 487 encryption, header address translation and header encapsulation 489 Huston Informational - Expires August 2000 9 490 should be undertaken with due attention to their potential impacts 491 on service delivery packet classifiers. 493 4.7 The Service Set 495 The underlying question posed here is how many distinguished service 496 responses are adequate to provide a functionally adequate range of 497 service responses? 499 The Differentiated Services architecture does not make any limiting 500 restrictions on the number of potential services that a network 501 operator can offer. The network operator may be limited to a choice 502 of up to 64 discrete services in terms of the 6 bit service code 503 point in the IP header but as the mapping from service to code point 504 can be defined by each network operator, there can be any number of 505 potential services. 507 As always, there is such a thing as too much of a good thing, and a 508 large number of potential services leads to a set of issues around 509 end-to-end service coherency when spanning multiple network domains. 510 A small set of distinguished services can be supported across a 511 large set of service providers by equipment vendors and by 512 application designers alike. An ill defined large set of potential 513 services serves little productive purpose. This does point to a 514 potential refinement of the QoS architecture to define a small core 515 set of service profiles as well-known service profiles, and place 516 all other profiles within a private use category. 518 4.8 Measuring Service Delivery 520 There is a strong requirement within any QoS architecture for 521 network management approaches that provide a coherent view of the 522 operating state of the network. This differs from a conventional 523 element-by-element management view of the network in that the desire 524 here is to be able to provide a view of the available resources 525 along a particular path within a network, and map this view to an 526 admission control function which can determine whether to admit a 527 service differentiated flow along the nominated network path. 529 As well as managing the admission systems through resource 530 availability measurement, there is a requirement to be able to 531 measure the operating parameters of the delivered service. Such 532 measurement methodologies are required in order to answer the 533 question of how the network operator provides objective measurements 534 to substantiate the claim that the delivered service quality 535 conformed to the service specifications. Equally, there is a 536 requirement for a measurement methodology to allow the client to 537 measure the delivered service quality so that any additional expense 538 that may be associated with the use of premium services can be 539 justified in terms of superior application performance. 541 Such measurement methodologies appear to fall within the realm of 542 additional refinement to the QoS architecture. 544 Huston Informational - Expires August 2000 10 545 4.9 QoS Accounting 547 It is reasonable to anticipate that such forms of premium service 548 and customized service will attract an increment on the service 549 tariff. The provision of a distinguished service is undertaken with 550 some level of additional network resources to support the service, 551 and the tariff premium should reflect this altered resource 552 allocation. Not only does such an incremental tariff shift the added 553 cost burden to those clients who are requesting a disproportionate 554 level of resources, but it provides a means to control the level of 555 demand for premium service levels. 557 If there are to be incremental tariffs on the use of premium 558 services, then some accounting of the use of the premium service 559 would appear to be necessary relating use of the service to a 560 particular client. So far there is no definition of such an 561 accounting model nor a definition as to how to gather the data to 562 support the resource accounting function. 564 The impact of this QoS service model may be quite profound to the 565 models of Internet service provision. The commonly adopted model in 566 both the public internet and within enterprise networks is that of a 567 model of access, where the clients service tariff is based on the 568 characteristics of access to the services, rather than that of the 569 actual use of the service. The introduction of QoS services creates 570 a strong impetus to move to usage-based tariffs, where the tariff is 571 based on the level of use of the network's resources. This, in turn, 572 generates a requirement to meter resource use, which is a form of 573 usage accounting. 575 4.10 QoS Deployment Diversity 577 It is extremely improbable that any single form of service 578 differentiation technology will be rolled out across the Internet 579 and across all enterprise networks. 581 Some networks will deploy some form of service differentiation 582 technology while others will not. Some of these service platforms 583 will interoperate seamlessly and other less so. To expect all 584 applications, host systems, network routers, network policies, and 585 inter-provider arrangements to coalesce into a single homogenous 586 service environment that can support a broad range of service 587 responses is an somewhat unlikely outcome given the diverse nature 588 of the available technologies and industry business models. It is 589 more likely that we will see a number of small scale deployment of 590 service differentiation mechanisms and some efforts to bridge these 591 environments together in some way. 593 In this heterogeneous service environment the task of service 594 capability discovery is as critical as being able to invoke service 595 responses and measure the service outcomes. QoS architectures will 597 Huston Informational - Expires August 2000 11 598 need to include protocol capabilities in supporting service 599 discovery mechanisms. 601 In addition, such a heterogeneous deployment environment will create 602 further scaling pressure on the operational network as now there is 603 an additional dimension to the size of the network. Each potential 604 path to each host is potentially qualified by the service 605 capabilities of the path. While one path may be considered as a 606 candidate best effort path, another path may offer a more precise 607 match between the desired service attributes and the capabilities of 608 the path to sustain the service. Much of the brunt of such scaling 609 pressures will be seen in the inter-domain and intra-domain routing 610 domain where there are pressures to increase the number of 611 attributes of a routing entry, and also to use the routing protocol 612 in some form of service signaling role. 614 4.11 QoS Inter-Domain signalling 616 QoS Path selection is both an intra-domain (interior) and an inter- 617 domain (exterior) issue. Within the inter-domain space, the current 618 routing technologies allow each domain to connect to a number of 619 other domains, and to express its policies with respect to received 620 traffic in terms of inter-domain route object attributes. 621 Additionally, each domain may express its policies with respect to 622 sending traffic through the use of boundary route object filters, 623 allowing a domain to express its preference for selecting one 624 domain's advertised routes over another. The inter-domain routing 625 space is a state of dynamic equilibrium between these various route 626 policies. 628 The introduction of differentiated services adds a further dimension 629 to this policy space. For example, while a providers may execute an 630 interconnection agreement with one party to exchange best effort 631 traffic, it may execute another agreement with a second party to 632 exchange service qualified traffic. The outcome of this form of 633 interconnection is that the service provider will require external 634 route advertisements to be qualified by the accepted service 635 profiles. Generalizing from this scenario, it is reasonable to 636 suggest that we will require the qualification of routing 637 advertisements with some form of service quality attributes. This 638 implies that we will require some form of quality vector-based 639 forwarding function, at least in the inter-domain space, and some 640 associated routing protocol can pass a quality of service vector in 641 an operationally stable fashion. 643 The implication of this requirement is that the number of objects 644 being managed by routing systems must expand dramatically, as the 645 size and number of objects managed within the routing domain 646 increases, and the calculation of a dynamic equilibrium of import 647 and export policies between interconnected providers will also be 648 subject to the same level of scaling pressure. 650 Huston Informational - Expires August 2000 12 651 This has implications within the inter-domain forwarding space as 652 well, as the forwarding decision in such a services differentiated 653 environment is then qualified by some form of service quality 654 vector. This is required in order to pass exterior traffic to the 655 appropriate exterior interconnection gateway. 657 4.12 QoS Deployment Logistics 659 How does the deployment of service-aware networks commence? Which 660 gets built first - host applications or network infrastructure? 662 This is another instance of the chicken and egg problem. No network 663 operator will make the significant investment in distinguished 664 service infrastructure unless there is a set of clients and 665 applications available to make immediate use of such facilities. No 666 application designer will attempt to integrate service quality 667 features into the application unless there is a model of operation 668 supported by widespread deployment that makes the additional 669 investment in application complexity worthwhile. With both halves of 670 the deployment scenario waiting for the other to move, deployment of 671 distinguished services may require some other external impetus. 673 Further aspects of this deployment picture lie in the issues of 674 network provisioning and the associated task of traffic engineering. 675 Engineering a network to meet the demands of best effort flows 676 follows a well understood pattern of matching network points of user 677 concentrations to content delivery network points with best effort 678 paths. Integrating QoS-mediated traffic engineering into the 679 provisioning model suggests a provisioning requirement that also 680 requires input from a QoS demand model. 682 5. The objective of the QoS architecture 684 What is the precise nature of the problem that QoS is attempting to 685 solve? Perhaps this is one of the more fundamental questions 686 underlying the QoS effort, and the diversity of potential responses 687 is a pointer to the breadth of scope of the QoS effort. 689 All of the following responses form a part of the QoS intention: 691 1. To control the network service response such that the response 692 to a specific service element is consistent and predictable. 694 2. To control the network service response such that a service 695 element is provided with a level of response equal to or above a 696 guaranteed minimum. 698 3. To allow a service element to establish in advance the service 699 response that can or will be obtained from the network. 701 4. To control the contention for network resources such that a 702 service element is provided with a superior level of network 703 resource. 705 Huston Informational - Expires August 2000 13 706 5. To control the contention for network resources such that a 707 service element does not obtain an unfair allocation of 708 resources (to some definition of 'fairness'). 710 Broadly speaking, the first three responses can be regarded as 711 'application-centric', and the latter as 'network-centric'. It is 712 critical to bear in mind that none of these responses can be 713 addressed in isolation within any effective QoS architecture. Within 714 the end-to-end architectural model of the Internet, applications 715 make minimal demands on the underlying IP network. In the case of 716 TCP, the protocol uses an end-to-end control signal approach to 717 dynamically adjust to the prevailing network state. QoS 718 architectures add a critical addition to this 720 6. Towards an end-to-end QoS architecture 722 The challenge facing the QoS architecture lies in addressing the 723 weaknesses noted above, and in integrating the various elements of 724 the architecture into a cohesive whole that is capable of sustaining 725 end-to-end service models across a wide diversity of internet 726 platforms. It should be noted that such an effort may not 727 necessarily result in a single resultant architecture, and that it 728 is possible to see a number of end-to-end approaches based on 729 different combinations of the existing components. 731 One approach is to attempt to combine both architectures into an 732 end-to-end model, using IntServ as the architecture which allows 733 applications to interact with the network, and DiffServ as the 734 architecture to manage admission the network's resources. In this 735 approach, the basic tension that needs to be resolved lies in 736 difference between the per-application view of the IntServ 737 architecture and the network boundary-centric view of the DiffServ 738 architecture. 740 One major building block for such an end-to-end service architecture 741 is a service signalling protocol. The RSVP signalling protocol can 742 address the needs of applications that require a per-service end-to- 743 end service signalling environment. The abstracted model of RSVP is 744 that of a discovery signalling protocol that allows an application 745 to use a single transaction to communicate its service requirements 746 to both the network and the remote party, and through the response 747 mechanism, to allow these network elements to commit to the service 748 requirements. The barriers to deployment for this model lie in an 749 element-by element approach to service commitment, implying that 750 each network element must undertake per-flow signalling and per-flow 751 processing to support this service model. This approach is seen as 752 imposing an unacceptable level of overhead on the central core 753 elements of large carrier networks. 755 The DiffServ approach uses a model of abstraction which attempts to 756 create an external view of a compound network as a single 758 Huston Informational - Expires August 2000 14 759 subnetwork. From this perspective the network can be perceived as 760 two boundary service points, ingress and egress. The advantage of 761 this approach is that there exists the potential to eliminate the 762 requirement for per-flow state and per-flow processing on the 763 interior elements of such a network. 765 One approach is for applications to use RSVP to request that their 766 flows be admitted into the network. If a request is accepted, it 767 would imply that there is a committed resource reservation within 768 the IntServ-capable components of the network, and that the service 769 requirements have been mapped into a compatible aggregate service 770 class within the DiffServ-capable network. The DiffServ core must be 771 capable of carrying the RSVP messages across the DiffServ network, 772 so that further resource reservation is possible within the IntServ 773 network upon egress from the DiffServ environment. The approach 774 calls for the DiffServ network to use per-flow multi-field (MF) 775 classifier, where the MF classification is based on the RSVP- 776 signalled flow specification. The service specification of the RSVP- 777 signalled resource reservation is mapped into a compatible aggregate 778 DiffServ behavior aggregate and the MF classifier marks packets 779 according to the selected behavior. Alternatively the boundary of 780 the IntServ and DiffServ networks can use the IntServ egress to mark 781 the flow packets with the appropriate DSCP, allowing the DiffServ 782 ingress element to use the BA classifier, and dispense with the per- 783 flow MF classifier. 785 An end-to-end QoS model requires that any admission failure within 786 the DiffServ network be communicated to the end application via 787 RSVP. This allows the application to take some form of corrective 788 action, either by modifying it's service requirements or terminating 789 the application. If the service agreement between the DiffServ 790 network is statically provisioned, then this static information can 791 be loaded into the IntServ boundary systems, and IntServ can manage 792 the allocation of available DiffServ behavior aggregate resources. 793 If the service agreement is dynamically variable, some form of 794 signaling is required between the two networks to pass this resource 795 availability information back into the RSVP signalling environment. 797 7. Conclusions 799 None of these are any reason to condemn the QoS architectures as 800 completely impractical, nor do they provide any reason to believe 801 that the efforts of deploying QoS architectures will not come to 802 fruition. What this is intended to illustrate is that there are 803 still a number of activities that are essential precursors to 804 widespread deployment and use of such QoS networks and that there is 805 a need to fill in the missing sections with something more 806 substantial than pixie dust and wishful thinking. 808 8. Security Considerations 810 Huston Informational - Expires August 2000 15 811 The Internet is not an architecture that includes a strict 812 implementation of fairness of access to the common transmission and 813 switching resource. The introduction of any form of fairness, and, 814 in the case of QoS, weighted fairness, implies a requirement for 815 transparency in the implementation of the fairness contract between 816 the network provider and the network's users. This requires some 817 form of resource accounting and auditing, which, in turn, requires 818 the use of authentication and access control. The balancing factor 819 is that a shared resource should not overtly expose the level of 820 resource usage of any one user to any other, so that some level of 821 secrecy is required in this environment 823 The QoS environment also exposes the potential of theft of resources 824 through the unauthorized admission of traffic with an associated 825 service profile. QoS signalling protocols which are intended to 826 undertake resource management and admission control require the use 827 of identity authentication and integrity protection in order to 828 mitigate this potential for theft of resources. 830 Both forms of QoS architecture require the internal elements of the 831 network to be able to undertake classification of traffic based on 832 some form of identification that is carried in the packet header in 833 the clear. Classifications systems that use multi-field specifiers, 834 or per-flow specifiers rely on the carriage of end-to-end packet 835 header fields being carried in the clear. This has conflicting 836 requirements for security architectures that attempt to mask such 837 end-to-end identifiers within an encrypted payload. 839 QoS architectures can be considered as a means of exerting control 840 over network resource allocation. In the event of a rapid change in 841 resource availability (e.g. disaster) it is an undesirable outcome 842 if the remaining resources are completely allocated to a single 843 class of service to the exclusion of all other classes. Such an 844 outcome constitutes a denial of service, where the traffic control 845 system (routing) selects paths that are incapable of carrying any 846 traffic of a particular service class. 848 9. References 850 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 851 9, RFC 2026, October 1996. 853 [1] Bradner, S., _The Internet Standards Process _ Revision 3_, 854 BCP9, RFC2026, October 1996. 856 [2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., 857 Weinrib, A., Zhang, L., _Resource ReSerVation Protocol (RSVP) 858 Version 1 Applicability Statement_, RFC2208, September 1997. 860 Huston Informational - Expires August 2000 16 862 [3] Braden. R., Clark, D., Shenker, S., _Integrated Services in the 863 Internet Architecture: an Overview_, RFC1633, June 1994. 865 [4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, 866 W., _An Architecture for Differentiated Services_, RFC2475, December 867 1998. 869 10. Acknowledgments 871 Valuable contributions to this draft came from Brian Carpenter, Jon 872 Crowcroft, Tony Hain and Henning Schulzrinne. 874 11. Author's Addresses 876 Geoff Huston 877 Telstra 878 5/490 Northbourne Ave 879 Dickson ACT 2602 880 AUSTRALIA 881 Email: gih@telstra.net 883 Huston Informational - Expires August 2000 17 884 Full Copyright Statement 886 "Copyright (C) The Internet Society (date). All Rights Reserved. 887 This document and translations of it may be copied and furnished to 888 others, and derivative works that comment on or otherwise explain it 889 or assist in its implementation may be prepared, copied, published 890 and distributed, in whole or in part, without restriction of any 891 kind, provided that the above copyright notice and this paragraph 892 are included on all such copies and derivative works. However, this 893 document itself may not be modified in any way, such as by removing 894 the copyright notice or references to the Internet Society or other 895 Internet organizations, except as needed for the purpose of 896 developing Internet standards in which case the procedures for 897 copyrights defined in the Internet Standards process must be 898 followed, or as required to translate it into languages other than 899 English. The limited permissions granted above are perpetual and 900 will not be revoked by the Internet Society or its successors or 901 assigns. This document and the information contained herein is 902 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 903 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 904 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 905 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 906 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 908 Huston Informational - Expires August 2000 18