INTERNET-DRAFT Octavio Medina Internet Engineering Task Force Jean-Marie Bonnin Expires April 2000 Laurent Toutain ENST Bretagne A Multimedia Color Marker 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document defines a mark and drop mechanism called Multimedia Color Marker or mmCM. This mechanism, based on the Three Color Marker [trTCM], can be used as a component of a Diffserv traffic conditioner for CBR Audio/Video flows. In addition to the functions performed by a color aware trTCM, the mmCM performs rate control and reactive discard. Rate control protects TCP flows from unresponsive UDP streams. Rate control is performed by introducing a third Token Bucket to the trTCM model with a small bucket size. Reactive discard is used to increase the probability of delivery for low precedence packets. Reactive discard is performed by demoting or dropping yellow and red packets in reaction to a green packet demotion at the marker. Hierarchically coded Audio/Video flows can benefit of this functionality if the coder pre-marks the stream to reflect the relative value of the information transported in each IP packet. It is assumed that the mmCM is used in conjunction with AF-based services. Medina, Bonnin, Toutain Expires April 2000 [Page 1] INTERNET-DRAFT draft-medina-mmcm-00.txt October 1999 1. Introduction As an element of the Differentiated Services architecture [arch], a traffic conditioner plays a decisive role in the definition of services. In the case of AF-based services [AF], one of the functions of the traffic conditioner is to assign a drop precedence level for every IP packet using the service. Different strategies in this matter have been proposed to assure differentiated distribution of bandwidth and/or TCP protection against non-responsive flows [trTCM][EA][FM]. It is difficult to conceive an universal marker that works for every type of flow. While for some types of traffic a marking strategy will result in good differentiation, for other types of flows the differentiation goals may not be achieved. In this document a new type of marker is being proposed for a particular type of flow: Constant Rate Audio/Video streams. Two aspects have been taken into account when defining the mmCM. First, Audio/Video streams are commonly transported using UDP, therefore no congestion mechanisms are enforced at the end nodes. If marking is the only action performed by traffic conditioners, a bad behaved UDP source can significantly affect the Quality of Service observed by other flows sharing the same link. For this reason, it is desirable to limit the resources that UDP flows can consume. The second consideration focuses on the nature of Audio/Video flows. While for TCP flows a packet loss is followed by the retransmission of the packet, for Audio/Video flows dropped information is in general not retransmitted due to time constraints. Hierarchical Audio/Video coders can generate base quality information and enhanced quality information [MPEG][sband]. For this type of flows, the loss of some packets may result in an increased quality degradation than the loss of other packets. One possibility to increase the quality observed by the receiver consists of having the coder to pre- mark its packets based on the semantic value they carry. On the network side, traffic conditioners would have to prevent packets marked as valuable from being lost due to congestion. The mmCM is based on the two rate Three Color Marker proposed in [trTCM]. Two Token Buckets verify conformance to the specified Committed rate and Peak rate. This results in three possible precedence levels. The first enhancement to the trTCM consists of a third Token Bucket that is used to limit the total rate that enters the network. If the flow is non conforming to this Token Bucket, packets are discarded by the marker independently of their incoming color. The second enhancement is represented by a Reactive Module capable of preempting yellow and red packets. By these means, the number of demoted or dropped green packets (considered by the source as valuable) can be reduced. 2. Description of the marker The multimedia Color Marker consists of three modules as shown in Figure 1. The reactive box is the first to treat incoming packets. Based on the feedback coming from the Meter, it may demote yellow packets to red, or drop yellow and red packets. These actions normally follow the demotion of a previous green packet. The actual version of the mmCM also considers preempting red packets following a yellow packet demotion. Medina, Bonnin, Toutain Expires April 2000 [Page 2] INTERNET-DRAFT draft-medina-mmcm-00.txt October 1999 +-------------+ +------------+ | feedback | | result | V | | V +----------+ +----------+ +----------+ Packet | Reactive | | Meter | | Marker | Marked Packet Stream ==> | Box |====>| |====>| |===> Stream +----------+ +----------+ +----------+ | | DROP DROP Figure 1: mmCM scheme On the second step conformity is verified using three Token Buckets defined by a Committed Rate, a Peak Rate, a Maximum Rate and their corresponding burst sizes. If the incoming packet exceeds the MR it is immediately discarded. If the packet conforms to the MR but remains non- conforming to the PR it is marked as red. If the packet does not exceed the MR nor the PR but it is above the CR it is marked yellow. If the packet rate remains below the CR the packet obtains the green precedence. Finally, If the metering function results in demoting or dropping a green packet, the Reactive Box is informed. The mmCM always operates in color-aware mode. If a source can not assign different colors to its packets, all of them can be considered as green. This results in a behavior similar to a rate-controlled trTCM. 3. Configuration The mmCM is configured by assigning values to 6 different parameters: a Committed Rate (CR) and its corresponding Committed Burst Size (CBS), a Peak Rate (PR) and its corresponding Peak Burst Size (PBS) and a Maximum Rate (MR). The preceding rates MUST be specified in bytes of IP packets per second. The burst sizes MUST be expressed in bytes. The Maximum Rate (MR) expresses an absolute rate limit, so it is proposed that the Token Bucket used to verify this constrain is configured with a Burst Size of 1 or 2 times the maximum packet size. To obtain the expected behavior from the mmCM, the values assigned to the rate parameters MUST respect the relationship: CR <= PR <= MR. The final parameter is an integer called the Reaction Level (RL). It represents the number of higher precedence packets to be preempted for every lower precedence packet dropped at the Meter. For example, if RL equals 1, a yellow packet drop means a red packet preemption. For RL=2, a yellow packet drop translates into 2 red packet reactive drops. The mechanism at the Reactive Box is recursive, so that for RL=2 a green drop is compensated by the preemption of 2 yellow packets and 4 red packets. 4. Metering, Marking and Dropping The behavior of the mmCM depends on the parameters presented in the above section. When a packet arrives, it is first treated by the Reactive Box. The behavior of this module depends on the value of the Reaction Level parameter (RL), and on three internal counters: Medina, Bonnin, Toutain Expires April 2000 [Page 3] INTERNET-DRAFT draft-medina-mmcm-00.txt October 1999 yellow_demote, yellow_out, red_out. These counters are updated based on the feedback coming from the meter as shown in Table 1. Metering Result Variable Update Recursion ---------------------------------------------------- yellow->red red_out++ yellow->drop red_out += RL green->yellow yellow_demote++ red_out++ green->red yellow_out++ red_out += RL gren->drop yellow_out += RL red_out += (RL * RL) Table 1. Reactive Box Variable Update As shown in the Table, variable update is recursive. If one green demotion demands one yellow demotion, this yellow demotion is followed by the corresponding red packet drops. Based on the value of the internal counters, one of the following actions is taken at the Reactive Box: * if the incoming color of the packet is red and red_out > 0, the packet is dropped and red_out is decreased by 1. * if the incoming color of the packet is yellow and yellow_out > 0, the packet is dropped and yellow_out is decreased by 1. * if the incoming color of the packet is yellow and yellow_demote > 0, the packet is re-colored red and yellow_demote is decreased by 1. The packet then enters the marker. When this module is launched, 3 Token Buckets are initialized: Tc(CR, CBS) verifies conformity to the Committed Rate, Tp(PR, PBS) verifies for the Peak Rate and Tm(MR, MBS) verifies the Maximum Rate. It is RECOMMENDED to use a small value for the MBS, i.e. the equivalent of 1 or 2 times the maximum packet size. The initial level of the Buckets is CBS, PBS and MBS respectively. Thereafter, Tc is incremented CR times per second up to CBS. The same behavior applies for Tp and Tm based on their corresponding parameters. When a packet of size B bytes arrives at the marker, one of the following actions is taken: * if Tm(t) < B, the packet is discarded * if Tp(t) < B or the incoming color of the packet is red, the packet is marked as red. * if Tc(t) < B or the incoming color of the packet is yellow, the packet is marked as yellow. * if Tc(t) > B and the packet has been pre-colored as green, the packet is marked as green. Following the metering function, the packet is marked to reflect the obtained color. This action results in a new Diffserv Code Point [DSCP] for the packet. In the case of AF-based services, the obtained color can be coded as the precedence level of the packet. Medina, Bonnin, Toutain Expires April 2000 [Page 4] INTERNET-DRAFT draft-medina-mmcm-00.txt October 1999 5. Discussion The protection of green packets can be very useful when the mmCM is used to control an aggregate of Audio/Video CBR flows. In this case, it is hard to predict how many packets will be pre-marked as green. Current proposals consider precedence levels as an indication of SLS conformance, but in the case of Audio/Video flows this precedence should be seen as the semantic value of the information carried by the packet. With this idea on mind, it is possible to imagine some services that can be offered to Audio/Video Applications. One of the scaling properties of the DiffServ architecture [arch] is the capacity to do policing over a flow aggregate. Introducing flow- type specific traffic conditioning may reduce this advantage. However, separating UDP flows from TCP flows for differentiated conditioning treatments is not a complicated task and it can improve the differentiation capacities at edge nodes. This might be done by using separate AF classes, but it is not the only solution. TCP and UDP packets belonging to the same aggregate may be separated for policing reasons at edge devices and be regrouped again before getting into the next link, sharing the same AF class. The mmCM has been designed for use with UDP flows. Its applicability with other types of traffic, like TCP flows, remains a subject of future research. The rate limiting function of the mmCM may prevent TCP flows from obtaining excess bandwidth over non-congested networks. Nevertheless, the mmCM can be configured to operate as a normal Three Color Marker with Reactive Box (by setting MR to infinity). Without the rate control function, the number of reactive drops is considerably reduced, increasing the output rate that TCP sources may obtain. The last comment goes on the utilization of mmCM markers with "interactive" flows. This type of data demands low delay guarantees that can be satisfied using adapted PHBs like the Explicit Forwarding PHB [EF]. A mmCM can be used to perform the rate control function requested by a Premium Service but, since no precedence levels exist for the EF PHB, the benefits of the mmCM would be minimal. The behavior of the mmCM when used with services based on PHBs other than AF, as well as the service offered to Variable Rate flows, is still to be tested. 6. Service Example The use of AF-based transmission together with mmCM mechanisms can result into a minimal quality guarantee service for Audio/Video CBR streams. On the Application side, coders can organize the information transported by the flow and pre-mark as green those packets needed for a minimal quality decoding (mark I frames of an MPEG stream as green, for example). Whenever the flow is aggregated with similar flows, traffic conditioners take actions to prevent the drop of green, and therefore, valuable packets. On the network side, interior nodes use a precedence-based queue management algorithm. On a well provisioned network, green packets should never be dropped by interior nodes. In normal operation decoders will receive the totality of the information, offering to the receiver high quality Audio/Video. Whenever the network gets into congestion state, the Medina, Bonnin, Toutain Expires April 2000 [Page 5] INTERNET-DRAFT draft-medina-mmcm-00.txt October 1999 quality observed by receivers will decrease fairly (same degradation for all receivers) up to the minimal quality assured by the service. 7. Security Considerations The mmCM has no security considerations at this point. 8. References [trTCM] J. Heinanen and R. Guerin, "A Two Rate Three Color Marker," Internet Draft, March 1999. [MPEG] R. Aravind, M. R. Civanlar et A.R. Reibman, "Packet Loss Resilience of MPEG2 Scalable Video Coding Algorithms", AT&T Bell Laboratories, Holmdel; USA. [sband] K. Sawada et T. Kinoshita, "Subband-based scalable coding schemes with motion compensated prediction", SPIE Vol. 2501, pp. 1470 1477, July 1995. [arch] D. Black et al., "An Architecture for Differentiated Services", Internet Draft, May 1998. [AF] J. Heinanen et al., "Assured Forwarding PHG Group," Internet Draft, February 1999. [EA] W. Fang and D. Clark, "Explicit Allocation of Best Effort Packet Delivery Service," submitted for publication. [FM] H. Kim, "A Fair Marker", Internet Draft, October 1999. [DSCP] K. Nichols et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 8. Authors' Address Octavio MEDINA, Jean-Marie BONNIN, Laurent TOUTAIN Ecole Nationale des Tilicommunications de Bretagne Campus de Rennes 3, rue de la Chbtaigneraie 35510 CESSON-SEVIGNE France Email: {medina, bonnin, toutain}@rennes.enst-bretagne.fr Medina, Bonnin, Toutain Expires April 2000 [Page 6]