Subject: new version of protected best effort spec

From: Juha Heinanen <[email-masked]>
Date: Thu, 13 Jun 1996 19:59:26 +0300

i just submitted the following new version of the protected best effort
service spec to the internet-drafts editor.  it tried to address some of
the issues brought up in the la meeting, namely:

- relaxed definition of fairness (max-min fairness is no longer
  required) 

- relaxed treatment of ordinary best effort flows (a pbe flow will
  always receive at least as much resources as any unprotected one)

unfortunately i don't have a change to participate in the next meeting,
but thought to make this revised version anyhow in order to keep it on
the table.  comments via the mailing list are of course welcome.

-- juha
----------------------------------------------------

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                             Juha Heinanen
draft-heinanen-pbe-svc-02.txt                       Telecom Finland Inc.
                                                            June 9, 1996

                     Protected Best Effort Service

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 mate-
   rial 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 has been submitted to 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-
   [email-masked] and/or the author.

Abstract

   This document specifies the Protected Best Effort (PBE) service that
   provides to the application an isolated best effort flow with an
   optional minimum bandwidth.

Introduction

   This document defines the requirements for network elements that sup-
   port the Protected Best Effort (PBE) service.  The end-to-end behav-
   ior provided to an application by a series of network elements con-
   forming to this specification is

   - at least fair share of the bandwidth available for best effort
     traffic along the path of the application's data flow or at least a
     minimum bandwidth whichever is larger,

Heinanen                Expires December 9, 1996                [Page 1]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

   - fair transit delay among best effort data flows that share the same
     network elements, and

   - ordered delivery of packets as long as the network path of the
     application's data flow doesn't change.

   When counting the fair share of the bandwidth available for best
   effort traffic, the sum of minimum bandwidths is first decremented
   from the total best effort bandwidth.

   To ensure that the above behavior can be met, an application request-
   ing PBE service provides the network elements with a Minimum Accept-
   able Bandwidth (MAB).  A network element that correctly implements
   the PBE service, doesn't need to support MAB values > 0.

   The application may not assume successful delivery of packets sent at
   a rate which is higher than the MAB, since there may not be more
   bandwidth available on the path for best effort traffic.  Further,
   the application may not assume any given upper bound for transit
   delay or jitter, since the number of best effort data flows that
   share the same network path can change dynamically.

Motivation

   The PBE service is intented to support any non-real-time application
   that is developed for use in today's internets.  In particular, the
   PBE service is suitable for applications that don't require a given
   maximum delay or delay variation and that can't characterize their
   traffic requirements in terms of average data rates and maximum burst
   lengths.  The PBE service differs from the conventional (= unpro-
   tected) best effort service in that it guarantees bandwidth and delay
   fairness by isolating the PBE data flows from other (protected and
   unprotected) best effort flows.  If all the network elements along
   the path of the application's data flow support a greater than zero
   MAB, then the PBE service can also be used to provide an upper bound
   for the time it takes to transfer the information across the network.

Network Element Data Handling Requirements

   Each network element accepting a request for a PBE service must
   ensure that adequate network element and link resources are available
   to handle the requested level of traffic as given by the MAB in the
   requestor's TSpec.  This must be accomplished through active admis-
   sion control.  A network element may employ statistical methods to
   decide whether adequate resources are available to accept the service
   request.

   Links are not permitted to fragment packets which receive the PBE

Heinanen                Expires December 9, 1996                [Page 2]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

   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 PBE service is invoked by specifying the data flow's requested
   traffic parameters (TSpec).  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 order-
   ing rules given below) should never be denied service.

   The TSpec consists of a rate (MAB), a minimum policed unit (m), and a
   maximum packet size (M).  MAB 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 MAB parameter are significant, so the use of float-
   ing point representations, accurate to at least 0.1% is encouraged.

   The range of values allowed for these parameters is intentionally
   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 MAB 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 maxi-
   mum 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 one floating
   point number in single-precision IEEE floating point format followed
   by two 32-bit integers in network byte order.  The first value is the
   rate (MAB), the second value is the minimum policed unit (m), and the
   third is the maximum packet size (M).

Exported Information

   The PBE service is assigned service_name X.

   The PBE service has no required characterization parameters. Specific
   implementations may export appropriate measurement and monitoring

Heinanen                Expires December 9, 1996                [Page 3]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

   information.

Policing

   PBE traffic must be policed for conformance at each network element.
   All PBE traffic that exceeds either the flow's fair share of the net-
   work element's best effort resources or MAB*T over all time periods T
   (whichever is larger) is considered nonconformant.  For the purposes
   of this accounting, network elements must count packets that are
   smaller than the minimal policing unit to be of size m.

   The flow is defined to receive its fair share of the network ele-
   ment's best effort resources if it is not arbitralily or persistently
   favored or penalized as compared to other best effort flows sharing
   the same set of network resources.  When counting a flow's fair share
   of the network element's best effort resources, the sum of MABs is
   first decremented from the total best effort resources.

   A network element may discard nonconforming PBE packets, but should
   not do so as long as it has enough buffering resources available to
   protect conforming PBE flows, i.e., flows that are currently using
   less than their share of the network element's best effort resources.
   Conversely, the network element must discard nonconforming packets if
   buffering resources would not otherwise be adequate to accommodate
   new packets belonging to conforming PBE flows.

   Although this section only defines policing of PBE flows, it follows
   from the above that also unprotected best effort traffic must be
   policed in order to guarantee each PBE flow its fair share of the
   network element's overall best effort resources.  Since no fairness
   guarantees apply to unprotected best effort flows, the minimum
   requirement is that unprotected best effort flows are policed as an
   aggregate to receive AT MOST their combined fair share of the avail-
   able best effort resources.

   At all network elements, packets bigger than the outgoing link MTU
   are considered nonconformant and must be discarded.

   (I would like to add to the TSpec Peak Rate parameter that tells the
   maximum bandwidth ever possibly available for PBE traffic on the cur-
   rent path and then police all PBE traffic also according to this
   parameter.  It doesn't namely make sense to allow traffic to the net-
   work that possibly can't get through at later network elements.  The
   value of the Peak Rate parameter is determined using the path mes-
   sage.)

Heinanen                Expires December 9, 1996                [Page 4]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

Ordering and Merging

   The PBE 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) MAB for TSpec A is greater 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 MAB, 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 PBE 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 parameter MAB.

   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.

   - The minimum of the rates MAB.

Heinanen                Expires December 9, 1996                [Page 5]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

Guidelines for Implementors

   Network elements providing the PBE service are permitted to oversub-
   scribe the available resources to some extent, in the sense that the
   MAB requirements indicated by summing the TSpec MAB values of all PBE
   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 MABs would suggest. The most conservative approach, rejec-
   tion of new flows whenever the addition of their traffic would cause
   the sum of the MABs to exceed the capacity of the network element,
   may be appropriate in other circumstances.

Evaluation Criteria

   The quality of a PBE implementation can be evaluated by measuring the
   degree of bandwidth and delay fairness it provides to PBE flows shar-
   ing the same network path.  In addition, it can be measured that the
   bandwidth available to a PBE flow is always at least MAB and that
   unprotected best effort traffic can't get more resources than their
   aggregate fair share.

   A bandwidth fairness is commonly measured using the so-called parking
   lot configuration.  The service is bandwidth fair if each flow
   receives an equal amount of bandwidth no matter how many network ele-
   ments it has traversed.

   Delay fairness can be evaluated by measuring that the delay of a
   packets only depends on the number of the simultaneously active flows
   on the path.  The delay should increase linearly when new flows
   become active, but should not depend on the bandwidth of each flow.

Examples of Implementation

   One possible implementation of the PBE service uses a fair queuing
   mechanism where each best effort flow has its own queue that is ser-
   viced in a round robin fashion or at least so often that the flow can
   be guaranteed its MAB.

Security Considerations

   Security considerations are not discussed in this memo.

Acknowledgements

   This specification was created using the Controlled-Load Network Ele-
   ment Service specification [3] as the template.

Heinanen                Expires December 9, 1996                [Page 6]

INTERNET-DRAFT                 PBE Service                  June 9, 1996

References

   [1] Bertsekas, D., and R. Galager, Data Networks, Prentice Hall,
       1987.

   [2] Jaffe, J., Bottleneck Flow Control, IEEE Trans. Communications,
       July 1981.

   [3] Wroclawski, J., Specification of the Controlled-Load Network Ele-
       ment Service.  Internet draft, November, 1995.

Authors' Addresses

   Juha Heinanen
   Telecom Finland Inc.
   PO Box 228
   FI-33101 Tampere
   Finland

   Phone: +358 400 500 958
   Email: [email-masked]

Heinanen                Expires December 9, 1996                [Page 7]