INTERNET-DRAFT Octavio Medina
Internet Engineering Task Force Jean-Marie Bonnin
Expires April 2000 Laurent Toutain
ENST Bretagne
A Multimedia Color Marker
<draft-medina-mmcm-00.txt>
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]