Subject: draft-ietf-intserv-controlled-delay-svc-00.txt

From: John Wroclawski <[email-masked]>
Date: Thu, 23 Mar 1995 22:21:56 -0500

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                   S. Shenker/C. Partridge
draft-ietf-intserv-controlled-delay-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
   [email-masked] 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
   [email-masked]
   415-812-4840
   415-812-4471 (FAX)

   Craig Partridge
   BBN
   2370 Amherst St
   Palo Alto CA 94306
   [email-masked]

Shenker/Partridge            Expires 9/1/95                     [Page 5]