Internet-Draft                                 EF RESOLVE DESIGN TEAM
                                                   (Grenville Armitage)
                                                       (Alessio Casati)
                                                        (Jon Crowcroft)
                                                         (Joel Halpern)
                                                        (Brijesh Kumar)
                                                      (John Schnizlein)

                                                    November 12th, 2000 (Informational)                      Grenville Armitage
                                                        Alessio Casati
                                                         Jon Crowcroft
                                                          Joel Halpern
                                                         Brijesh Kumar
                                                       John Schnizlein

                                                      April 20th, 2001

             A revised expression Delay Bound alternative revision of the Expedited Forwarding PHB
                  <draft-ietf-diffserv-efresolve-00.txt> RFC2598
                 <draft-ietf-diffserv-efresolve-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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."

    The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The

   To view the list of Internet-Draft Shadow Directories can be accessed at Directories, see
   http://www.ietf.org/shadow.html.

   This document was submitted to the IETF Differentiated Services
   (DiffServ) WG.  Publication of this document does not imply
   acceptance by the DiffServ WG of any ideas expressed within.
   Comments should be submitted to the diffserv@ietf.org mailing list.

   Distribution of this memo is unlimited.

Abstract

    RFC 2598 is

   At the DiffServ Pittsburgh IETF meeting in August 2000, the Differentiated
   Services working group faced serious questions regarding RFC2598 -
   the group's current standards track definition of the Expedited Forwarding
   (EF) Per Hop Behavior (PHB)
    [1]. As part of the DiffServ working group's ongoing refinement (PHB). An 'EF Design Team' volunteered to
   develop a re-expression of RFC2598, bearing in mind the EF PHB, additional issues were raised with the text
   in RFC 2598
    [2]. An 'EF design team' was formed after the Pittsburgh DiffServ group.  At the San Diego IETF meeting in December
   2000 the DiffServ working group decided to synthesize a new pursue an alternative re-
   expression of the EF PHB. This Internet Draft For historical interest this document
   captures our feedback to the DiffServ WG on a EF Design Team's proposed revision to solution, preferred by the
   original authors of RFC2598 but not adopted by the working group in
   December 2000. The original definition of EF was based on comparison
   of forwarding on an unloaded network. This experimental Delay Bound
   (DB) PHB definition. A formal revision requires a bound on the delay of packets due to RFC 2598 will be derived
    from this document. other
   traffic in the network.

Specification of Requirements

    The

   This document is for Informational purposes only.  If implementors
   choose to experiment with the DB PHB, key words "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in
   RFC 2119 [3].

1 Introduction

   RFC 2598 is was the Differentiated Services (DiffServ) working group's
    current
   first standards track definition of the Expedited Forwarding (EF) Per
   Hop Behavior (PHB) [1]. As part of the DiffServ working group's
   ongoing refinement of the EF PHB, additional various issues were raised with the
   text in RFC 2598 [2]. An

   After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF
   design team' was formed after the
    Pittsburgh IETF meeting (the authors of this document) to synthesize propose a
   new expression of the EF PHB.
    This Internet Draft The remainder of this Informational
   document captures our feedback to the DiffServ WG working group at the
   San Diego IETF in December 2000.  Our solution focussed on a
    proposed revision to Delay
   Bound (DB) based re-expression of RFC 2598 which met the goals of
   RFC2598's original authors.  The DiffServ working group ultimately
   chose an alternative re-expression of the EF PHB definition.

    A formal revision text, developed by
   the authors of [2] and revised to RFC 2598 will be derived from this document. additionally encompass our model
   described here.

   Our proposed Delay Bound solution is archived for historical
   interest.  Section 2 covers the minimum, necessary and sufficient
   description of what we believed qualifies as 'EF' 'DB' behavior from a
   single node. Section 3 then discusses a number of issues and
   assumptions made to support the definition in section 2.

2. Definition of Expedited Forwarding Delay Bound forwarding

   For a traffic stream not exceeding a particular configured rate the
   goal of the
    EF DB PHB is a strict bound on the delay variation of
   packets through a hop.

    When a DS-compliant node claims to implement the EF PHB, the
    implementation MUST conform to the specification given in this
    document. However, the EF PHB is not a mandatory part of the
    Differentiated Services architecture - a node is NOT REQUIRED to
    implement the EF PHB in order to be considered DS-compliant.

   This section will begin with the goals and necessary boundary
   conditions for EF DB behavior, then provide a descriptive definition of
    EF
   DB behavior itself, discuss what it means to conform to the EF DB
   definition, and assign the default EF experimental DB PHB code point.

2.1 Goal and Scope of EF DB

   For a traffic stream not exceeding a configured rate the goal of the
    EF
   DB PHB is a strict bound on the delay variation of packets through a
   hop.

   Traffic MUST be policed and/or shaped at the source edge (for
   example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
   order to get such a bound.  However, specific policing and/or shaping
   rules are outside the scope of the EF DB PHB definition.  Such rules
   MUST be defined in any per-domain behaviors (PDBs) composed from the
    EF
   DB PHB.

   A device (hop) delivers EF DB behavior to appropriately marked traffic
   received on one or more interfaces (marking is specified in section
   2.4).  A device SHALL deliver the EF DB behavior on an interface to EF DB
   marked traffic meeting (i.e. less than or equal) a certain arrival
   rate limit R.

   If more EF DB traffic arrives than is acceptable, the device is NOT
   REQUIRED to deliver the EF DB behavior. However, although the original
   source of EF DB traffic will be shaped, aggregation and upstream jitter
   ensure that the traffic arriving at any given hop cannot be assumed
   to be so shaped.  Thus an EF DB implementation SHOULD have some
   tolerance for burstiness - the ability to provide EF behavior even
   when the arrival rate exceeds the rate limit R.

   Different EF DB implementations are free to exhibit different tolerance
   to burstiness.  (Burstiness MAY be characterized in terms of the
   number of back-to-back wire-rate packets to which the hop can deliver
    EF
   DB behavior. However, since the goal of characterizing burstiness is
   to allow useful comparison of EF DB implementations, vendors and users
   of EF DB implementations MAY choose to utilize other burstiness
   metrics.)

   The EF DB PHB definition does NOT mandate or recommend any particular
   method for achieving EF DB behavior. Rather, the EF DB PHB definition
   identifies parameters that bound the operating range(s) over which an
   implementation can deliver EF DB behavior. Implementors characterize
   their implementations using these parameters, while network designers
   and testers use these parameters to assess the utility of different
    EF
   DB implementations.

2.2 Description of EF DB behavior

   For simplicity the definition will be explained using an example
   where traffic arrives on only one interface and is destined for
   another (single) interface.

   The crux of this definition is that the difference in time between
   when a packet might have been delivered, and when it is delivered,
   will never exceed a specifiable bound.

   Given an acceptable (not exceeding arrival rate limit R) stream of EF DB
   packets arriving on an interface:

      There is a time sequence E(i) when these packets would be
      delivered at the output interface in the absence of competing
      traffic.  That is, E(i) are the earliest times that the packets
      could be delivered by the device.

      In the presence of competing traffic, the packets will be delayed
      to some later time D(i).

   Competing traffic includes all EF DB traffic arriving at the device on
   other ports, and all non-EF non-DB traffic arriving at the device on any
   port.

    EF

   DB is defined as the behavior which ensures, for all i, that:

      D(i) - E(i) <=  S * MTU/R.

   MTU is the maximum transmission unit (packet size) of the output.
   R is the arrival rate that the EF DB device is prepared to accept on
   this interface.

   Note that D(i) and E(i) simply refer to the times of what can be
   thought of as "the same packet" under the two treatments (with and
   without competing traffic).

   The score, S, is a characteristic of the device at the rate, R, in
   order to meet this defined bound. This score, preferably a small
   constant, depends on the scheduling mechanism and configuration of
   the device.

2.3 Conformance to EF DB behavior

   An implementation need not conform to the EF DB specification over an
   arbitrary range of parameter values. Instead, implementations MUST
   specify the rates, R, and scores S, for which they claim conformance
   with the EF DB definition in section 2.2, and the implementation-
   specific configuration parameters needed to deliver conformant
   behavior. An implementation SHOULD document the traffic burstiness it
   can tolerate while still providing EF DB behavior.

   The score, S, and configuration parameters depend on the
   implementation error from an ideal scheduler. Discussion of the
   ability of any particular scheduler to provide EF DB behavior, and the
   conditions under which it might do so, is outside the scope of this
   document.

   The implementor MAY define additional constraints on the range of
   configurations in which EF DB behavior is delivered.  These constraints
   MAY include limits on the total EF DB traffic across the device, or
   total EF DB traffic targetted at a given interface from all inputs.

   This document does not specify any requirements on an EF DB
   implementation's values for R, S, or tolerable burstiness.  These
   parameters will be bounded by real-world considerations such as the
   actual network being designed and the desired PDB.

2.4 Marking for EF DB behavior

   One or more DiffServ codepoint (DSCP) values may be used to indicate
   a requirement for EF DB behavior [4].

   By default a we suggest an 'experimental' DSCP of 101110 indicates 101111 be used to
   indicate that EF DB PHB is required.

3. Discussion

   This section discusses some issues that might not be immediately
   obvious from the definition in section 2.

3.1 Mutability

   Packets marked for EF DB PHB MAY be remarked at a DS domain boundary
   only to other codepoints that satisfy the EF DB PHB.  Packets marked for
    EF
   DB PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
   domain.

3.2 Tunneling

   When EF DB packets are tunneled, the tunneling packets must be marked as
    EF.
   DB.

3.3 Interaction with other PHBs
   Other PHBs and PHB groups may be deployed in the same DS node or
   domain with the EF DB PHB as long as the requirement of section 2 is
   met.

3.4 Output Rate not specified

   The definition of EF DB behavior given in section 2 is quite explicitly
   given in terms of input rate R and output delay variation D(i) -
   E(i). A scheduler's output rate does not need to be specified, since
   (by design) it will be whatever is needed to achieve the target delay
   variation bounds.

3.5 Jitter

   Jitter is not the bounded parameter in EF DB behavior.  Jitter can be
   understood in a number of ways, for example the variability in inter-
   packet times from one inter-packet interval to the next. However, EF DB
   behavior aims to bound a related but different parameter - the
   variation in delay between the time packets would ideally depart, depart in the
   absence of competing traffic, E(i), and when they would depart in the
   presence of competing traffic, D(i).

3.6 Multiple Inputs and/or Multiple Outputs

   The definition of 'competing traffic' in section 2.2 covers both the
   single input/single output case and the more general case where EF DB
   traffic is converging on a single output port from multiple input
   ports.  When evaluating the ability of an EF DB device to offer EF DB
   behavior to traffic arriving on one port, EF DB traffic arriving on
   other ports is factored in as competing traffic.

   When considering EF DB traffic from a single input that is leaving via
   multiple ports, it is clear that the behavior is no worse than if all
   of the traffic could be leaving through each one of those ports
   individually (subject to limits on how much is permitted).

3.7 Fragmentation and Rate

   Where an ingress link has an MTU higher than that of an egress link,
   it is conceivable packets may be fragmented as they pass through a
   Diffserv hop. However, the unpredictability of fragmentation is
   significantly counter to the goal of providing controllable QoS.
   Therefore we assume that fragmentation of EF DB packets is being avoided
   (either through some form of Path MTU discovery, or configuration),
   and does not need to be specifically considered in the EF DB behavior
   definition.

3.8 Interference with other traffic
   If the EF DB PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF DB traffic
   could inflict on other traffic. This will be reflected in the EF DB
   device's burst tolerance described in section 2.1.

3.9 Micro flow awareness

   Some EF DB implementations may choose to provide queuing and scheduling
   at a finer granularity (for example, per micro flow) than is
   indicated solely by the packet's DSCP. Such behavior is NOT precluded
   by the EF DB PHB definition. However, such behavior is also NOT part of
   the EF DB PHB definition. Vendors Implementors are free to characterize and
   publicize the additional per micro flow capabilities of their EF DB
   implementations as they see fit.

3.10 Arrival rate 'R'

   In the absence of additional information, R is assumed to be limited
   by the slowest interface on the device.

   In addition, an EF DB device may be characterized by different values of
   R for different traffic flow scenarios (for example, for traffic
   aimed at different ports, total incoming R, and possibly total per
   output port incoming R across all incoming interfaces).

4. IANA Considerations

   This document allocates suggests one experimental codepoint, 101110, in Pool 1 of 101111.  Because
   the DSCP is taken from the experimental code
    space defined space, it may be re-used
   by [4]. other experimental or informational DiffServ proposals.

5. Conclusion.

   This document defines EF DB behavior in terms of a bound on delay
   variation for traffic streams that are rate shaped on ingress to a DS
   domain. Two parameters - capped arrival rate (R) and a 'score' (S)
   are defined and related to the target delay variation bound.  All
   claims of EF DB 'conformance' for specific implementations of EF DB
   behavior are made with respect to particular values for R, S, and the
   implementation's ability to tolerate small amounts of burstiness in
   the arriving EF DB traffic stream.

Security Considerations

   To protect itself against denial of service attacks, the edge of a DS
   domain MUST strictly police all EF DB marked packets to a rate
   negotiated with the adjacent upstream domain (for example, some value
   less than or equal to the capped arrival rate R).  Packets in excess
   of the negotiated rate MUST be dropped.  If two adjacent domains have
   not negotiated an EF DB rate, the downstream domain MUST use 0 as the
   rate (i.e., drop all EF DB marked packets).

   Since PDBs constructed from the EF DB PHB will require that the upstream
   domain police and shape EF DB marked traffic to meet the rate negotiated
   with the downstream domain, the downstream domain's policer should
   never have to drop packets.  Thus these drops (or a summary of these
   drops) SHOULD be noted (e.g., via rate-limited SNMP traps) as
   possible security violations or serious misconfiguration.

   Overflow events on an EF DB queue MAY also be logged as indicating
   possible denial of service attacks or serious network
   misconfiguration.

Acknowledgments

   This draft document is the product of the EF Resolve volunteer 'EF Resolve' design
   team, and builds
    almost entirely building on the works work of V. Jacobson, K. Nichols, K. Poduri [1]
   and A. Charny, F. Baker, J. Bennett, K. Benson, J.-Y. Le Boudec,
    A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek,
    K.K. Ramakrishnan, and D. Stiliadis [2]. clarified through discussions with members of the DiffServ
   working group (particularly the authors of [2]).  Non-contentious
   text (such as the use of EF DB with tunnels, the security
   considerations, etc) were drawn directly from equivalent text in RFC
   2598.

Authors (volunteer EF Design Team Members members)

   Grenville Armitage
      Rm A234, 3180 Porter Drive
      Palo Alto, CA 94061
     email: gja@lucent.com gja@ureach.com

   Brian E. Carpenter (team observer, WG co-chair)
     IBM
     iCAIR, Suite 150
     1890 Maple Avenue
     Evanston IL 60201, USA
     email: brian@icair.org

   Alessio Casati
     Lucent Technologies
     Swindon, WI  SN5 7DJ  United Kingdom
     email: acasati@lucent.com

   Jon Crowcroft
     Department of Computer Science
     University College London
     Gower Street,
     London WC1E 6BT, UK
     email: J.Crowcroft@cs.ucl.ac.uk

   Joel M. Halpern
     Longitude Systems, Inc.
     15000 Conference Center Drive
     Chantilly, VA 20151
     email: joel@longsys.com

   Brijesh Kumar
      Ennovate
     Corona Networks Inc.,
     630 Alder DRive,
     Milpitas, CA 95035
     email: bkumar@ennovatenetworks.com brijesh@coronanetworks.com

   John Schnizlein
     Cisco Systems
     9123 Loughran Road
     Fort Washington, MD 20744
     email: john.schnizlein@cisco.com

Intellectual Properties Considerations

    <TBD>

   To establish whether any considerations apply to the idea expressed
   in this document, readers are encouraged to review notices filed with
   the IETF and stored at:

    http://www.ietf.org/ipr.html

References

   [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
   [2] A Charny, ed. "EF PHB Redefined", INTERNET DRAFT <draft-charny-
   [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
   [4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
   Differentiated Services Field (DS Field) in the IPv4 and IPv6
   Headers", RFC 2474, December 1998.

   [5] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
   Architecture for Differentiated Services", RFC 2475, December 1998.