Internet Draft Paul Ferguson
March 12, 1998 cisco Systems, Inc.
Expires in six months
Simple Differential Services:
IP TOS and Precedence, Delay Indication, and Drop Preference
draft-ferguson-delay-drop-02.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 scalability 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, especially
in the face of congestion, yet not as resource intensive as RSVP.
As a result, the Differentiated Service (diffserv) working group
in the IETF 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 subfields of the
TOS byte in the IP packet header for delay indication and packet drop
preference, respectively.
draft-ferguson-delay-drop-00.txt [Page 1]
INTERNET-DRAFT Simple Differential Services March 12, 1998
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 functionality, a large
contingent of Internet Service Providers (ISP's) have expressed
concern over the amount of computational and memory overhead, as
well as other system resources which might be consumed by managing
thousands, or perhaps hundreds of thousands, of flows.
As a result, the Differentiated Services (diffserv) 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-02.txt [Page 2]
INTERNET-DRAFT Simple Differential Services March 12, 1998
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 in conjunction 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 packet 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 this byte has historically not been widely used in the
Internet.
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-02.txt [Page 3]
INTERNET-DRAFT Simple Differential Services March 12, 1998
As it exists today, RFC791 [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] 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 suggests modifying the 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
(arguably) widely used for traffic differentiation in practice
today.
3. Architectural Significance
The objective in this approach is to provide a simplistic method
in which to indicate the intrinsic value and relative priority of
each packet presented to the network for transmission. 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 relative priority than traditional
best effort traffic (e.g. e-mail).
draft-ferguson-delay-drop-02.txt [Page 4]
INTERNET-DRAFT Simple Differential Services March 12, 1998
In this particular example, packets originating from h1 may have
a higher delay sensitivity indication (as well as a lower drop
preference indication) than other traffic in the network, while
traffic originating from h2 may only indicate a lower drop
preference.
Each of the tools mentioned in this draft have very specific
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, effectively modifying existing RFC1349 TOS
subfield semantics:
Bit Delay
Value Indication
11__ High delay sensitivity
10__ Medium delay sensitivity
01__ Low delay sensitivity
00__ No delay sensitivity
The low-order two bits (indicated by underscores in the chart above)
are not used in this scheme in the interest of coding efficiency and
should be values of zero (0). It is believed that three levels of
delay indication (high, medium, low delay sensitivity), in addition
to "no delay sensitivity," is sufficient for preferential non-FIFO
queuing and preferential transmission servicing schemes. In any
event, the reserved low-order two bits may be used in the future
for expansion of this scheme should it be determined that more
levels of delay indication is required.
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 predicable
transmission behavior. This relies on the queuing discipline
used, as well as the queue servicing and transmission algorithm.
draft-ferguson-delay-drop-02.txt [Page 5]
INTERNET-DRAFT Simple Differential Services March 12, 1998
The most interesting, and perhaps most effective, method of doing
this is to map packets to different CBQ (Class Based Queuing) [7]
queues.
It should be noted that to provide effective differentiation for
packets with non-zero (e.g. high, medium, low delay sensitivity)
delay indication, a consistent CBQ model should be deployed on each
router in the end-to-end traffic path.
Simple Delay Indication to CBQ mapping example:
delay +-----------------------------+
sensitivity | CBQ queue depth |
| |
| |
| +-------------------+ |
0100-+ | +->| |-+ |
| | | +-------------------+ | | towards
| | | | | destinations
+-------+ +----------------+ +-------->
1000----------->| |---------------->
+-------+ +----------------+ +------->
| | | | |
| | | +--------+ | |
1100-+ | +->| |-------------+ |
| +--------+ |
| |
+-----------------------------+
Router
Incoming
packets with CBQ queue
delay depths proportional
indication to relative transmission
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
transmitted prior to those with "lower" delay sensitivity indication.
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 arguably
only important at this point to agree on the bit value semantics.
draft-ferguson-delay-drop-02.txt [Page 6]
INTERNET-DRAFT Simple Differential Services March 12, 1998
3.3 Drop Preference
There is at least one known implementation of preferential
packet drop which uses the values expressed in the IP precedence
subfield of the TOS byte, as described in [5], and this draft
effectively modifies 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 in conjunction with a differential services
implementation:
Bit RFC791 Relative
Value Semantics Drop Preference
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, unless the packet contains a non-zero delay
indication.
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
draft-ferguson-delay-drop-02.txt [Page 7]
INTERNET-DRAFT Simple Differential Services March 12, 1998
"unfair," or preferential, method of selecting packets for
discard when the queue depth(s) exceed the threshold, thus providing
a prejudicial mechanism for providing differentiated services.
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," or "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. It is prudent to allow implementors to determine
how these mechanics will be deployed -- again, 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 subfield values (delay indication) and IP precedence
subfield 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 multiple 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 indicators 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
draft-ferguson-delay-drop-02.txt [Page 8]
INTERNET-DRAFT Simple Differential Services March 12, 1998
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.
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, based on congestion (queue occupancy) in
accordance with the drop preference indicated in the packets
themselves.
These use of delay indication and drop preference are not
necessarily reliant upon one another -- they can be used
independently or in conjunction with one another. However, use
of the delay indication bits requires the use of preferential
queuing and transmission at each router in the transit path,
and likewise, use of the drop preference bits requires that a
preferential drop mechanism, similar to the ones discussed above,
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 the *-00.txt revision 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.
draft-ferguson-delay-drop-02.txt [Page 9]
INTERNET-DRAFT Simple Differential Services March 12, 1998
[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.
[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-02.txt [Page 10]