Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT S. Shenker/C. Partridge
draft-ietf-intserv-control-del-svc-00.txt Xerox/BBN
March, 1995
Expires: 9/1/95
Specification of Controlled Delay 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 expected behavior of a controlled delay
service in the Internet. The memo follows the service template model
of specifying per-network-element behavior, end-to-end behavior, and
evaluation requirements.
Introduction
This memo is the first of what is expected to be a series of Service
Definitions for quality of service in the Internet. This memo
defines a controlled delay service. In particular, it defines
requirements for network elements that support this service. It does
not specify how end-to-end setup mechanisms establish their service,
except to define what information each element requires to establish
the service at that element and what information each element may
advertise in return.
The document uses the terms "network element" and "element" to mean
Shenker/Partridge Expires 9/1/95 [Page 1]
INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995
any component of the internetwork which is capable of exercising QOS
control over data flowing through it. Network elements might include
routers, QOS-aware subnetworks, and end-note operating systems.
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
intserv@isi.edu and/or the author(s).
Motivation
Controlled delay service is designed for service and delay adaptive
applications; i.e., applications that are prepared to adapt to
changing delays and to change their service request (after they have
started receiving) if the current service level is not adequate.
This service does not provide any quantified level of assurance.
Instead, it merely promises to avoid overloads by turning excess
flows away. The criterion for determining overloads is not
specified. Thus, while this service controls delay, it does not make
any specific assurances about delay. This service is subject to
admission control.
Per-hop Service
The network element must assure that the packet delays are
controlled. This control must be active, in that the element must be
able to control admissions to the element. In particular,
overprovisioning is not sufficient to deliver controlled delay
service. However, no quantitative specification of the maximal
delays are given.
There are three different logical levels of service; a switch can
implement fewer actual levels of service, but must treat them as
three logical levels. The levels have different levels of delay
control, with level 1 having the most tightly controlled delay, and
level 3 having the least tightly controlled delay. The different
levels do not have to give strictly ordered delays for each packet;
that is, the network element need not ensure that every packet given
level 1 service experiences less delay than if it were given level 2
service. The element need only ensure that the typical delays are no
greater in level 1 than in level 2 (and similarly for levels 2 and
3).
Advertisements
The network element is not required to advertise any information
about the service to the setup mechanism used to establish end-to-end
service. It is assumed that the receiving application is measuring
Shenker/Partridge Expires 9/1/95 [Page 2]
INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995
the delays it experiences and will adapt, either by changing its
playback time, or by changing levels of service if the delays are
unacceptable.
However, as a hint about current delays, the instantaneous delay may
optionally be advertised for each service level (1, 2 and 3). This
advertisement has an additive composition rule; the delay at each hop
is added to the current cumulative delay along the path. There is no
exact specification of how the instantaneous delay must be measured.
However, since the maximal delays are typically more important than
the average delays, the advertised quantity should reflect the
extremal values of delay.
If a network element does not measure its instantaneous delays and
any setup mechanisms that wish to estimate the instantaneous delay
should treat the element as having a modest fixed delay. [Neither
author is sure that this sentence belongs here -- but we need some
consistent rule about what setup mechanisms do if some elements don't
cooperate]
Traffic Specification and Policing
Traffic is described by a token bucket filter (tbf), which is
specified by a token bucket depth r and a token bucket rate b.
Policing is done at the edge of the network and at all source merge
points. (A source merge point is where data from multiple different
sources is merged into a single flow). Nonconforming packets are
dropped.
Invocation
Service is invoked by specifying the traffic (TSpec) and service
(RSpec) to the network element
The TSpec is a token bucket depth r and a token bucket rate b. Both
r and b must be positive.
The RSpec is a target delay, or a service level, or both. The
service level is specified by one of the integers 1, 2, or 3. A
target delay is specified by positive value.
The service module can map the target-delay into a service level with
any monotonic mapping; for instance, if a target delay td1 maps into
service level 2, then all target delays greater than td1 must map
into service levels 2 or 3. This mapping is local to each network
element; the mappings at different elements can be different.
However, the mapping is static, in that it does not change over time.
Shenker/Partridge Expires 9/1/95 [Page 3]
INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995
Either or both of the possible forms of RSpec can be specified. If
both are specified then the more stringent service, as determined by
the network element, is used (i.e., they both map into a service
level, and then the lowest service level is used). The form of
request where both are specified is necessary when merging
reservation requests.
Ordering
The TSpec's are ordered as follows; both the token bucket depth and
rate must be greater than or equal in order for the TSpec to be
greater than or equal. The RSpec's are ordered by their numerical
values (in inverse order). If both the target-delay and service-
level are specified, then both must be greater than or equal for the
RSpec to be greater than or equal. Ordering is relevant to the
merging of reservation requests.
Resulting Service
The resulting end-to-end service is one that offers applications
several levels of delay to choose from. So an adaptive application
that is unhappy with its current level of delay can move to a better
level of delay to try to improve service (or to a lesser level, if
the service currently being received is better than is needed).
Furthermore, this service promises that the levels of experienced
delays will be controlled. However, this service makes no assurances
about the absolute levels of delay or jitter the receiving
application will experience.
Evaluation Criteria
Showing that a network element implements a controlled delay service
is somewhat difficult, since the quality of service depends on
overall traffic load, the traffic pattern presented and the degree of
delay control implemented. In this section we sketch out a
methodology for testing an element's controlled delay service.
The idea is that one chooses a particular traffic mix (for instance,
three parts level 1, one part level 2, two parts level 3 and the rest
is best-effort traffic) and loads the network element with
progressively higher levels of this traffic mix (i.e., 40% of
capacity, then 50% of capacity, on up to near 100% capacity, or
beyond 100% capacity, provided all traffic in excess of full loading
is best effort traffic that can be discarded). For each load level,
one measures the mean delays and the packet loss rate for each level
of service (including best effort). Each test run at a particular
load should involve enough traffic that is a reasonable predictor of
the performance a long-lived application such as a video conference
Shenker/Partridge Expires 9/1/95 [Page 4]
INTERNET-DRAFTdraft-ietf-intserv-controlled-delay-svc-00.txt March, 1995
would experience (e.g., several minutes of traffic).
A conformant network element will show a distinct difference in mean
delays for level 1 service and best-effort service as loads increase
towards 100%, with level 1 service always getting the lower delay.
This should be true over a broad range of traffic mixes. Delays for
levels 2 and 3 traffic will fall between level 1 and best effort.
The level 2 and 3 delays can be equal to the level 1 delay, but must
be less than the best effort delay at higher loads. The level 2 and
3 delays are also subject to the condition that the delay for level 2
traffic must be less than or equal to the delay for level 3 traffic.
This memo does not specify particular traffic mixes to test, however,
we expect in the future that as the nature of real-time Internet
traffic is better understood, some suggested traffic mixes will be
proposed. For present purposes, it is sufficient for a network
element to demonstrate it effectively distinguishes delay for a few
different traffic mixes.
Security Considerations
Security considerations are not discussed in this memo.
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 9/1/95 [Page 5]
