diff options
Diffstat (limited to 'doc/rfc/rfc2990.txt')
| -rw-r--r-- | doc/rfc/rfc2990.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc2990.txt b/doc/rfc/rfc2990.txt new file mode 100644 index 0000000..f4190b4 --- /dev/null +++ b/doc/rfc/rfc2990.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group G. Huston +Request for Comments: 2990 Telstra +Category: Informational November 2000 + + + Next Steps for the IP QoS Architecture + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + While there has been significant progress in the definition of + Quality of Service (QoS) architectures for internet networks, there + are a number of aspects of QoS that appear to need further + elaboration as they relate to translating a set of tools into a + coherent platform for end-to-end service delivery. This document + highlights the outstanding architectural issues relating to the + deployment and use of QoS mechanisms within internet networks, noting + those areas where further standards work may assist with the + deployment of QoS internets. + + This document is the outcome of a collaborative exercise on the part + of the Internet Architecture Board. + +Table of Contents + + 1. Introduction ........................................... 2 + 2. State and Stateless QoS ................................ 4 + 3. Next Steps for QoS Architectures ....................... 6 + 3.1 QoS-Enabled Applications ........................... 7 + 3.2 The Service Environment ............................ 9 + 3.3 QoS Discovery ...................................... 10 + 3.4 QoS Routing and Resource Management ................ 10 + 3.5 TCP and QoS ........................................ 11 + 3.6 Per-Flow States and Per-Packet classifiers ......... 13 + 3.7 The Service Set .................................... 14 + 3.8 Measuring Service Delivery ......................... 14 + 3.9 QoS Accounting ..................................... 15 + 3.10 QoS Deployment Diversity .......................... 16 + 3.11 QoS Inter-Domain signaling ........................ 17 + + + +Huston Informational [Page 1] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + 3.12 QoS Deployment Logistics .......................... 17 + 4. The objective of the QoS architecture .................. 18 + 5. Towards an end-to-end QoS architecture ................. 19 + 6. Conclusions ............................................ 21 + 7. Security Considerations ................................ 21 + 8. References ............................................. 22 + 9. Acknowledgments ........................................ 23 + 10. Author's Address ....................................... 23 + 11. Full Copyright Statement ............................... 24 + +1. Introduction + + The default service offering associated with the Internet is + characterized as a best-effort variable service response. Within + this service profile the network makes no attempt to actively + differentiate its service response between the traffic streams + generated by concurrent users of the network. As the load generated + by the active traffic flows within the network varies, the network's + best effort service response will also vary. + + The objective of various Internet Quality of Service (QoS) efforts is + to augment this base service with a number of selectable service + responses. These service responses may be distinguished from the + best-effort service by some form of superior service level, or they + may be distinguished by providing a predictable service response + which is unaffected by external conditions such as the number of + concurrent traffic flows, or their generated traffic load. + + Any network service response is an outcome of the resources available + to service a load, and the level of the load itself. To offer such + distinguished services there is not only a requirement to provide a + differentiated service response within the network, there is also a + requirement to control the service-qualified load admitted into the + network, so that the resources allocated by the network to support a + particular service response are capable of providing that response + for the imposed load. This combination of admission control agents + and service management elements can be summarized as "rules plus + behaviors". To use the terminology of the Differentiated Service + architecture [4], this admission control function is undertaken by a + traffic conditioner (an entity which performs traffic conditioning + functions and which may contain meters, markers, droppers, and + shapers), where the actions of the conditioner are governed by + explicit or implicit admission control agents. + + As a general observation of QoS architectures, the service load + control aspect of QoS is perhaps the most troubling component of the + architecture. While there are a wide array of well understood + service response mechanisms that are available to IP networks, + + + +Huston Informational [Page 2] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + matching a set of such mechanisms within a controlled environment to + respond to a set of service loads to achieve a completely consistent + service response remains an area of weakness within existing IP QoS + architectures. The control elements span a number of generic + requirements, including end-to-end application signaling, end-to- + network service signaling and resource management signaling to allow + policy-based control of network resources. This control may also + span a particular scope, and use 'edge to edge' signaling, intended + to support particular service responses within a defined network + scope. + + One way of implementing this control of imposed load to match the + level of available resources is through an application-driven process + of service level negotiation (also known as application signaled + QoS). Here, the application first signals its service requirements + to the network, and the network responds to this request. The + application will proceed if the network has indicated that it is able + to carry the additional load at the requested service level. If the + network indicates that it cannot accommodate the service requirements + the application may proceed in any case, on the basis that the + network will service the application's data on a best effort basis. + This negotiation between the application and the network can take the + form of explicit negotiation and commitment, where there is a single + negotiation phase, followed by a commitment to the service level on + the part of the network. This application-signaled approach can be + used within the Integrated Services architecture, where the + application frames its service request within the resource + reservation protocol (RSVP), and then passes this request into the + network. The network can either respond positively in terms of its + agreement to commit to this service profile, or it can reject the + request. If the network commits to the request with a resource + reservation, the application can then pass traffic into the network + with the expectation that as long as the traffic remains within the + traffic load profile that was originally associated with the request, + the network will meet the requested service levels. There is no + requirement for the application to periodically reconfirm the service + reservation itself, as the interaction between RSVP and the network + constantly refreshes the reservation while it remains active. The + reservation remains in force until the application explicitly + requests termination of the reservation, or the network signals to + the application that it is unable to continue with a service + commitment to the reservation [3]. There are variations to this + model, including an aggregation model where a proxy agent can fold a + number of application-signaled reservations into a common aggregate + reservation along a common sub-path, and a matching deaggregator can + reestablish the collection of individual resource reservations upon + leaving the aggregate region [5]. The essential feature of this + Integrated Services model is the "all or nothing" nature of the + + + +Huston Informational [Page 3] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + model. Either the network commits to the reservation, in which case + the requestor does not have to subsequently monitor the network's + level of response to the service, or the network indicates that it + cannot meet the resource reservation. + + An alternative approach to load control is to decouple the network + load control function from the application. This is the basis of the + Differentiated Services architecture. Here, a network implements a + load control function as part of the function of admission of traffic + into the network, admitting no more traffic within each service + category as there are assumed to be resources in the network to + deliver the intended service response. Necessarily there is some + element of imprecision in this function given that traffic may take + an arbitrary path through the network. In terms of the interaction + between the network and the application, this takes the form of a + service request without prior negotiation, where the application + requests a particular service response by simply marking each packet + with a code to indicate the desired service. Architecturally, this + approach decouples the end systems and the network, allowing a + network to implement an active admission function in order to + moderate the workload that is placed upon the network's resources + without specific reference to individual resource requests from end + systems. While this decoupling of control allows a network's + operator greater ability to manage its resources and a greater + ability to ensure the integrity of its services, there is a greater + potential level of imprecision in attempting to match applications' + service requirements to the network's service capabilities. + +2. State and Stateless QoS + + These two approaches to load control can be characterized as state- + based and stateless approaches respectively. + + The architecture of the Integrated Services model equates the + cumulative sum of honored service requests to the current reserved + resource levels of the network. In order for a resource reservation + to be honored by the network, the network must maintain some form of + remembered state to describe the resources that have been reserved, + and the network path over which the reserved service will operate. + This is to ensure integrity of the reservation. In addition, each + active network element within the network path must maintain a local + state that allows incoming IP packets to be correctly classified into + a reservation class. This classification allows the packet to be + placed into a packet flow context that is associated with an + appropriate service response consistent with the original end-to-end + service reservation. This local state also extends to the function + + + + + +Huston Informational [Page 4] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + of metering packets for conformance on a flow-by-flow basis, and the + additional overheads associated with maintenance of the state of each + of these meters. + + In the second approach, that of a Differentiated Services model, the + packet is marked with a code to trigger the appropriate service + response from the network elements that handles the packet, so that + there is no strict requirement to install a per-reservation state on + these network elements. Also, the end application or the service + requestor is not required to provide the network with advance notice + relating to the destination of the traffic, nor any indication of the + intended traffic profile or the associated service profile. In the + absence of such information any form of per-application or per-path + resource reservation is not feasible. In this model there is no + maintained per-flow state within the network. + + The state-based Integrated Services architectural model admits the + potential to support greater level of accuracy, and a finer level of + granularity on the part of the network to respond to service + requests. Each individual application's service request can be used + to generate a reservation state within the network that is intended + to prevent the resources associated with the reservation to be + reassigned or otherwise preempted to service other reservations or to + service best effort traffic loads. The state-based model is intended + to be exclusionary, where other traffic is displaced in order to meet + the reservation's service targets. + + As noted in RFC2208 [2], there are several areas of concern about the + deployment of this form of service architecture. With regard to + concerns of per-flow service scalability, the resource requirements + (computational processing and memory consumption) for running per- + flow resource reservations on routers increase in direct proportion + to the number of separate reservations that need to be accommodated. + By the same token, router forwarding performance may be impacted + adversely by the packet-classification and scheduling mechanisms + intended to provide differentiated services for these resource- + reserved flows. This service architecture also poses some challenges + to the queuing mechanisms, where there is the requirement to allocate + absolute levels of egress bandwidth to individual flows, while still + supporting an unmanaged low priority best effort traffic class. + + The stateless approach to service management is more approximate in + the nature of its outcomes. Here there is no explicit negotiation + between the application's signaling of the service request and the + network's capability to deliver a particular service response. If + the network is incapable of meeting the service request, then the + request simply will not be honored. In such a situation there is no + requirement for the network to inform the application that the + + + +Huston Informational [Page 5] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + request cannot be honored, and it is left to the application to + determine if the service has not been delivered. The major attribute + of this approach is that it can possess excellent scaling properties + from the perspective of the network. If the network is capable of + supporting a limited number of discrete service responses, and the + routers uses per-packet marking to trigger the service response, then + the processor and memory requirements in each router do not increase + in proportion to the level of traffic passed through the router. Of + course this approach does introduce some degree of compromise in that + the service response is more approximate as seen by the end client, + and scaling the number of clients and applications in such an + environment may not necessarily result in a highly accurate service + response to every client's application. + + It is not intended to describe these service architectures in further + detail within this document. The reader is referred to RFC1633 [3] + for an overview of the Integrated Services Architecture (IntServ) and + RFC2475 [4] for an overview of the Differentiated Services + architecture (DiffServ). + + These two approaches are the endpoints of what can be seen as a + continuum of control models, where the fine-grained precision of the + per application invocation reservation model can be aggregated into + larger, more general and potentially more approximate aggregate + reservation states, and the end-to-end element-by-element reservation + control can be progressively approximated by treating a collection of + subnetworks or an entire transit network as an aggregate service + element. There are a number of work in progress efforts which are + directed towards these aggregated control models, including + aggregation of RSVP [5], the RSVP DCLASS Object [6] to allow + Differentiated Services Code Points (DSCPs) to be carried in RSVP + message objects, and operation of Integrated Services over + Differentiated Services networks [7]. + +3. Next Steps for QoS Architectures + + Both the Integrated Services architecture and the Differentiated + Services architecture have some critical elements in terms of their + current definition which appear to be acting as deterrents to + widespread deployment. Some of these issues will probably be + addressed within the efforts to introduce aggregated control and + response models into these QoS architectures, while others may + require further refinement through standards-related activities. + + + + + + + + +Huston Informational [Page 6] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + +3.1 QoS-Enabled Applications + + One of the basic areas of uncertainty with QoS architectures is + whether QoS is a per-application service, whether QoS is a + transport-layer option, or both. Per-application services have + obvious implications of extending the QoS architecture into some form + of Application Protocol Interface (API), so that applications could + negotiate a QoS response from the network and alter their behavior + according to the outcome of the response. Examples of this approach + include GQOS [8], and RAPI [9]. As a transport layer option, it + could be envisaged that any application could have its traffic + carried by some form of QoS-enabled network services by changing the + host configuration, or by changing the configuration at some other + network control point, without making any explicit changes to the + application itself. The strength of the transport layer approach is + that there is no requirement to substantially alter application + behavior, as the application is itself unaware of the + administratively assigned QoS. The weakness of this approach is that + the application is unable to communicate what may be useful + information to the network or to the policy systems that are managing + the network's service responses. In the absence of such information + the network may provide a service response that is far superior than + the application's true requirements, or far inferior than what is + required for the application to function correctly. An additional + weakness of a transport level approach refers to those class of + applications that can adapt their traffic profile to meet the + available resources within the network. As a transport level + mechanism, such network availability information as may be available + to the transport level is not passed back to the application. + + In the case of the Integrated Services architecture, this transport + layer approach does not appear to be an available option, as the + application does require some alteration to function correctly in + this environment. The application must be able to provide to the + service reservation module a profile of its anticipated traffic, or + in other words the application must be able to predict its traffic + load. In addition, the application must be able to share the + reservation state with the network, so that if the network state + fails, the application can be informed of the failure. The more + general observation is that a network can only formulate an accurate + response to an application's requirements if the application is + willing to offer precise statement of its traffic profile, and is + willing to be policed in order to have its traffic fit within this + profile. + + In the case of the Differentiated Services architecture there is no + explicit provision for the application to communicate with the + network regarding service levels. This does allow the use of a + + + +Huston Informational [Page 7] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + transport level option within the end system that does not require + explicit alteration of the application to mark its generated traffic + with one of the available Differentiated Services service profiles. + However, whether the application is aware of such service profiles or + not, there is no level of service assurance to the application in + such a model. If the Differentiated Services boundary traffic + conditioners enter a load shedding state, the application is not + signaled of this condition, and is not explicitly aware that the + requested service response is not being provided by the network. If + the network itself changes state and is unable to meet the cumulative + traffic loads admitted by the ingress traffic conditioners, neither + the ingress traffic conditioners, nor the client applications, are + informed of this failure to maintain the associated service quality. + While there is no explicit need to alter application behavior in this + architecture, as the basic DiffServ mechanism is one that is managed + within the network itself, the consequence is that an application may + not be aware whether a particular service state is being delivered to + the application. + + There is potential in using an explicit signaling model, such as used + by IntServ, but carrying a signal which allows the network to manage + the application's traffic within an aggregated service class [6]. + Here the application does not pass a complete picture of its intended + service profile to the network, but instead is providing some level + of additional information to the network to assist in managing its + resources, both in terms of the generic service class that the + network can associate with the application's traffic, and the + intended path of the traffic through the network. + + An additional factor for QoS enabled applications is that of receiver + capability negotiation. There is no value in the sender establishing + a QoS-enabled path across a network to the receiver if the receiver + is incapable of absorbing the consequent data flow. This implies + that QoS enabled applications also require some form of end-to-end + capability negotiation, possibly through a generic protocol to allow + the sender to match its QoS requirements to the minimum of the flow + resources that can be provided by the network and the flow resources + that can be processed by the receiver. In the case of the Integrated + services architecture the application end-to-end interaction can be + integrated into the RSVP negotiation. In the case of the + Differentiated Services architecture there is no clear path of + integrating such receiver control into the signaling model of the + architecture as it stands. + + If high quality services are to be provided, where `high quality' is + implied as being `high precision with a fine level of granularity', + then the implication is that all parts of the network that may be + involved with servicing the request either have to be over- + + + +Huston Informational [Page 8] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + provisioned such that no load state can compromise the service + quality, or the network element must undertake explicit allocation of + resources to each flow that is associated with each service request. + + For end-to-end service delivery it does appear that QoS architectures + will need to extend to the level of the application requesting the + service profile. It appears that further refinement of the QoS + architecture is required to integrate DiffServ network services into + an end-to-end service delivery model, as noted in [7]. + +3.2 The Service Environment + + The outcome of the considerations of these two approaches to QoS + architecture within the network is that there appears to be no single + comprehensive service environment that possesses both service + accuracy and scaling properties. + + The maintained reservation state of the Integrated Services + architecture and the end-to-end signaling function of RSVP are part + of a service management architecture, but it is not cost effective, + or even feasible, to operate a per-application reservation and + classification state across the high speed core of a network [2]. + + While the aggregated behavior state of the Differentiated Services + architecture does offer excellent scaling properties, the lack of + end-to-end signaling facilities makes such an approach one that + cannot operate in isolation within any environment. The + Differentiated Services architecture can be characterized as a + boundary-centric operational model. With this boundary-centric + architecture, the signaling of resource availability from the + interior of the network to the boundary traffic conditioners is not + defined, nor is the signaling from the traffic conditioners to the + application that is resident on the end system. This has been noted + as an additional work item in the IntServ operations over DiffServ + work, concerning "definition of mechanisms to efficiently and + dynamically provision resources in a DiffServ network region". This + might include protocols by which an "oracle" (...) conveys + information about resource availability within a DiffServ region to + border routers." [7] + + What appears to be required within the Differentiated Services + service model is both resource availability signaling from the core + of the network to the DiffServ boundary and some form of signaling + from the boundary to the client application. + + + + + + + +Huston Informational [Page 9] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + +3.3 QoS Discovery + + There is no robust mechanism for network path discovery with specific + service performance attributes. The assumption within both IntServ + and DiffServ architectures is that the best effort routing path is + used, where the path is either capable of sustaining the service + load, or not. + + Assuming that the deployment of service differentiating + infrastructure will be piecemeal, even if only in the initial stages + of a QoS rollout, such an assumption may be unwarranted. If this is + the case, then how can a host application determine if there is a + distinguished service path to the destination? No existing + mechanisms exist within either of these architectures to query the + network for the potential to support a specific service profile. Such + a query would need to examine a number of candidate paths, rather + than simply examining the lowest metric routing path, so that this + discovery function is likely to be associated with some form of QoS + routing functionality. + + From this perspective, there is still further refinement that may be + required in the model of service discovery and the associated task of + resource reservation. + +3.4 QoS Routing and Resource Management + + To date QoS routing has been developed at some distance from the task + of development of QoS architectures. The implicit assumption within + the current QoS architectural models is that the routing best effort + path will be used for both best effort traffic and distinguished + service traffic. + + There is no explicit architectural option to allow the network + service path to be aligned along other than the single best routing + metric path, so that available network resources can be efficiently + applied to meet service requests. Considerations of maximizing + network efficiency would imply that some form of path selection is + necessary within a QoS architecture, allowing the set of service + requirements to be optimally supported within the network's aggregate + resource capability. + + In addition to path selection, SPF-based interior routing protocols + allow for the flooding of link metric information across all network + elements. This mechanism appears to be a productive direction to + provide the control-level signaling between the interior of the + network and the network admission elements, allowing the admission + + + + + +Huston Informational [Page 10] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + systems to admit traffic based on current resource availability + rather than on necessarily conservative statically defined admission + criteria. + + There is a more fundamental issue here concerning resource management + and traffic engineering. The approach of single path selection with + static load characteristics does not match a networked environment + which contains a richer mesh of connectivity and dynamic load + characteristics. In order to make efficient use of a rich + connectivity mesh, it is necessary to be able to direct traffic with + a common ingress and egress point across a set of available network + paths, spreading the load across a broader collection of network + links. At its basic form this is essentially a traffic engineering + problem. To support this function it is necessary to calculate per- + path dynamic load metrics, and allow the network's ingress system the + ability to distribute incoming traffic across these paths in + accordance with some model of desired traffic balance. To apply this + approach to a QoS architecture would imply that each path has some + form of vector of quality attributes, and incoming traffic is + balanced across a subset of available paths where the quality + attribute of the traffic is matched with the quality vector of each + available path. This augmentation to the semantics of the traffic + engineering is matched by a corresponding shift in the calculation + and interpretation of the path's quality vector. In this approach + what needs to be measured is not the path's resource availability + level (or idle proportion), but the path's potential to carry + additional traffic at a certain level of quality. This potential + metric is one that allows existing lower priority traffic to be + displaced to alternative paths. The path's quality metric can be + interpreted as a metric describing the displacement capability of the + path, rather than a resource availability metric. + + This area of active network resource management, coupled with dynamic + network resource discovery, and the associated control level + signaling to network admission systems appears to be a topic for + further research at this point in time. + +3.5 TCP and QoS + + A congestion-managed rate-adaptive traffic flow (such as used by TCP) + uses the feedback from the ACK packet stream to time subsequent data + transmissions. The resultant traffic flow rate is an outcome of the + service quality provided to both the forward data packets and the + reverse ACK packets. If the ACK stream is treated by the network + with a different service profile to the outgoing data packets, it + remains an open question as to what extent will the data forwarding + service be compromised in terms of achievable throughput. High rates + of jitter on the ACK stream can cause ACK compression, that in turn + + + +Huston Informational [Page 11] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + will cause high burst rates on the subsequent data send. Such bursts + will stress the service capacity of the network and will compromise + TCP throughput rates. + + One way to address this is to use some form of symmetric service, + where the ACK packets are handled using the same service class as the + forward data packets. If symmetric service profiles are important + for TCP sessions, how can this be structured in a fashion that does + not incorrectly account for service usage? In other words, how can + both directions of a TCP flow be accurately accounted to one party? + + Additionally, there is the interaction between the routing system and + the two TCP data flows. The Internet routing architecture does not + intrinsically preserve TCP flow symmetry, and the network path taken + by the forward packets of a TCP session may not exactly correspond to + the path used by the reverse packet flow. + + TCP also exposes an additional performance constraint in the manner + of the traffic conditioning elements in a QoS-enabled network. + Traffic conditioners within QoS architectures are typically specified + using a rate enforcement mechanism of token buckets. Token bucket + traffic conditioners behave in a manner that is analogous to a First + In First Out queue. Such traffic conditioning systems impose tail + drop behavior on TCP streams. This tail drop behavior can produce + TCP timeout retransmission, unduly penalizing the average TCP goodput + rate to a level that may be well below the level specified by the + token bucket traffic conditioner. Token buckets can be considered as + TCP-hostile network elements. + + The larger issue exposed in this consideration is that provision of + some form of assured service to congestion-managed traffic flows + requires traffic conditioning elements that operate using weighted + RED-like control behaviors within the network, with less + deterministic traffic patterns as an outcome. A requirement to + manage TCP burst behavior through token bucket control mechanisms is + most appropriately managed in the sender's TCP stack. + + There are a number of open areas in this topic that would benefit + from further research. The nature of the interaction between the + end-to-end TCP control system and a collection of service + differentiation mechanisms with a network is has a large number of + variables. The issues concern the time constants of the control + systems, the amplitude of feedback loops, and the extent to which + each control system assumes an operating model of other active + control systems that are applied to the same traffic flow, and the + mode of convergence to a stable operational state for each control + system. + + + + +Huston Informational [Page 12] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + +3.6 Per-Flow States and Per-Packet classifiers + + Both the IntServ and DiffServ architectures use packet classifiers as + an intrinsic part of their architecture. These classifiers can be + considered as coarse or fine level classifiers. Fine-grained + classifiers can be considered as classifiers that attempt to isolate + elements of traffic from an invocation of an application (a `micro- + flow') and use a number of fields in the IP packet header to assist + in this, typically including the source and destination IP addresses + and source and source and destination port addresses. Coarse-grained + classifiers attempt to isolate traffic that belongs to an aggregated + service state, and typically use the DiffServ code field as the + classifying field. In the case of DiffServ there is the potential to + use fine-grained classifiers as part of the network ingress element, + and coarse-gained classifiers within the interior of the network. + + Within flow-sensitive IntServ deployments, every active network + element that undertakes active service discrimination is requirement + to operate fine-grained packet classifiers. The granularity of the + classifiers can be relaxed with the specification of aggregate + classifiers [5], but at the expense of the precision and accuracy of + the service response. + + Within the IntServ architecture the fine-grained classifiers are + defined to the level of granularity of an individual traffic flow, + using the packet's 5-tuple of (source address, destination address, + source port, destination port, protocol) as the means to identify an + individual traffic flow. The DiffServ Multi-Field (MF) classifiers + are also able to use this 5-tuple to map individual traffic flows + into supported behavior aggregates. + + The use of IPSEC, NAT and various forms of IP tunnels result in a + occlusion of the flow identification within the IP packet header, + combining individual flows into a larger aggregate state that may be + too coarse for the network's service policies. The issue with such + mechanisms is that they may occur within the network path in a + fashion that is not visible to the end application, compromising the + ability for the application to determine whether the requested + service profile is being delivered by the network. In the case of + IPSEC there is a proposal to carry the IPSEC Security Parameter Index + (SPI) in the RSVP object [10], as a surrogate for the port addresses. + In the case of NAT and various forms of IP tunnels, there appears to + be no coherent way to preserve fine-grained classification + characteristics across NAT devices, or across tunnel encapsulation. + + IP packet fragmentation also affects the ability of the network to + identify individual flows, as the trailing fragments of the IP packet + will not include the TCP or UDP port address information. This admits + + + +Huston Informational [Page 13] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + the possibility of trailing fragments of a packet within a + distinguished service class being classified into the base best + effort service category, and delaying the ultimate delivery of the IP + packet to the destination until the trailing best effort delivered + fragments have arrived. + + The observation made here is that QoS services do have a number of + caveats that should be placed on both the application and the + network. Applications should perform path MTU discovery in order to + avoid packet fragmentation. Deployment of various forms of payload + encryption, header address translation and header encapsulation + should be undertaken with due attention to their potential impacts on + service delivery packet classifiers. + +3.7 The Service Set + + The underlying question posed here is how many distinguished service + responses are adequate to provide a functionally adequate range of + service responses? + + The Differentiated Services architecture does not make any limiting + restrictions on the number of potential services that a network + operator can offer. The network operator may be limited to a choice + of up to 64 discrete services in terms of the 6 bit service code + point in the IP header but as the mapping from service to code point + can be defined by each network operator, there can be any number of + potential services. + + As always, there is such a thing as too much of a good thing, and a + large number of potential services leads to a set of issues around + end-to-end service coherency when spanning multiple network domains. + A small set of distinguished services can be supported across a large + set of service providers by equipment vendors and by application + designers alike. An ill-defined large set of potential services + often serves little productive purpose. This does point to a + potential refinement of the QoS architecture to define a small core + set of service profiles as "well-known" service profiles, and place + all other profiles within a "private use" category. + +3.8 Measuring Service Delivery + + There is a strong requirement within any QoS architecture for network + management approaches that provide a coherent view of the operating + state of the network. This differs from a conventional element-by- + element management view of the network in that the desire here is to + be able to provide a view of the available resources along a + + + + + +Huston Informational [Page 14] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + particular path within a network, and map this view to an admission + control function which can determine whether to admit a service + differentiated flow along the nominated network path. + + As well as managing the admission systems through resource + availability measurement, there is a requirement to be able to + measure the operating parameters of the delivered service. Such + measurement methodologies are required in order to answer the + question of how the network operator provides objective measurements + to substantiate the claim that the delivered service quality + conformed to the service specifications. Equally, there is a + requirement for a measurement methodology to allow the client to + measure the delivered service quality so that any additional expense + that may be associated with the use of premium services can be + justified in terms of superior application performance. + + Such measurement methodologies appear to fall within the realm of + additional refinement to the QoS architecture. + +3.9 QoS Accounting + + It is reasonable to anticipate that such forms of premium service and + customized service will attract an increment on the service tariff. + The provision of a distinguished service is undertaken with some + level of additional network resources to support the service, and the + tariff premium should reflect this altered resource allocation. Not + only does such an incremental tariff shift the added cost burden to + those clients who are requesting a disproportionate level of + resources, but it provides a means to control the level of demand for + premium service levels. + + If there are to be incremental tariffs on the use of premium + services, then some accounting of the use of the premium service + would appear to be necessary relating use of the service to a + particular client. So far there is no definition of such an + accounting model nor a definition as to how to gather the data to + support the resource accounting function. + + The impact of this QoS service model may be quite profound to the + models of Internet service provision. The commonly adopted model in + both the public internet and within enterprise networks is that of a + model of access, where the clients service tariff is based on the + characteristics of access to the services, rather than that of the + actual use of the service. The introduction of QoS services creates + a strong impetus to move to usage-based tariffs, where the tariff is + based on the level of use of the network's resources. This, in turn, + generates a requirement to meter resource use, which is a form of + usage accounting. This topic was been previously studied within the + + + +Huston Informational [Page 15] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + IETF under the topic of "Internet Accounting" [11], and further + refinement of the concepts used in this model, as they apply to QoS + accounting may prove to be a productive initial step in formulating a + standards-based model for QoS accounting. + +3.10 QoS Deployment Diversity + + It is extremely improbable that any single form of service + differentiation technology will be rolled out across the Internet and + across all enterprise networks. + + Some networks will deploy some form of service differentiation + technology while others will not. Some of these service platforms + will interoperate seamlessly and other less so. To expect all + applications, host systems, network routers, network policies, and + inter-provider arrangements to coalesce into a single homogeneous + service environment that can support a broad range of service + responses is an somewhat unlikely outcome given the diverse nature of + the available technologies and industry business models. It is more + likely that we will see a number of small scale deployment of service + differentiation mechanisms and some efforts to bridge these + environments together in some way. + + In this heterogeneous service environment the task of service + capability discovery is as critical as being able to invoke service + responses and measure the service outcomes. QoS architectures will + need to include protocol capabilities in supporting service discovery + mechanisms. + + In addition, such a heterogeneous deployment environment will create + further scaling pressure on the operational network as now there is + an additional dimension to the size of the network. Each potential + path to each host is potentially qualified by the service + capabilities of the path. While one path may be considered as a + candidate best effort path, another path may offer a more precise + match between the desired service attributes and the capabilities of + the path to sustain the service. Inter-domain policy also impacts + upon this path choice, where inter-domain transit agreements may + specifically limit the types and total level of quality requests than + may be supported between the domains. Much of the brunt of such + scaling pressures will be seen in the inter-domain and intra-domain + routing domain where there are pressures to increase the number of + attributes of a routing entry, and also to use the routing protocol + in some form of service signaling role. + + + + + + + +Huston Informational [Page 16] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + +3.11 QoS Inter-Domain signaling + + QoS Path selection is both an intra-domain (interior) and an inter- + domain (exterior) issue. Within the inter-domain space, the current + routing technologies allow each domain to connect to a number of + other domains, and to express its policies with respect to received + traffic in terms of inter-domain route object attributes. + Additionally, each domain may express its policies with respect to + sending traffic through the use of boundary route object filters, + allowing a domain to express its preference for selecting one + domain's advertised routes over another. The inter-domain routing + space is a state of dynamic equilibrium between these various route + policies. + + The introduction of differentiated services adds a further dimension + to this policy space. For example, while a providers may execute an + interconnection agreement with one party to exchange best effort + traffic, it may execute another agreement with a second party to + exchange service qualified traffic. The outcome of this form of + interconnection is that the service provider will require external + route advertisements to be qualified by the accepted service + profiles. Generalizing from this scenario, it is reasonable to + suggest that we will require the qualification of routing + advertisements with some form of service quality attributes. This + implies that we will require some form of quality vector-based + forwarding function, at least in the inter-domain space, and some + associated routing protocol can pass a quality of service vector in + an operationally stable fashion. + + The implication of this requirement is that the number of objects + being managed by routing systems must expand dramatically, as the + size and number of objects managed within the routing domain + increases, and the calculation of a dynamic equilibrium of import and + export policies between interconnected providers will also be subject + to the same level of scaling pressure. + + This has implications within the inter-domain forwarding space as + well, as the forwarding decision in such a services differentiated + environment is then qualified by some form of service quality vector. + This is required in order to pass exterior traffic to the appropriate + exterior interconnection gateway. + +3.12 QoS Deployment Logistics + + How does the widespread deployment of service-aware networks + commence? Which gets built first - host applications or network + infrastructure? + + + + +Huston Informational [Page 17] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + No network operator will make the significant investment in + deployment and support of distinguished service infrastructure unless + there is a set of clients and applications available to make + immediate use of such facilities. Clients will not make the + investment in enhanced services unless they see performance gains in + applications that are designed to take advantage of such enhanced + services. No application designer will attempt to integrate service + quality features into the application unless there is a model of + operation supported by widespread deployment that makes the + additional investment in application complexity worthwhile and + clients who are willing to purchase such applications. With all + parts of the deployment scenario waiting for the others to move, + widespread deployment of distinguished services may require some + other external impetus. + + Further aspects of this deployment picture lie in the issues of + network provisioning and the associated task of traffic engineering. + Engineering a network to meet the demands of best effort flows + follows a well understood pattern of matching network points of user + concentrations to content delivery network points with best effort + paths. Integrating QoS-mediated traffic engineering into the + provisioning model suggests a provisioning requirement that also + requires input from a QoS demand model. + +4. The objective of the QoS architecture + + What is the precise nature of the problem that QoS is attempting to + solve? Perhaps this is one of the more fundamental questions + underlying the QoS effort, and the diversity of potential responses + is a pointer to the breadth of scope of the QoS effort. + + All of the following responses form a part of the QoS intention: + + - To control the network service response such that the response + to a specific service element is consistent and predictable. + + - To control the network service response such that a service + element is provided with a level of response equal to or above a + guaranteed minimum. + + - To allow a service element to establish in advance the service + response that can or will be obtained from the network. + + - To control the contention for network resources such that a + service element is provided with a superior level of network + resource. + + + + + +Huston Informational [Page 18] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + - To control the contention for network resources such that a + service element does not obtain an unfair allocation of + resources (to some definition of 'fairness'). + + - To allow for efficient total utilization of network resources + while servicing a spectrum of directed network service outcomes. + + Broadly speaking, the first three responses can be regarded as + 'application-centric', and the latter as 'network-centric'. It is + critical to bear in mind that none of these responses can be + addressed in isolation within any effective QoS architecture. Within + the end-to-end architectural model of the Internet, applications make + minimal demands on the underlying IP network. In the case of TCP, + the protocol uses an end-to-end control signal approach to + dynamically adjust to the prevailing network state. QoS + architectures add a somewhat different constraint, in that the + network is placed in an active role within the task of resource + allocation and service delivery, rather than being a passive object + that requires end systems to adapt. + +5. Towards an end-to-end QoS architecture + + The challenge facing the QoS architecture lies in addressing the + weaknesses noted above, and in integrating the various elements of + the architecture into a cohesive whole that is capable of sustaining + end-to-end service models across a wide diversity of internet + platforms. It should be noted that such an effort may not + necessarily result in a single resultant architecture, and that it is + possible to see a number of end-to-end approaches based on different + combinations of the existing components. + + One approach is to attempt to combine both architectures into an + end-to-end model, using IntServ as the architecture which allows + applications to interact with the network, and DiffServ as the + architecture to manage admission the network's resources [7]. In + this approach, the basic tension that needs to be resolved lies in + difference between the per-application view of the IntServ + architecture and the network boundary-centric view of the DiffServ + architecture. + + One building block for such an end-to-end service architecture is a + service signaling protocol. The RSVP signaling protocol can address + the needs of applications that require a per-service end-to-end + service signaling environment. The abstracted model of RSVP is that + of a discovery signaling protocol that allows an application to use a + single transaction to communicate its service requirements to both + the network and the remote party, and through the response mechanism, + to allow these network elements to commit to the service + + + +Huston Informational [Page 19] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + requirements. The barriers to deployment for this model lie in an + element-by element approach to service commitment, implying that each + network element must undertake some level of signaling and processing + as dictated by this imposed state. For high precision services this + implies per-flow signaling and per-flow processing to support this + service model. This fine-grained high precision approach to service + management is seen as imposing an unacceptable level of overhead on + the central core elements of large carrier networks. + + The DiffServ approach uses a model of abstraction which attempts to + create an external view of a compound network as a single subnetwork. + From this external perspective the network can be perceived as two + boundary service points, ingress and egress. The advantage of this + approach is that there exists the potential to eliminate the + requirement for per-flow state and per-flow processing on the + interior elements of such a network, and instead provide aggregate + service responses. + + One approach is for applications to use RSVP to request that their + flows be admitted into the network. If a request is accepted, it + would imply that there is a committed resource reservation within the + IntServ-capable components of the network, and that the service + requirements have been mapped into a compatible aggregate service + class within the DiffServ-capable network [7]. The DiffServ core + must be capable of carrying the RSVP messages across the DiffServ + network, so that further resource reservation is possible within the + IntServ network upon egress from the DiffServ environment. The + approach calls for the DiffServ network to use per-flow multi-field + (MF) classifier, where the MF classification is based on the RSVP- + signaled flow specification. The service specification of the RSVP- + signaled resource reservation is mapped into a compatible aggregate + DiffServ behavior aggregate and the MF classifier marks packets + according to the selected behavior. Alternatively the boundary of + the IntServ and DiffServ networks can use the IntServ egress to mark + the flow packets with the appropriate DSCP, allowing the DiffServ + ingress element to use the BA classifier, and dispense with the per- + flow MF classifier. + + A high precision end-to-end QoS model requires that any admission + failure within the DiffServ network be communicated to the end + application, presumably via RSVP. This allows the application to + take some form of corrective action, either by modifying it's service + requirements or terminating the application. If the service + agreement between the DiffServ network is statically provisioned, + then this static information can be loaded into the IntServ boundary + systems, and IntServ can manage the allocation of available DiffServ + behavior aggregate resources. If the service agreement is + + + + +Huston Informational [Page 20] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + dynamically variable, some form of signaling is required between the + two networks to pass this resource availability information back into + the RSVP signaling environment. + +6. Conclusions + + None of these observations are intended to be any reason to condemn + the QoS architectures as completely impractical, nor are they + intended to provide any reason to believe that the efforts of + deploying QoS architectures will not come to fruition. + + What this document is intended to illustrate is that there are still + a number of activities that are essential precursors to widespread + deployment and use of such QoS networks, and that there is a need to + fill in the missing sections with something substantial in terms of + adoption of additional refinements to the existing QoS model. + + The architectural direction that appears to offer the most promising + outcome for QoS is not one of universal adoption of a single + architecture, but instead use a tailored approach where aggregated + service elements are used in the core of a network where scalability + is a major design objective and use per-flow service elements at the + edge of the network where accuracy of the service response is a + sustainable outcome. + + Architecturally, this points to no single QoS architecture, but + rather to a set of QoS mechanisms and a number of ways these + mechanisms can be configured to interoperate in a stable and + consistent fashion. + +7. Security Considerations + + The Internet is not an architecture that includes a strict + implementation of fairness of access to the common transmission and + switching resource. The introduction of any form of fairness, and, + in the case of QoS, weighted fairness, implies a requirement for + transparency in the implementation of the fairness contract between + the network provider and the network's users. This requires some + form of resource accounting and auditing, which, in turn, requires + the use of authentication and access control. The balancing factor + is that a shared resource should not overtly expose the level of + resource usage of any one user to any other, so that some level of + secrecy is required in this environment + + The QoS environment also exposes the potential of theft of resources + through the unauthorized admission of traffic with an associated + service profile. QoS signaling protocols which are intended to + + + + +Huston Informational [Page 21] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + undertake resource management and admission control require the use + of identity authentication and integrity protection in order to + mitigate this potential for theft of resources. + + Both forms of QoS architecture require the internal elements of the + network to be able to undertake classification of traffic based on + some form of identification that is carried in the packet header in + the clear. Classifications systems that use multi-field specifiers, + or per-flow specifiers rely on the carriage of end-to-end packet + header fields being carried in the clear. This has conflicting + requirements for security architectures that attempt to mask such + end-to-end identifiers within an encrypted payload. + + QoS architectures can be considered as a means of exerting control + over network resource allocation. In the event of a rapid change in + resource availability (e.g. disaster) it is an undesirable outcome if + the remaining resources are completely allocated to a single class of + service to the exclusion of all other classes. Such an outcome + constitutes a denial of service, where the traffic control system + (routing) selects paths that are incapable of carrying any traffic of + a particular service class. + +8. References + + [1] Bradner, S., "The Internet Standards Process- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., + Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) + Version 1 Applicability Statement", RFC 2208, September 1997. + + [3] Braden. R., Clark, D. and S. Shenker, "Integrated Services in + the Internet Architecture: an Overview", RFC 1633, June 1994. + + [4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. + Weiss, "An Architecture for Differentiated Services", RFC 2475, + December 1998. + + [5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B., + "Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in + Progress. + + [6] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, + November 2000. + + + + + + + +Huston Informational [Page 22] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + + [7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, + M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A + Framework for Integrated Services Operation Over DiffServ + Networks", RFC 2998, November 2000. + + [8] "Quality of Service Technical Overview", Microsoft Technical + Library, Microsoft Corporation, September 1999. + + [9] "Resource Reservation Protocol API (RAPI)", Open Group Technical + Standard, C809 ISBN 1-85912-226-4, The Open Group, December + 1998. + + [10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data + Flows", RFC 2007, September 1997. + + [11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting: + Background", RFC 1272, November 1991. + +9. Acknowledgments + + Valuable contributions to this document came from Yoram Bernet, Brian + Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne. + +10. Author's Address + + Geoff Huston + Telstra + 5/490 Northbourne Ave + Dickson ACT 2602 + AUSTRALIA + + EMail: gih@telstra.net + + + + + + + + + + + + + + + + + + + +Huston Informational [Page 23] + +RFC 2990 Next Steps for QoS Architecture November 2000 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Huston Informational [Page 24] + |