Network Working Group Anders Bergsten, TRAB INTERNET-DRAFT Krisztian Nemeth, BUTE Expiration Date: January 2002 Istvan Cselenyi, TRAB Gabor Feher, BUTE July 2001 Fundamental Questions Regarding End-to-End QoS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This short memo aims to discuss the different functions and topological areas of an internetwork, where some kind of enhancements are required in order to provide predictable end-to-end quality of service (QoS) to customers. These enhancements require (1) the exchange of QoS-related information and (2) enforcement of QoS-related decisions. This can be, but not necessarily is, done by some existing or new signaling protocols. The following five points are identified: 1) The access network: the probability of congestion is the highest in the access network, thus it is very likely that some kind of mechanism supporting the QoS instantiation is necessary here 2) End-to-end signaling between applications: we believe that a high level information exchange must be the first step of a QoS session initiation in several cases 3) Inter-domain communication, particularly on a peering link: an automatic service announcement is needed, something like BGP, but with QoS enhancements. In addition, it is considerable to have a Bergsten et al. Expires January 2002 [Page 1] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 mechanism, which actually provides inter-domain provisioning of these resources. 4) Identifying, which customer to penalize in case of a network congestion: when a severe congestion occurs and a contract has to be breached, it should be under the control of the network provider (through policies) which contract to breach. It should be considered both as a technical and a business problem, which customer to turn down. 5) Providing requirement information from customers: Customers could inform the service providers about the current and intended network utilization, specifying for example the expected destinations and traffic volumes. The operator could then use this knowledge to dimension its network better, and also to calculate the amount of services to buy from the neighboring operators. 1. Introduction Looking from the perspective of the end-user, a predictable end-to- end quality of service seems to be the most beneficial facility in the whole QoS (quality of service) concept. Consequently the network providers should aim for making this type of service available to the user. DiffServ (Differentiated Services [1]) gives us the fundamental building blocks to achieve service differentiation. This alone can take us very far. Differentiated Services provides means to separate (i.e., the Per Hop Behavior, PHB), to police and to describe service components (i.e., the Per Domain Behavior, PDB). These are all the basic, but mandatory ingredients for QoS provisioning. Furthermore, DiffServ also gives us a couple of more architectural ingredients: the contractual agreement (i.e., the Service Level Agreement, SLA) and the assumption that an ISP (Internet Service Provider) must be knowledgeable enough to provision its network correctly. Given the ability to separate, provision the network correctly and to write contracts between parties is enough for QoS -- as seen from an operator's perspective. However, to achieve end-to-end service quality, several pieces of the "QoS pie" seem to be missing from this point of view. At this point we would also like to acknowledge that the implicit method used in todayÆs Internet [2] should play a fundamental role also in the future, even for IP QoS. After a contract has been signed the probability of blocking in a domain is designed to be extremely low (0.01 to 0.00001) during normal operations. Thus, blocked flows are the exception rather than the rule, why we are looking into an architecture that takes the implicit method as a starting point for customers. Bergsten et al. Expires January 2002 [Page 2] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 In this short memo we try to identify those places in the network architecture, where some enhancements are required, or at least could be beneficial in order to achieve end-to-end QoS. In the third section, we detail our list of these places. 2. Scenario Our targeted scenario is the "public" Internet of the near future, we do not aim for special IP networks, like for example mobile telephony carriers over IP. There are four fundamental players in the QoS game. The two customer sides that are communicating, the operators that sign contracts with the customers and the network that supply the resources. Of course, there may be more than four physical (or logical) players performing these roles. Using this network, users run the same applications as today, plus some QoS-demanding ones, just like IP-telephony, web-TV, etc. The structure of the network is coming from the Internet architecture we have today: there are several Internet Service Providers and each has its own network, which are connected to other providers enabling connectivity for the whole Internet. From the user's perspective the network consists of an access network, which is his or her local Internet Service Provider. The network node with which the user is communicating resides in the far end access network. Between these there might be several transit domains owned by different operators, over which the communication goes through. We also assume that premium services that the network operators offer to customers in the near future have similar characteristics and also based on the services that we have today. In this memo we describe two different types of such premium services, and study the end-to-end QoS provisioning issues considering these two types only. 2.1 Corporate Service First, there is a service, which is very similar to the Virtual Private Network (VPN) service. The main attributes of this service are: the Service Provider guarantees some QoS bounds for the customer's traffic that is targeted to a known set of network domains; the customer is responsible for its traffic, which should not exceed the agreed limits; the customer and the operator makes a contract (Service Level Agreement, SLA), which is valid for a reasonable long time period. This type of premium service is ideal for companies, who frequently require the QoS guarantees, or would like to build up VPNs among distant network nodes (e.g. branch offices). That is the customer of this service can continuously expect the same QoS for his macro-service. Bergsten et al. Expires January 2002 [Page 3] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 2.2 Consumer Service Second, we can imagine a premium service, which is similar to current prepaid telephone-card based calling service. In this case the customer shall subscribe to the ability of using premium service (buy the phone card). Than whenever he wants to have a service session, he can request it as long as there are units on the phone card. This type of service in our model is for the majority of users. It is not based on quasi-permanent SLAs, but it supports the setup of dynamic QoS sessions. Examples can be a video watching session downloading the film from a digital library or a distributed game- party. These sessions are always preceded by an explicit setup request sent from the endpoint to its local ISP. It is the ISP's responsibility to handle these requests. After the end of the session, it is torn down. Probably the biggest difference compared to the corporate service is that these requests can be accepted or denied at the initiation time in case of not enough resources. However, since customers certainly do not like blocked services, it is the responsibility of the network operator to provision its network to achieve low consumer service blocking probability. Certainly the tradeoff between the service blocking probability and the network utilization is also a business-related issue. 3. Possible places of enhancements 3.1 The access network Problem statement: The access network is perhaps the most critical from the QoS perspective. The number of contracts (one for each end-user and for each peering domain) is the highest and the traffic demand is the least predictable here. In addition, the peak and average data rate generated by the end-users are usually very different from each other, meaning a relative high peak but low average utilization. Because of these issues, overprovisioning is generally not a solution in IP access networks. Another consequence is that the access is still the bottleneck, where most of the congestion occurs. Thus, some way of QoS control mechanism seems to be needed in the access networks. Moreover, in some cases, like for example shared cable-TV access links, the lower network layers also demand QoS support mechanisms. To sum up, here we need communication between the customer and the access network (and the far-end customer and his access network), and both information exchange and QoS enforcement is needed. Discussion: For the corporate service probably no signaling is necessary. After the contract has been signed (meaning that the network can cope with Bergsten et al. Expires January 2002 [Page 4] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 the new amount of traffic) the network has to be configured once. After instantiation some form of traffic engineering might be used to prevent congestion. This can be very useful if the network operator wants to control the resources in its network, and signaling might also be handy to support the traffic engineering. However, even if the customer informs the local access network about his or her resource demand and enforces the allocation of that, there may be problems in the far-end access network. For this reason, the mechanisms applied in access networks should also support session setup requests coming from the direction the core network. For the customer service type signaling based resource reservation seems to be more adequate since this gives tighter control of resources. The endpoints should provide some information about their requirements, and the ISP must accept or reject the setup request and in the former case should inform the user about the price for the service as well. 3.2 Application-to-application information exchange Problem Statement: The goal of this type of communication is to have means for the applications/users to inform each other and to negotiate about a QoS session, prior to its establishment. Thus, here the information exchange is done between the two customer sites; the QoS enforcement is optional. Discussion: In most of the cases this involves something more than just agreeing upon the fact of a new session setup. For example before starting to watch a movie (video on demand), the user may wish to choose among different qualities and prices. (Note, the same kind of choice is already available in some telephone networks, where for long distance calls the users may choose between the traditional phone connection or the IP-based one, where the latter is cheaper but is of worse quality.) Application settings might also be negotiated here, which are dependent for example on the hardware equipment of the endpoints (e.g. support for video transmission for an IP phone session makes sense only if the users have got a camera). As partly mentioned already, charging information may also form part of this communication, as for example it has to be agreed who pays for the session. This may involve the participation of a third party, who -- on behalf of the operator -- informs the users about the price of the service in question. Without going into details of the possible realizations, we can state that it will most probably be application specific. It can Bergsten et al. Expires January 2002 [Page 5] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 also be mentioned, that existing protocols, such as SIP could be used for this purpose. 3.3 Inter-domain signaling Problem Statement: Quality of service is an end-to-end problem. The customer needs to understand what he is buying, in order to decide about what service to buy and from which operator. Thus the service provider should supply the end-to-end QoS parameters of an offered session. We discuss two issues here: 1) how to announce the service promises between operators end-to-end 2) how to enforce the accepted promise per domain The information exchange happens between operators. QoS enforcing is per domain. Discussion: (1) For announcing promises end-to-end Many operators today describe the best effort service that is being sold to their customers. This is done in the contract between the parties, and also as an advertisement on a web page for example. The quality (delay and packet loss) that the customer will receive in the domain in question is described in the contract. Note that we wrote "the domain in question". This is one of the fundamental problems of the Internet QoS today that the promise only deals with one domain and not the entire path. A chain of domains (building up and end-to-end service), that all separately describe the service they deliver, will nevertheless not be able to state what the end-to-end QoS will be as there is no control of the entire path. BGP [3] solve this problem for the simplest service -- connectivity. The equivalent in QoS, which is the metrics by which the service is described, is not transported the same way. Thus, there is a need for a protocol that is able to collect the promises for QoS parameters that each ISP is making and thereby forming an end-to-end description of the service. Note that we deliberately use "promises", as this is a much simpler problem to deal with than to take into account what the actual delay and packet loss is. (2) For enforcing promises per domain While there is a definite need for a mechanism that describes the expected end-to-end QoS parameters for the customers, it is also a natural idea to think about a mechanism, which actually provides inter-domain provisioning of these resources. Bergsten et al. Expires January 2002 [Page 6] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 This would mean some way of automated SLA generation and processing. This could happen on a peering link between two neighboring domains only, or these service level agreements could form a larger scale, multi-provider, quasi-dynamic resource provisioning system. This certainly would run on a much larger time-scale than the dynamic provisioning; SLA's would be modified in a weekly/monthly basis for example. 3.4 Business oriented congestion control Problem Statement: As we operators are selling services, we bind ourselves to contracts that we should fulfill or otherwise some form of penalty will come into play. We are now talking about the case where the already admitted sessions cannot be served fully. This might happen due to a partial network failure or due to bad provisioning. The basic idea here is to insert some kind of policy into the QoS congestion control. When a severe congestion occurs then probably a contract has to be breached. It is both a technical and a business problem which customer to turn down in this case, but the conditions are not given today so that business considerations could be taken into account during this decision. These considerations would require the knowledge of the contracts, and also the history of events, i.e., when and which customers we have already denied service to. In this case information exchange and QoS enforcement is done within a network domain. Discussion: In the case of DiffServ if the contracts are broken, it can happen in either controlled or un-controlled way. The un-controlled method is what we would call "pure" DiffServ (i.e. DiffServ as it is today, with no extra functionality). The higher packet loss or delay will be seen by all customers that share the over-utilized resource. A possible approach that an operator can take in this case is to degrade some of the flows going through the congestion. Treating these flows artificially worse (e.g. drop/remark/delay its packets at the domain border) might relieve the congestion and thus help the operator to keep the contract for the rest of the flows. For the selection of the blocked flows we can use a policy, which takes into account both technical and business-oriented aspects. In this case an end-to-end signaling might help to identify the customers related to the data flows. 3.5 Supplying requirement information from the customers to the providers Bergsten et al. Expires January 2002 [Page 7] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 Problem Statement: It is beneficial for the operator to have some information about the current and future demand of the customers in order to provision his network and prepare it for the future challenges, including buying services from neighboring operators (peering). Customers could inform the service providers about the current and intended network utilization, specifying for example the expected destinations and traffic volumes. This is needed on per customer basis (and not per flow, neither per behavior aggregate). Apart from this customer-operator information exchange, no immediate QoS enforcement happens. Discussion: Today, an operator can guess the user demand by looking at aggregate statistics of link utilization. That is, bandwidth usage and possibly some more statistics. Another mean for an operator to do it, if signaling is used, is to collect statistics of the signaling protocols (RSVP [4], for example). With DiffServ an operator can only use the first method which might be a problem if end-to-end congestion control is being used. The demand of users, however, might differ from the actual throughput that shows up on a single link. For example, due to an upstream congestion a downstream operator will not see the real demand. When the upstream congestion has cleared there is risk that the congestion will only move to another place in the network. Thus, to understand the resource need of users, there might be a reason to explore if it is possible to construct a "resource demand" information signaling protocol. Then there would exist a simple mean for the operator to figure out what requirements the users have. Although such a mechanism seems undoubtedly useful, it has to be noted that the significance of this method is very hard to foresee. Currently it is also not straightforward, how the customers would generate the traffic forecast data. It should also be mentioned that such a protocol might be subject to misuse. For example, if used naively, it might be tricked to fool an ISP to make more resources available towards certain areas of the Internet where capacity is not actually needed. 4. Legacy solutions Certainly we did not want to reinvent the wheel, nor protocols for that matter. There are many legacy solutions that can cover parts of the aforementioned problems. Nevertheless, it is always good to look at the requirements first and then to identify the solutions. Bergsten et al. Expires January 2002 [Page 8] INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001 Looking at existing specific solutions that can solve parts of the problems is out of the scope of this memo. 5. Security Considerations We tried to address problems and not their solutions; thus security considerations are not addressed in this memo. 6. References [1] Blake S. et al., "An architecture for Differentiated Services", RFC 2475 [2] Crowcroft J., mail to SigLite mailing list 09/01/2001 16:30 http://lists.cs.columbia.edu/mailman/listinfo/siglite [3] Rekhter Y. and Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771 [4] Braden R. (Ed), "A Resource reSerVation Protocol (RSVP) Version 1 Functional Specification", RFC 2205 7. Acknowledgments The authors would like to acknowledge the helpful discussions with Niklas Borg, Peter Fuzesi and Rikard Holmberg. 8. Author's Addresses Anders Bergsten Telia Research AB Aurorum 6; 977 75 Lulea; Sweden Phone: +46 920 754 50 E-mail: Anders.P.Bergsten@telia.se Krisztian Nemeth Budapest University of Technology and Economics Department of Telecommunications and Telematics Pßzmßny P. s. 1/D.; H-1117 Budapest; Hungary Phone: +36 1 463 3119 E-mail: nemeth_k@ttt-atm.ttt.bme.hu Istvan Cselenyi Telia Research AB Vitsandsgatan 9; S-12386 Farsta; Sweden Phone: +46 8 713 8173 E-mail: Istvan.I.Cselenyi@telia.se Gabor Feher Budapest University of Technology and Economics Department of Telecommunications and Telematics Pßzmßny P. s. 1/D.; H-1117 Budapest; Hungary Phone: +36 1 463 2187 E-mail: feher@ttt-atm.ttt.bme.hu Bergsten et al. Expires January 2002 [Page 9]