Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT S. Shenker/C. Partridge draft-ietf-intserv-control-del-svc-00.txt Xerox/BBN March, 1995 Expires: 9/1/95 Specification of Controlled Delay Quality of Service Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes the expected behavior of a controlled delay service in the Internet. The memo follows the service template model of specifying per-network-element behavior, end-to-end behavior, and evaluation requirements. Introduction This memo is the first of what is expected to be a series of Service Definitions for quality of service in the Internet. This memo defines a controlled delay service. In particular, it defines requirements for network elements that support this service. It does not specify how end-to-end setup mechanisms establish their service, except to define what information each element requires to establish the service at that element and what information each element may advertise in return. The document uses the terms "network element" and "element" to mean Shenker/Partridge Expires 9/1/95 [Page 1] INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995 any component of the internetwork which is capable of exercising QOS control over data flowing through it. Network elements might include routers, QOS-aware subnetworks, and end-note operating systems. This document is a product of the Integrated Services working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at intserv@isi.edu and/or the author(s). Motivation Controlled delay service is designed for service and delay adaptive applications; i.e., applications that are prepared to adapt to changing delays and to change their service request (after they have started receiving) if the current service level is not adequate. This service does not provide any quantified level of assurance. Instead, it merely promises to avoid overloads by turning excess flows away. The criterion for determining overloads is not specified. Thus, while this service controls delay, it does not make any specific assurances about delay. This service is subject to admission control. Per-hop Service The network element must assure that the packet delays are controlled. This control must be active, in that the element must be able to control admissions to the element. In particular, overprovisioning is not sufficient to deliver controlled delay service. However, no quantitative specification of the maximal delays are given. There are three different logical levels of service; a switch can implement fewer actual levels of service, but must treat them as three logical levels. The levels have different levels of delay control, with level 1 having the most tightly controlled delay, and level 3 having the least tightly controlled delay. The different levels do not have to give strictly ordered delays for each packet; that is, the network element need not ensure that every packet given level 1 service experiences less delay than if it were given level 2 service. The element need only ensure that the typical delays are no greater in level 1 than in level 2 (and similarly for levels 2 and 3). Advertisements The network element is not required to advertise any information about the service to the setup mechanism used to establish end-to-end service. It is assumed that the receiving application is measuring Shenker/Partridge Expires 9/1/95 [Page 2] INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995 the delays it experiences and will adapt, either by changing its playback time, or by changing levels of service if the delays are unacceptable. However, as a hint about current delays, the instantaneous delay may optionally be advertised for each service level (1, 2 and 3). This advertisement has an additive composition rule; the delay at each hop is added to the current cumulative delay along the path. There is no exact specification of how the instantaneous delay must be measured. However, since the maximal delays are typically more important than the average delays, the advertised quantity should reflect the extremal values of delay. If a network element does not measure its instantaneous delays and any setup mechanisms that wish to estimate the instantaneous delay should treat the element as having a modest fixed delay. [Neither author is sure that this sentence belongs here -- but we need some consistent rule about what setup mechanisms do if some elements don't cooperate] Traffic Specification and Policing Traffic is described by a token bucket filter (tbf), which is specified by a token bucket depth r and a token bucket rate b. Policing is done at the edge of the network and at all source merge points. (A source merge point is where data from multiple different sources is merged into a single flow). Nonconforming packets are dropped. Invocation Service is invoked by specifying the traffic (TSpec) and service (RSpec) to the network element The TSpec is a token bucket depth r and a token bucket rate b. Both r and b must be positive. The RSpec is a target delay, or a service level, or both. The service level is specified by one of the integers 1, 2, or 3. A target delay is specified by positive value. The service module can map the target-delay into a service level with any monotonic mapping; for instance, if a target delay td1 maps into service level 2, then all target delays greater than td1 must map into service levels 2 or 3. This mapping is local to each network element; the mappings at different elements can be different. However, the mapping is static, in that it does not change over time. Shenker/Partridge Expires 9/1/95 [Page 3] INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995 Either or both of the possible forms of RSpec can be specified. If both are specified then the more stringent service, as determined by the network element, is used (i.e., they both map into a service level, and then the lowest service level is used). The form of request where both are specified is necessary when merging reservation requests. Ordering The TSpec's are ordered as follows; both the token bucket depth and rate must be greater than or equal in order for the TSpec to be greater than or equal. The RSpec's are ordered by their numerical values (in inverse order). If both the target-delay and service- level are specified, then both must be greater than or equal for the RSpec to be greater than or equal. Ordering is relevant to the merging of reservation requests. Resulting Service The resulting end-to-end service is one that offers applications several levels of delay to choose from. So an adaptive application that is unhappy with its current level of delay can move to a better level of delay to try to improve service (or to a lesser level, if the service currently being received is better than is needed). Furthermore, this service promises that the levels of experienced delays will be controlled. However, this service makes no assurances about the absolute levels of delay or jitter the receiving application will experience. Evaluation Criteria Showing that a network element implements a controlled delay service is somewhat difficult, since the quality of service depends on overall traffic load, the traffic pattern presented and the degree of delay control implemented. In this section we sketch out a methodology for testing an element's controlled delay service. The idea is that one chooses a particular traffic mix (for instance, three parts level 1, one part level 2, two parts level 3 and the rest is best-effort traffic) and loads the network element with progressively higher levels of this traffic mix (i.e., 40% of capacity, then 50% of capacity, on up to near 100% capacity, or beyond 100% capacity, provided all traffic in excess of full loading is best effort traffic that can be discarded). For each load level, one measures the mean delays and the packet loss rate for each level of service (including best effort). Each test run at a particular load should involve enough traffic that is a reasonable predictor of the performance a long-lived application such as a video conference Shenker/Partridge Expires 9/1/95 [Page 4] INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995 would experience (e.g., several minutes of traffic). A conformant network element will show a distinct difference in mean delays for level 1 service and best-effort service as loads increase towards 100%, with level 1 service always getting the lower delay. This should be true over a broad range of traffic mixes. Delays for levels 2 and 3 traffic will fall between level 1 and best effort. The level 2 and 3 delays can be equal to the level 1 delay, but must be less than the best effort delay at higher loads. The level 2 and 3 delays are also subject to the condition that the delay for level 2 traffic must be less than or equal to the delay for level 3 traffic. This memo does not specify particular traffic mixes to test, however, we expect in the future that as the nature of real-time Internet traffic is better understood, some suggested traffic mixes will be proposed. For present purposes, it is sufficient for a network element to demonstrate it effectively distinguishes delay for a few different traffic mixes. Security Considerations Security considerations are not discussed in this memo. Authors' Address: Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 shenker@parc.xerox.com 415-812-4840 415-812-4471 (FAX) Craig Partridge BBN 2370 Amherst St Palo Alto CA 94306 craig@bbn.com Shenker/Partridge Expires 9/1/95 [Page 5]