Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT S. Shenker/C. Partridge draft-ietf-intserv-guaranteed-svc-01.txt Xerox/BBN July 1995 Expires: 12/1/95 Specification of Guaranteed 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 network element behavior required to deliver guaranteed service in the Internet. The memo follows the service template model of specifying per-network-element behavior, guidelines, and evaluation requirements. 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 int- serv@isi.edu and/or the author(s). Introduction This memo is one of a series of documents which specify network element behavior in IP internetworks which provide multiple qualities of service. This memo defines a guaranteed service. In particular, it defines Shenker/Partridge Expires 12/1/95 [Page 1] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 requirements for network elements that support this service. It follows the service template specified in [XXX]. Readers should refer to that document for additional details about the specification of qualities of service for IP internetworks. Motivation A guaranteed service provides firm (mathematically provable) guarantees that the end-to-end delay experienced by packets in a flow will not exceed a set limit, assuming that all service elements in the flow's path support guaranteed service. We also assume that there are no hard failures in the intermediate nodes or packet routing changes within the lifetime of the flow. Failure cases must be handled by higher protocols. This service is designed for applications which are intolerant of any loss and any applications with hard real-time requirements. This service guarantees that packets will arrive within the guaranteed delivery time and will not be discarded due to queue overflows. Authors of playback applications should note that packets will often arrive far earlier than the delivery deadline and will have to buffered at the receiving system until it is time for the application to process them. Network Element Data Handling Requirements The network element must ensure that the service matches the "fluid model" of service (as discussed in [XXX]). The flow's level of service is characterized at each network element by a bandwidth R and a buffer size B. R represents the share of the link's bandwidth the flow is entitled to and B represents the buffer space in the router that the flow may consume. The network element must ensure that its service matches the fluid model at that same rate to within a sharp error bound. The fluid delay of a flow obeying a token bucket (r,b) and being served by a line with bandwith R is given by b/R as long as R is no less than r. The network element must ensure that the delay of any packet be less than b/R+C/R+D where C and D describe the maximal deviation away from the fluid model. For instance, for Weighted Fair Queueing, C is given by MTU of the outbound link and D is zero. The assurance that packets will not be lost is obtained by setting the router buffer space B to be equal to the token bucket b plus some error term. Shenker/Partridge Expires 12/1/95 [Page 2] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 NOTE: the mathematics of buffer space are not fully worked out and this last sentence may be wrong. Invocation Information Service is invoked by specifying the traffic (TSpec) and the desired service (RSpec) to the network element. The TSpec takes the form of a token bucket, with a bucket depth, b, and a bucket rate, r. Both b and r must be positive. The rate, r, is measured in bytes per 1/100th of a second, and can range from 1 to 10^12. This range allows data rates as small as 800 bits per second (a reasonable minimum) as well as data rates as large as 800 terabits per second (or 10 times what is believed to be the maximum theoretical bandwidth of a single strand of fiber) to be requested. Clearly, particularly for large bandwidths, only the first few digits are significant and so the use of floating point representations, accurate to at least 0.1% is encouraged. The bucket depth, b, is measured in bytes and can range from 1 byte to 250 gigabytes. Again, floating point representations accurate to at least 0.1% are encouraged. The range of values is intentionally large to allow for the future bandwidths. The range is not intended to imply that a network element must support the entire range. The RSpec is a rate R, where R must be greater than or equal to r. The RSpec rate can be bigger than the TSpec rate because higher rates will reduce queueing delay. No buffer specification is included in the RSpec because the service element is expected to derive the required buffer space to ensure no queueing loss from the bucket size in the TSpec, the rate in the RSpec, combined with internal information about how the element manages its traffic. The TSpec can be represented by two 16-bit values each using the following form: 15 10 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exponent | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this format, the 6 most significant bits of the word encode an exponent (E), and the 10 LSB's encode a value (V). This format encodes a number, of the form V * (2**E). This format is chosen to allow easy representation of a wide range of values, while avoiding over-precise representations. The 16-bit word is placed into packets Shenker/Partridge Expires 12/1/95 [Page 3] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 in network byte order. The first value is the rate (r) and the second value is the bucket size (b). The RSpec rate, R, can use the same representation. Exported Information Each guaranteed service module must export at least the following information. All of the parameters described below are characterization parameters. A flow's service is characterized by two error terms, C and D, which represent how the element's implementation of the guaranteed service deviates from the fluid model. These two parameters have an additive composition rule. For both parameters, the composition function computes the sum of the parameter values (Ctot and Dtot) across all network elements in the path and delivers this value to the end nodes. Furthermore, (see the section on Policing below), intermediate values of Ctot and Dtot need to be delivered to policing points to ensure no queueing loss. The error term C is measured in units of bytes. An individual element can advertise a delay value between 1 and 2**28 (a bit over 250 megabytes) and the total added all elements can range as high as 2**32-1. Should the sum of the different elements delay exceed 2**32-1, the end-to-end error term should be 2**32-1. The error term D is measured in units of one microsecond. An individual element can advertise a delay value between 1 and 2**28 (somewhat over two minutes) and the total delay added all elements can range as high as 2**32-1. Should the sum of the different elements delay exceed 2**32-1, the end-to-end delay should be 2**32- 1. The guaranteed service is service_name 2. Error characterization parameter C is numbered 1 and parameter D is numbered 2. The end-to-end composed value for C is numbered 3 and the end-to-end composed value for D is numbered 4. Shenker/Partridge Expires 12/1/95 [Page 4] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 Policing Policing is done at the edge of the network and at all source merge points. A source merge point is where data from different sources is merged into a single flow. It is the responsibility of the invoker of the service (a setup protocol, local configuration tool, or similar mechanism) to identify points where policing is required. Nonconforming packets are dropped. Implementors should note that traffic entering the network with a particular token bucket (r,b) will often become more bursty as it travels through the network. However, under guaranteed service, the burstiness of the flow at any given point is bounded by a token bucket equal Ctot+b+(Dtot*R), where Ctot and Dtot are the sums of the parameters C and D between the flow's source and the policing point. WARNING: The derivation of the enhanced token bucket size may not be quite right. We are still working through the theory. Ordering and Merging TSpec's are ordered according to the following rule: TSpec A is a substitute for TSpec B if both the the token bucket depth and rate for TSpec A are greater than or equal than those of TSpec B. The RSpec's are ordered by their numerical values, with larger being better. Resulting Service The resulting end-to-end service is an assured bandwidth service which, when used by a policed flow, produces a delay bounded service with no queueing loss. The service conforms to the fluid model to within the specified error bounds. The end-to-end delay bound is b/R+Ctot/R+Dtot. This service is intended for applications which need a firm guarantee that a packet will arrive no later than a certain time after it was transmitted by its source. However, implementors should keep in mind that because the guaranteed is a firm one, it must be large enough to cover extremely rare cases of long queueing delays. Several studies have shown that the actual delay for the vast majority of packets will be far lower than the guaranteed delay, and receiving systems or applications should be prepared to receive packets that arrive well before the delay bound. Shenker/Partridge Expires 12/1/95 [Page 5] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 Guidelines for Implementors [none] Evaluation Criteria The scheduling algorithm and admission control algorithm of the element must ensure that the delay bounds are never violated. Vendors are encouraged to formally prove that their implementation is an approximation of the fluid model. Examples of Implementation One implementation of guaranteed service would be to implement the Weighted Fair Queueing (WFQ) scheduling algorithm [1]. Examples of Use Consider an application that is intolerant of any lost or late packets. It uses the advertised values Ctot and Dtot (the values of C and D added across all nodes) and the TSpec of the flow, to determine compute the resulting delay bound from a service request R. It then sets its playback point to b/R+Ctot/R+Dtot. Security Considerations Security considerations are not discussed in this memo. References 1. A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm," in Internetworking: Research and Experience, Vol 1, No. 1., pp. 3-26. 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 12/1/95 [Page 6] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-01.txt July, 1995 Shenker/Partridge Expires 12/1/95 [Page 7]