Internet Draft Paul Ferguson November 7, 1997 cisco Systems, Inc. Expires in six months Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference draft-ferguson-delay-drop-00.txt 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 Recent opinions and sentiments expressed in the Internet Service Provider (ISP) community, as well as the Internet community at-large, have voiced concern over the applicability and scaleability of RSVP and the Integrated Service model in the global Internet infrastructure. Convincing arguments have been made for a differential services model which offers packet delivery services better than traditional best effort, yet not as resource intensive as RSVP. As a result, an effort within the Intergrated Services working group has been examining methods to provide simpler, less resource intensive methods of offering differentiated services. This draft provides a practical method to use bit values expressed in the IP Type or Service (TOS) and IP precedence fields for delay indication and packet drop preference, respectively. draft-ferguson-delay-drop-00.txt [Page 1] INTERNET-DRAFT Simple Differential Services November 7, 1997 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architectural Significance . . . . . . . . . . . . . . . . 4 3.1 Delay Indication . . . . . . . . . . . . . . . . . . . 5 3.2 Queuing Packets with Delay Indication . . . . . . . . 5 3.3 Drop Preference . . . . . . . . . . . . . . . . . . . 7 3.4 Preferential Drop Mechanism at Intermediate Nodes . . 7 3.5 Passive and Active admission . . . . . . . . . . . . . 8 4. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations. . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Differentiated Quality of Service (QoS) has become a watchword in the Internet community, at the expense of differentiated definitions of the concept. While many had hoped that RSVP would prove to be the mechanism to provide this functionailty, a large contingent of Internet Service Providers (ISP's) have expressed concern over the amount of computational, memory, and other system resources which might be consumed by managing thousands, or perhaps hundreds of thousands, of flows. As a result, a small collective group within the IETF Integrated Services working group has been examining several methods to define less resource intensive mechanisms to provide differentiated services -- somewhere between the traditional best effort model and the guaranteed [1] and controlled-load [2] service models defined in the Integrated Services architecture [3]. This draft focuses on two fundamental issues -- a simplistic method to signify a "delay indicator" in packets, as well as a "drop preference" to indicate the relative priority of a particular packet as it is transited through the network. 2. Background One of the first questions that becomes immediately apparent in this scheme is, "What are we trying to accomplish?" As mentioned previously, there is a need for a QoS traffic scheme which provides reasonable levels of differentiation, but yet which does not impose the path and resource reservation state maintenance required by RSVP [4]. draft-ferguson-delay-drop-00.txt [Page 2] INTERNET-DRAFT Simple Differential Services November 7, 1997 The first order of business is to examine methods which provide a simpler, less resource intensive method of differentiating traffic, but at the same time requires no fundamental change in deployed protocols, implementation, and only a modification in the interpreted semantics of bit values in the IP TOS and precedence fields, when used inconjunction with a differentiated services implementation. Without adding a new signaling protocol (which has, in and of itself, been a topic of much dissension), the most logical place to consider for placing indicators for differentiation is in the IP header. If we examine the IP header, we find the 8 bit TOS field could indeed be used to convey differential service information [Figure 1] [5]. This is due to the fact that none of the bits within this particular field have been widely used for anything to date. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example IPv4 Datagram Header [5] [Figure 1] 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TOS | MBZ | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Type of Service Byte [6] [Figure 2] draft-ferguson-delay-drop-00.txt [Page 3] INTERNET-DRAFT Simple Differential Services November 7, 1997 As it exists today, RFC701 [5] suggests using the following semantics of bit values which might be contained in the precedence field, as depicted in [Figure 2]: 111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine Additionally, RFC1349 [6] is the most current reference which describes the semantics of the bit values which might be contained in the 4 bit TOS field, also depicted in [Figure 2]: 1000 -- minimize delay 0100 -- maximize throughput 0010 -- maximize reliability 0001 -- minimize monetary cost 0000 -- normal service This proposal modifies the intrinsic semantics of the values of both of these fields when used in a differential services implementation. It should be noted that as both of these bit value semantics are currently defined in RFC791 and RFC1349, neither is widely used for traffic differentiation in practice. 3. Architectural Significance The objective in this approach is to provide a simplistic method in which to indicate the intrinsic value of each packet presented to the network for transit. Consider the following topology: | h1---->+ | h2---->+-->r--->R---->R--->R-----> [towards destination] | Consider h1 and h2 as the "hosts" which desire some sort of "better-then-best-effort" service -- h1 may send traffic which is somewhat delay sensitive (for example, real-time loss-tolerant video), and h2 may send traffic which is not delay sensitive (for example, batch ftp traffic), but is considered to be of higher intrinsic value than traditional best effort traffic (e.g. e-mail). draft-ferguson-delay-drop-00.txt [Page 4] INTERNET-DRAFT Simple Differential Services November 7, 1997 Each of the tools mentioned in this draft have very sepcific architectural significance, or in other words, the effectiveness each tool is dependent on where & how it is used at various locations in the network topology. 3.1 Delay Indication It should be again be mentioned that this approach does not provide a priori knowledge of end-to-end network delay or maximal queuing delay, as done with the Integrated Services guaranteed service model. What it does attempt to provide, however, is a mechanism to identify packets which belong to traffic flows for which predictable queuing behavior is desired. The following semantics (Delay Indication) is proposed for differential services implementations in addition to existing RFC1349 TOS semantics: Bit Existing Delay Value Semantics Indication 1000 -- minimize delay Highest delay sensitivity 0100 -- maximize throughput . 0010 -- maximize reliability . 0001 -- minimize monetary cost Lowest delay sensitivity 0000 -- normal service No delay sensitivity The values 0100 (maximize throughput) and 0010 (maximize reliability) can be used as incremental delay indication values to represent any arbitrary delay sensitivity which falls between the "highest" and "lowest" delay sensitivity value indicators. 3.2 Queuing Packets with Delay Indication There are perhaps several methods which could be used to map packets with the delay indication (expressed in Section 3.1) to specific queues as a mechanism to provide predicatble transmission behavior. This relies on the queuing discipline used, as well as the queue servicing characteristics. The most interesting, and perhaps most effective, method of doing this is to map packets to different CBQ (Class Based Queuing) [7] queues. There are at least two choices with reagrds to where CBQ could be deployed in this architectural model. A CBQ-like mechanism should be implemented on the first-hop ingress router (r), but draft-ferguson-delay-drop-00.txt [Page 5] INTERNET-DRAFT Simple Differential Services November 7, 1997 can also be implemented on each intermediate router in the transit path (R). However, it is unlikely that the latter model is realistic in the global Internet, due to the fact that intermediate routers in the transit path between the source and destination may reside in various different administrative domains. Also, it is unclear that a preferential queuing discipline is actually needed at subsequent intermediate nodes. Simple Delay Indication to CBQ mapping example: delay +-----------------------------+ sensitivity | CBQ queue depth | | | | | | +-------------------+ | 0010-+ | +->| |-+ | | | | +-------------------+ | | towards | | | | | destinations +-------+ +----------------+ +--------> 0100----------->| |----------------> +-------+ +----------------+ +-------> | | | | | | | | +--------+ | | 1000-+ | +->| |-------------+ | | +--------+ | | | +-----------------------------+ Router Incoming packets with CBQ queue delay depths proportional indication to relative transmit priority The CBQ queue servicing algorithm may be implementation specific, but it is important to note that the desired functionality is for packets with a 'higher' delay sensitivity indication to be transmited prior to those with 'lower' delay sensitivity inication. It is also important to note that this is simply an example of how the delay indication bits could be used, not a mandatory implementation. We believe it is prudent to allow implementors to determine how these mechanics will be deployed -- it is only important to agree on the bit value semantics. draft-ferguson-delay-drop-00.txt [Page 6] INTERNET-DRAFT Simple Differential Services November 7, 1997 3.3 Drop Preference There is at least one known implementation of preferntial packet drop which uses the values expressed in the IP precedence field, as described in [5], and this draft does not modify the semantics of the existing IP precedence values defined below [5]. Instead, a suggested interpretation of these values is provided below which modifies the existing semantics when used inconjunction with a differential services implementation: Bit Existing Drop Preference Value Semantics Semantics 111 - Network Control Lowest 110 - Internetwork Control . 101 - CRITIC/ECP . 100 - Flash Override . 011 - Flash . 010 - Immediate . 001 - Priority . 000 - Routine Highest The values which fall between 110 (Internetwork Control) and 001 (Priority) can be used to represent any arbitrary incremental drop preference between "lowest" and "highest" drop preference values, 111 and 000 respectively. This is could be considered a matter of local policy. 3.4 Preferential Drop Mechanism at Intermediate Nodes It is important to note that if congestion is not experienced at an intermediate transit node, then no action (e.g. packet discard) is taken -- packets are forwarded in the order in which they are received. The concept of preferential drop, or packet discard, only becomes an issue should congestion be imminent. The most effective method of mitigating congestion is to use Random Early Detection (RED) [8], such that congestion and global synchronization [9] (and ultimately congestion collapse) is avoided to the maximum extent possible. However, basic RED functionality can be considered to be somewhat "fair", in that packets are pseudo- randomly selected for discard as the queue depth(s) reaches an arbitrary, administratively-defined threshold. What is needed is a more "unfair", or preferential, method of selecting packets for discard when the queue depth(s) exceed the threshold. draft-ferguson-delay-drop-00.txt [Page 7] INTERNET-DRAFT Simple Differential Services November 7, 1997 A modified RED behavior is discussed in [10], whereas the relative priority of packets (as discussed in Section 3.2) is considered in the packet discard decision process. This "unfair" and "enhanced" RED should be implemented on each node (R) in the traffic transit path. Again, it is also important to note that this is simply an example of how the drop preference bits could be used, not a mandatory implementation. We believe it is prudent to allow implementors to determine how these mechanics will be deployed -- it is only important to agree on the bit value semantics. 3.5 Passive and Active admission There are two possible scenarios for how packets are marked as they enter the network. The hosts (for example h1 and h2) could set the TOS (delay indication) and precedence values (drop preference) in their IP packets as they see fit, and the first-hop ingress router (r) could simply accept traffic "as is" without examining or policing it, and simply forward it on it's way unimpeded. This is passive admission. The alternative approach is for the first-hop ingress router (r) to actively profile, monitor, and police traffic which is presented to it for transit. The method of performing this active admission control can be implementation-specific, but there is at least one method that we understand, and which works well. This is the use of a token-bucket implemented on (r), or perhaps mutiple token-buckets, which uses thresholds to mark packets based upon their compliance or non-compliance (or both) to a bit rate threshold. A similar method for marking packets in this fashion is discussed in [11]. The ingress router is also an ideal point in the topology to mark packet indication insofar as host address or application (TCP or UDP port). 4. Summary The mechanisms discussed in this proposal are simple and effective methods to provide reasonably predictable service differentiation for traffic presented to the network. It should be noted, however, that the effectiveness of the deployment of these tools relies somewhat on the engineering of the network architecture, in that if the network is drastically under-provisioned and severely congested, these tools become noticeably less effective. This is the intrinsic difference between service quality and quality of service (QoS), in that if the network is poorly provisioned or excessively unstable (poor service quality), the effectiveness of any tool that attempts to provide service differentiation (QoS) is effectively diminished. draft-ferguson-delay-drop-00.txt [Page 8] INTERNET-DRAFT Simple Differential Services November 7, 1997 Having said that, however, traffic entering the network will indeed be provided preferential queuing and transmission if the delay indication bits are set accordingly, and traffic will be discarded at intermediate nodes in accordance with the drop preference indication set in the packets themselves. These use of delay indication and drop preference are not necessarily mutually exclusive -- they can be used independently or in conjunction with one another. However, use of the delay indication bits requires the use of preferential queueing and transmission at the network ingress router, and likewise, use of the drop preference bits requires that a preferential drop mechanism be used on each intermediate node in the transit path, in order for these mechanisms to be effective. 5. Security Considerations Inherently, it may be necessary to provide some sort of policy mechanism at the network ingress node to ensure that only "authorized" entities or applications can obtain preferential use of network resources. This is a local policy matter, and the implementation of such policy mechanisms are not discussed in this memo. 6. Acknowledgments Special thanks to Juha Heinanen (Telia) for his assistance in reviewing this memo. 7. References [1] RFC2212, "Specification of Guaranteed Quality of Service," S. Shenker, C. Partridge, R. Guerin, September 1997. [2] RFC2211, "Specification of the Controlled-Load Network Element Service," J. Wroclawski, September 1997. [3] RFC1633, "Integrated Services in the Internet Architecture: An Overview," R. Braden, D. Clark, S. Shenker, June 1994. [4] RFC2205, "Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification," R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, September 1997. [5] RFC791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," September 1981. [6] RFC1349, "Type of Service in the Internet Protocol Suite," P. Almquist. July 1992. draft-ferguson-delay-drop-00.txt [Page 9] INTERNET-DRAFT Simple Differential Services November 7, 1997 [7] "Link-sharing and Resource Management Models for Packet Networks," Floyd, S., and Jacobson, V., IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. http://ftp.ee.lbl.gov/floyd/cbq.html [8] "Random Early Detection Gateways for Congestion Avoidance," S. Floyd, V. Jacobson, IEEE/ACM Transactions on Networking, v.1, n.4, August 1993. http://www-nrg.ee.lbl.gov/floyd/red.html [9] "Oscillating Behavior of Network Traffic: A Case Study Simulation," L. Zhang, D. Clark, Internetwork: Research and Experience, Volume 1, Number 2, John Wiley & Sons, 1990, pages 101-112. [10] "Understanding TCP Dynamics in an Integrated Services Internet," W. Feng, D. Kandlur, D. Saha, K. Shin, NOSSDAV '97, May 1997. http://www.eecs.umich.edu/~wuchang/work/nossdav97.ps.Z [11] "Adaptive Packet Marking for Providing Differentiated Services in the Internet," W. Feng, D. Kandlur, D. Saha, K. Shin, U. Michigan CSE-TR-347-97, October 1997. http://www.eecs.umich.edu/~wuchang/work/pmg.ps.Z 8. Author's address Paul Ferguson cisco Systems, Inc. 400 Herndon Parkway Herndon, VA USA 20170 Email: ferguson@cisco.com draft-ferguson-delay-drop-00.txt [Page 10]