One document matched: draft-ietf-intserv-ctrl-load-svc-00.txt
Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT J. Wroclawski
draft-ietf-intserv-ctrl-load-svc-00.txt MIT LCS
November, 1995
Expires: 5/96
Specification of the Controlled-Load Network Element 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).
This draft is a product of the Integrated Services Working Group of
the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at int-
serv@isi.edu and/or the author(s).
Abstract
This memo specifies the network element behavior required to
deliver Controlled-Load service in the Internet. The controlled-
load service provides the client data flow with a quality of
service closely approximating the QoS that same flow would receive
from an unloaded network element, but uses capacity (admission)
control to assure that this service is received even when the
network element is overloaded.
J. Wroclawski Expires 5/96 [Page 1]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
Introduction
This document defines the requirements for network elements that
support the Controlled-Load service. This memo is one of a series of
documents that specify the network element behavior required to
support various qualities of service in IP internetworks. Services
described in these documents are useful both in the global Internet
and private IP networks.
This document is based on the service specification template given in
[1]. Please refer to that document for definitions and additional
information about the specification of qualities of service within
the IP protocol family.
End-to-End Behavior
The end-to-end behavior provided to an application by a series of
network elements conforming to this specification tightly
approximates the behavior visible to applications receiving best-
effort service *under unloaded conditions* from the same series of
network elements. Assuming the network is functioning correctly,
these applications may assume that:
- A very high percentage of transmitted packets will be
successfully delivered by the network to the receiving end-nodes.
(The percentage of packets not successfully delivered must closely
approximate the basic packet error rate of the transmission
medium).
- The transit delay experienced by a very high percentage of the
delivered packets will not greatly exceed the minimum transmit
delay experienced by any successfully delivered packet (the
"speed-of-light delay").
NOTE: the term "unloaded" above is used in the sense of "not
heavily loaded or congested" rather than in the sense of "no other
network traffic whatsoever".
To ensure that these conditions are met, clients requesting
J. Wroclawski Expires 5/96 [Page 2]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
controlled-load service provide the intermediate network elements
with a estimation of the data traffic they will generate; the TSpec.
In return, the service ensures that network element resources
adequate to process traffic falling within this descriptive envelope
will be available to the client. Should the client's traffic
generation properties fall outside of the region described by the
TSpec parameters, the QoS provided to the client may exhibit
characteristics indicative of overload, including large numbers of
delayed or dropped packets. The service definition does not require
that the precise characteristics of this overload behavior match
those which would be received by a best-effort data flow traversing
the same path under overloaded conditions.
Motivation
The controlled load service is intended to support a broad class of
applications which have been developed for use in today's Internet,
but are highly sensitive to overloaded conditions. Important
examples of this class are the "adaptive real-time applications"
currently offered by a number of vendors and researchers. These
applications have been shown to work well on unloaded nets, but
poorly on much of todays overloaded Internet. A service which mimics
unloaded nets serves these applications well.
The controlled-load service is intentionally minimal, in that there
are no optional functions or capabilities in the specification. The
service offers only a single function but system and application
designers can assume that all implementations will be indentical in
this respect.
Internally, the controlled-load service is suited to a wide range of
implementation techniques; including evolving scheduling and
admission control algorithms which allow sophisticated
implementations to be highly efficient in the use of network
resources. It is equally amenable to extremely simple implementation
in circumstances where maximum utilization of network resources is
not the only concern.
Network Element Data Handling Requirements
Each network element accepting a request for controlled-load service
must ensure that adequate bandwidth and packet processing resources
are available to handle the requested level of traffic, as given by
the requestor's TSpec. This must be accomplished through active
J. Wroclawski Expires 5/96 [Page 3]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
admission control. All resources important to the operation of the
network element must be considered when admitting a request. Common
examples of such resources include link bandwidth, router or switch
port buffer space, and computational capacity of the packet
forwarding engine.
The controlled-load service does not accept or make use of specific
target values for control parameters such as delay or loss. Instead,
acceptance of a request for controlled-load service is defined to
imply a commitment by the network element to provide the requestor
with service closely equivalent to that provided to uncontrolled
(best-effort) traffic under unloaded conditions. This definition may
be taken to include:
- Little or no average packet queueing delay over all timescales
significantly larger than the "burst time". The burst time is
defined as the time required for the flow's maximum size data burst
to be transmitted at the flow's requested transmission rate, where
the burst size and rate are given by the flow's TSpec, as described
below.
- A very low level of congestion loss. In this context, congestion
loss includes packet losses due to shortage of any required
processing resource, such as buffer space or link bandwidth.
Although occasional congestion losses may occur, any substantial
sustained loss represents a failure of the admission control
algorithm.
NOTE:
Implementations of controlled-load service are not required to
provide any control of short-term packet delay jitter beyond that
described above. However, the use of packet scheduling algorithms
that provide additional jitter control is not prohibited by this
specification.
Packet losses due to non-congestion-related causes, such as link
errors, are not bounded by this service.
A network element may employ statistical approaches to decide whether
adequate capacity is available to accept a service request. For
example, a network element processing a number of flows with long-
J. Wroclawski Expires 5/96 [Page 4]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
term characteristics predicted through measurement may be able to
overallocate its resources to some extent without reducing the level
of service delivered to the flows.
A network element may employ any appropriate means to ensure that
admitted flows receive appropriate service.
Links are not permitted to fragment packets which receive the
controlled-load service. Packets larger than the MTU of the link must
be treated as nonconformant to the TSpec. This implies that they will
be policed according to the rules described in the Policing section
below.
The controlled-load service is invoked by specifying the data flow's
desired traffic parameters (TSpec) to the network element. Requests
placed for a new flow will be accepted if the network element has the
capacity to forward the flow's packets as described above. Requests
to change the TSpec for an existing flow should be treated as a new
invocation, in the sense that admission control must be reapplied to
the flow. Requests that reduce the TSpec for an existing flow (in the
sense that the new TSpec is strictly smaller than the old TSpec
according to the ordering rules given below) should never be denied
service.
The TSpec takes the form of a token bucket specification plus a
minimum policed unit (m) and a maximum packet size (M).
The token bucket specification includes a bucket rate r and a bucket
depth, b. Both r and b must be positive. The rate, r, is measured
in bytes of IP datagrams per second. Values of this parameter may
range from 1 byte per second to 40 terabytes per second. Network
elements MUST return an error for requests containing values outside
this range. Network elements MUST return an error for any request
containing a value within this range which cannot be supported by the
element. In practice, only the first few digits of the r parameter
are significant, so the use of floating point representations,
accurate to at least 0.1% is encouraged.
The bucket depth, b, is measured in bytes. Values of this parameter
may range from 1 byte to 250 gigabytes. Network elements MUST return
an error for requests containing values outside this range. Network
elements MUST return an error for any request containing a value
within this range which cannot be supported by the element. In
practice, only the first few digits of the b parameter are
significant, so the use of floating point representations, accurate
to at least 0.1% is encouraged.
The range of values allowed for these parameters is intentionally
J. Wroclawski Expires 5/96 [Page 5]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
large to allow for future network technologies. Any given network
element is not expected to support the full range of values.
The minimum policed unit, m, is an integer measured in bytes. All IP
datagrams less than size m will be counted against the token bucket
as being of size m. The maximum packet size, M, is the biggest packet
that will conform to the traffic specification; it is also measured
in bytes. Network elements MUST reject a service request if the
requested maximum packet size is larger than the MTU of the link.
Both m and M must be positive, and m must be less then or equal to M.
The preferred concrete representation for the TSpec is two floating
point numbers in single-precision IEEE floating point format followed
by two 32-bit integers in network byte order. The first value is the
rate (r), the second value is the bucket size (b), the third is the
minimum policed unit (m), and the fourth is the maximum packet size
(M).
Exported Information
The controlled-load service is assigned service_name 5.
The controlled-load service has no required characterization
parameters. Specific implementations may export appropriate
measurement and monitoring information.
Policing
The controlled-load service is suitable for use with multicast as
well as unicast data flows. This capability introduces some
complexity into the policing requirements.
Controlled-load traffic must be policed for conformance to its TSpec
at every network element. The TSpec's token bucket parameters require
that traffic must obey the rule that over all time periods, the
amount of data sent does not exceed rT+b, where r and b are the token
bucket parameters and T is the length of the time period. For the
purposes of this accounting, links must count packets that are
smaller than the minimal policing unit to be of size m. Packets that
arrive at an element and cause a violation of the the rT+b bound are
considered nonconformant.
At all policing points, non-conforming packets are treated as BEST-
EFFORT datagrams. (See the NOTEs below for further discussion of this
J. Wroclawski Expires 5/96 [Page 6]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
issue).
If resources are available, it is desirable for the policing function
at points within the interior of the network (but *not* at edge
traffic entry points) to enforce slightly "relaxed" traffic
parameters to accommodate packet bursts somewhat larger than the
actual TSpec.
Other actions, such as reshaping the traffic stream (delaying packets
until they are compliant), are not allowed.
NOTE: RESHAPING. The prohibition on delaying packets is one of
many possible design choices. It may be better to permit some
delaying of a packet if that delay would allow it to pass the
policing function. (In other words, to reshape the traffic). The
challenge is to define a viable reshaping function.
Intuitively, a plausible approach is to allow a delay of (roughly)
up to the maximum queueing delay experienced by completely
conforming packets before declaring that a packet has failed to
pass the policing function. The merit of this approach, and the
precise wording of the specification that describes it, require
further study.
NOTE: INTERACTION WITH BEST-EFFORT TRAFFIC. Implementors of this
service should clearly understand that in certain circumstances
(routers acting as the "split points" of a multicast distribution
tree supporting a shared reservation) large numbers of packets may
fail the policing test *as a matter of normal operation*.
According to the definition above, these packets should be
processed as best-effort packets.
If the network element's best-effort queueing algorithm does not
distinguish between these packets and elastic best-effort traffic
such as TCP flows, THESE PACKETS WILL "BACK OFF" THE ELASTIC
TRAFFIC AND DOMINATE THE BEST-EFFORT BANDWIDTH USAGE. The
integrated services framework does not currently address this
issue. However, several possible solutions to the problem are
known [RED, xFQ]. Network elements supporting the controlled load
service should also implement some mechanism in their best-effort
queueing path to discriminate between classes of best-effort
traffic and provide elastic traffic with protection from inelastic
best-effort flows.
NOTE: EDGE POLICING. The text above specifys that the policing
J. Wroclawski Expires 5/96 [Page 7]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
function treats non-conformant packets as best-effort at all
points. A possible alternative is to replace this with language
reading:
At points where traffic first enters the network (end-nodes),
non-conforming packets are DROPPED. At these points, the
reservation setup mechanism must ensure that the TSpec used is
*no smaller* than the TSpec specified by the source for the
traffic it is generating.
At all other policing points, non-conforming packets are treated
as BEST-EFFORT datagrams.
The effect of this change is significant. Under the non-dropping
model, it is possible for a source to vastly over-send its TSpec,
with the excess packets being delivered if conditions permit. The
service offered in this case has been described as "best-effort-
with-floor"; essentially a best-effort delivery service with
enough resources reserved for a certain minimum traffic level.
Under the dropping model, the service loses its "best-effort-
with-floor" characteristics, and becomes essentially a fixed-
traffic-level service. In return, it offers significantly more
protection against overload of the network resources and
degradation of other flows' QoS.
NOTE: ARCHITECTURAL OPTIONS. The text above specifies a functional
and consistant model for policing of controlled-load data which
can be implemented within the current IP protocols.
In this model, it is necessary to police at every network element
because the policing function does not actually drop traffic which
exceeds the TSpec, but instead carries it as best-effort. Since
there is no end-to-end mechanism in place to limit a controlled-
load flow's traffic to the TSpec value, every network element must
perform this function for itself. Since excess controlled-load
traffic (traffic above the TSpec) is not dropped, every network
element should also perform the best-effort service discrimination
function described above.
The alternative option of "marking" packets which have failed the
policing test at some node is not available within the current IP
protocol. If marking were available, it would be necessary to
police only at certain points within the network. In this case,
the relevant language above might be replaced with a paragraph
J. Wroclawski Expires 5/96 [Page 8]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
reading:
Policing is performed at the edge of the network, at all
heterogeneous source branch points and at all source merge
points. A heterogeneous source branch point is a spot where the
multicast distribution tree from a source branches to multiple
distinct paths, and the TSpec's of the reservations on the
various outgoing links are not all the same. Policing need only
be done if the TSpec on the outgoing link is "less than" (in the
sense described in the Ordering section) the TSpec reserved on
the immediately upstream link. A source merge point occurs when
the multicast distribution trees from two different sources
(sharing the same reservation) merge. It is the responsibility
of the invoker of the service (a setup protocol, local
configuration tool, or similar mechanism) to identify points
where policing is required. Policing is allowed at points other
than those mentioned above.
Note that the best-effort traffic discrimination function
described above must still be performed at every network element.
In this case, the discrimination might be based in part on the
mark bit.
At all network elements, packets bigger than the outgoing link MTU
must be considered nonconformant and classified as best effort (and
will then either be fragmented or dropped according to the element's
handling of best effort traffic). It is expected that this situation
will not arise with any frequency, because flow setup mechanisms are
expected to notify the sending application of the appropriate path
MTU.
Ordering and Merging
The controlled-load service TSpec is ordered according to the
following rule: TSpec A is a substitute for ("as good or better
than") TSpec B if and only if
(1) both the token bucket depth and rate for TSpec A are greater
J. Wroclawski Expires 5/96 [Page 9]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
than or equal to those of TSpec B,
(2) the minimum policed unit m is at least as small for TSpec A as
it is for TSpec B, and
(3) the maximum packet size M is at least as large for TSpec A as
it is for TSpec B.
A merged TSpec may be calculated over a set of TSpecs by taking the
largest token bucket rate, largest bucket size, smallest minimal
policed unit, and largest maximum packet size across all members of
the set. This use of the word "merging" is similar to that in the
RSVP protocol; a merged TSpec is one that is adequate to describe the
traffic from any one of a number of flows.
The sum of n controlled-load service TSpecs is used when computing
the TSpec for a shared reservation of n flows. It is computed by
taking:
- The minimum across all TSpecs of the minimum policed unit
parameter m.
- The maximum across all TSpecs of the maximum packet size
parameter M.
- The sum across all TSpecs of the token bucket rate parameter r.
- The sum across all TSpecs of the token bucket size parameter b.
The perfect minimum of two TSpecs is defined as a TSpec which would
view as compliant any traffic flow that complied with both of the
original TSpecs, but would reject any flow that was non-compliant
with at least one of the original TSpecs. This perfect minimum can be
computed only when the two original TSpecs are ordered, in the sense
described above.
A definition for computing the minimum of two unordered TSpecs is:
- The minimum of the minimum policed units m.
- The maximum of the maximum packet sizes M.
J. Wroclawski Expires 5/96 [Page 10]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
- The minimum of the token bucket rates r.
- The maximum of the token bucket sizes b.
NOTE: The proper definition the minimum TSpec function is a topic
of current discussion. The definition above is provisional and
subject to change.
Guidelines for Implementors
The intention of this service specification is that network elements
deliver a level of service closely approximating best-effort service
under unloaded conditions. As with best-effort service under these
conditions, it is not required that every single packet must be
successfully delivered with zero queueing delay. Network elements
providing controlled-load service are permitted to oversubscribe the
available resources to some extent, in the sense that the bandwidth
and buffer requirements indicated by summing the TSpec token buckets
of all controlled-load flows may exceed the maximum capabilities of
the network element. However, this oversubscription may only be done
in cases where the element is quite sure that actual utilization is
far less than the sum of the token buckets would suggest. The most
conservative approach, rejection of new flows whenever the addition
of their traffic would cause the sums of the token buckets to exceed
the capacity of the network element, may be appropriate in other
circumstances.
Specific issues related to this subject are discussed in the
"Evaluation Criteria" and "Examples of Implementation" sections
below.
Implementors are encouraged (but not required) to implement policing
behavior (the behavior seen when a flow's actual traffic exceeds its
TSpec) which closely approximates the behavior of well-designed
best-effort services under overload. In particular, it is undesirable
to employ queueing models which lead to heavily bi-modal delay
distributions or large numbers of mis-ordered packet arrivals.
J. Wroclawski Expires 5/96 [Page 11]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
Evaluation Criteria
The basic requirement placed on an implementation of controlled-load
service is that, under all conditions, it provide accepted data flows
with service closely similar to the service that same flow would
receive using best-effort service under unloaded conditions.
This suggests a simple two-step evaluation strategy. Step one is to
compare the service given best-effort traffic and controlled-load
traffic under underloaded conditions.
- Measure the packet loss rate and delay characteristics of a test
flow using best-effort service and with no load on the network
element.
- Compare those measurements with measurements of the same flow
receiving controlled-load service with no load on the network
element.
Closer measurements indicate higher evaluation ratings. A
substantial difference in the delay characteristics, such as the
smoothing which would be seen in an implementation which scheduled
the controlled-load flow using a fixed, constant-bitrate algorithm,
should result in a somewhat lower rating.
Step two is to observe the change in service received by a
controlled-load flow as the load increases.
- Increase the background traffic load on the network element,
while continuing to measuring the loss and delay characteristics of
the controlled-load flow. Characteristics which remain essentially
constant as the element is driven into overload indicate a high
evaluation rating. Minor changes in the delay distribution indicate
a somewhat lower rating. Significant increases in delay or loss
indicate a poor evaluation rating.
This simple model is not adequate to fully evaluate the performance
of controlled-load service. Three additional variables affect the
evaluation. The first is the short-term burstiness of the traffic
J. Wroclawski Expires 5/96 [Page 12]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
stream used to perform the tests outlined above. The second is the
degree of long-term change in the controlled-load traffic within the
bounds of its TSpec. (Changes in this characteristic will have great
effect on the effectiveness of certain admission control algorithms.)
The third is the ratio of controlled-load traffic to other traffic at
the network element (either best effort or other controlled
services).
The third variable should be specifically evaluated using the
following procedure.
With no controlled-load flows in place, overload the network
element with best-effort traffic (as indicated by substantial
packet loss and queueing delay).
Execute requests for controlled-load service giving TSpecs with
increasingly large rate and burst parameters. If the request is
accepted, verify that traffic matching the TSpec is in fact handled
with characteristics closely approximating the unloaded
measurements taken above.
Repeat these experiments to determine the range of traffic
parameter (rate, burst size) values successfully handled by the
network element. The useful range of each parameter must be
determined for several settings of the other parameter, to map out
a two-dimensional "region" of successfully handled TSpecs. When
compared with network elements providing similar capabilities, this
region indicates the relative ability of the elements to provide
controlled-load service under high load. A larger region indicates
a higher evaluation rating.
Examples of Implementation
One possible implementation of controlled-load service is to provide
a queueing mechanism with two priority levels; a high priority one
for controlled-load and a lower priority one for best effort service.
An admission control algorithm is used to limit the amount of traffic
placed into the high-priority queue. This algorithm may be based
either on the specified characteristics of the high-priority flows
(using information provided by the TSpecs), or on the measured
characteristics of the existing high-priority flows and the TSpec of
the new request.
J. Wroclawski Expires 5/96 [Page 13]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
Another possible implementation of controlled-load service is based
on the existing capabilities of network elements which support
"traffic classes" based on mechanisms such as weighted fair queueing
or class-based queueing [xxx]. In this case, it is sufficient to map
data flows accepted for controlled-load service into an existing
traffic class with adequate capacity to avoid overload. This
requirement is enforced by an admission control algorithm which
considers the characteristics of the traffic class, the
characteristics of the traffic already admitted to the class, and the
TSpec of the new flow requesting service. Again, the admission
control algorithm may be based either on the TSpec-specified or the
measured characteristics of the existing traffic.
Admission control algorithms based on specified characteristics are
likely be appropriate when the number of flows in the high-priority
class is small, or the traffic characteristics of the flows appear
highly variable. In these situations the measured behavior of the
aggregate controlled-load traffic stream may not serve as an
effective predictor of future traffic, leading a measurement-based
admission control algorithm to produce incorrect results. Conversely,
in situations where the past behavior of the aggregate controlled-
load traffic *is* a good predictor of future behavior, a
measurement-based admission control algorithm may allow more traffic
to be admitted to the controlled-load service class with no
degradation in performance. An implementation may choose to switch
between these two approaches depending on the nature of the traffic
stream at a given time.
Examples of Use
The controlled-load service may be used by any application which can
make use of best-effort service, but is best suited to those
applications which can usefully characterize their traffic
requirements. Applications based on the transport of "continuous
media" data, such as digitized audio or video, are an important
example of this class.
The controlled-load service is not isochronous and does not provide
any explicit information about transmission delay. For this reason,
applications with end-to-end timing requirements, including the
continuous-media class mentioned above, provide an application-
specific timing recovery mechanism, similar or identical to the
mechanisms required when these applications use best-effort service.
A protocol useful to applications requiring this capability is the
IETF Real-Time Transport Protocol [2].
J. Wroclawski Expires 5/96 [Page 14]
INTERNET-DRAFT draft-ietf-intserv-ctrl-load-svc-00.txt November, 1995
Load-sensitive applications may choose to request controlled-load
service whenever they are run. Alternatively, these applications may
monitor their own performance and request controlled-load service
from the network only when best-effort service is not providing
acceptable performance. The first strategy provides higher assurance
that the level of quality delivered to the user will not change over
the lifetime of an application session. The second strategy provides
greated flexibility and offers cost savings in environments where
levels of service above best-effort incur a charge.
Security Considerations
Security considerations are not discussed in this memo.
References
[1] S. Shenker and J. Wroclawski. "Network Element Service
Specification Template", Internet Draft, June 1995, <draft-ietf-
intserv-svc-template-01.txt>
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP:
A Transport Protocol for Real-Time Applications", Internet Draft,
March 1995, <draft-ietf-avt-svc-rtp-07.txt>
Authors' Address:
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
jtw@lcs.mit.edu
617-253-7885
617-253-2673 (FAX)
J. Wroclawski Expires 5/96 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 07:11:37 |