Subject: draft-ietf-intserv-predictive-svc-00.txt

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

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                   S. Shenker/C. Partridge
draft-ietf-intserv-predictive-svc-00.txt                       Xerox/BBN
                                                             March, 1995
                                                         Expires: 9/1/95

             Specification of Predictive 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 predictive 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 second of what is expected to be a series of Service
   Definitions for quality of service in the Internet.  This memo
   defines a predictive service which advertises a maximum (and
   optionally) a current delay bound.

   A predictive service provides very high probability that the end-to-
   end delay experienced by packets in a flow will not exceed a known
   limit, assuming that there are no hard failures in the intermediate
   nodes or packet routing changes within the lifetime of the flow
   (these issues are handled at higher levels of the protocol).  In
   addition, the service may attempt to deliver packets with less delay

Shenker/Partridge            Expires 9/1/95                     [Page 1]
INTERNET-DRAFT  draft-ietf-intserv-predictive-svc-00.txt     March, 1995

   than the long-term limit when network resources permit.

   This memo defines requirements for network elements that support the
   predictive 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 will advertise in return.

   The memo uses the terms "network element" and "element" to mean 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

   Predictive service is designed for playback applications which are
   tolerant of occasional missed playback points.  The presence of delay
   bounds serves two functions.  First, they provide some
   characterization of the service so that a non-service-adaptive
   application (that is, an application that does not want to
   continually change its service request in response to current
   conditions) can know beforehand the worst delays its packets will
   experience in a given service class.  These bounds will allow such
   applications to choose an appropriate service class.  Second, such
   delay bounds can help applications which are not interested in
   adapting to current delays to set their playback point.  This service
   is subject to admission control.

Per-hop Service

   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.  Each level is associated with a delay bound,
   with level 1 having the smallest delay bound and level 3 the largest.
   The network element must assure that the packet delays are below the
   specified delay bound.  There can be occasional violations of these
   delay bounds, but the intention is that these violations are very
   rare.  This control must be active, in that the element must be able
   to control admissions to the element.  In particular,
   overprovisioning alone is not sufficient to deliver predictive
   service.

Shenker/Partridge            Expires 9/1/95                     [Page 2]
INTERNET-DRAFT  draft-ietf-intserv-predictive-svc-00.txt     March, 1995

Advertisements

   Two delay bounds are advertised.  The first is the long-term delay
   bound, the delay value within which the predictive service is trying
   to keep all traffic for this flow, regardless of traffic loading.
   The second bound is optional, and reflects the likely high bound on
   delay given the current traffic loading.

   The long-delay bound is computed via an additive composition rule;
   the maximum delay at each hop is added to the current cumulative
   delay along the path.  A conformant network element must provide its
   hop delay information.

   The instantaneous delay is an optional advertisement, and it also has
   an additive composition rule.  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.

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 maps the target-delay into the service level with
   the largest delay bound smaller than the target-delay.  If no such
   level exists, then the target-delay is mapped into service level 1.

   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

Shenker/Partridge            Expires 9/1/95                     [Page 3]
INTERNET-DRAFT  draft-ietf-intserv-predictive-svc-00.txt     March, 1995

   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 long-term delay to choose from.  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 except on rare
   occasions, the experienced delays are below the long-term bounds.

   This service assumes that adaptive applications are capable of
   measuring and adapting to delays themselves, so the optional
   instantaneous delay bounds are simply hints.  They may be useful to
   adaptive applications when the applications compute new playback
   points, or when trying to decide whether to shift from one level of
   service to another.

Evaluation Criteria

   In this section we sketch a methodology for testing a network
   element's predictive 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 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).  This traffic mix should be made up of
   several individual flows (i.e., distinct streams of traffic).  For
   each load level, one measures the mean delays and the packet loss
   rate for each level of service (including best effort).  In addition,
   for each predictive flow, one measures the mean delay and the number
   of times that the packet delay exceeded the advertised maximum delay
   for the flow.  Each test run at a particular load should involve

Shenker/Partridge            Expires 9/1/95                     [Page 4]
INTERNET-DRAFT  draft-ietf-intserv-predictive-svc-00.txt     March, 1995

   enough traffic that is a reasonable predictor of the performance a
   long-lived application such as a video conference would experience
   (e.g., several minutes of traffic).

   A conformant network element will have two characteristics.  First,
   the fraction of packets which exceed the advertised delay will be
   very small, substantially less than 3% overall and less than 5% for
   an individual flow. [Are these the right numbers?]  Second it 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]

--WAA11303.796014789/mercury.lcs.mit.edu--