Network Working Group G. Armitage Request for Comments: 3248 Swinburne University of Technology Category: Informational B. Carpenter IBM A. Casati Lucent Technologies J. Crowcroft University of Cambridge J. Halpern Consultant B. Kumar Corona Networks Inc. J. Schnizlein Cisco Systems March 2002 A Delay Bound alternative revision of RFC 2598 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractFor historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 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 requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB.
Specification of Requirements 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" are interpreted as described in RFC 2119 . RFC 2598 was the Differentiated Services (DiffServ) working group's first standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) . As part of the DiffServ working group's ongoing refinement of the EF PHB, various issues were raised with the text in RFC 2598 . After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF design team' was formed (the authors of this document) to propose a new expression of the EF PHB. The remainder of this Informational document captures our feedback to the DiffServ working group at the San Diego IETF in December 2000. Our solution focussed on a Delay Bound (DB) based re-expression of RFC 2598 which met the goals of RFC 2598's original authors. The DiffServ working group ultimately chose an alternative re-expression of the EF PHB text, developed by the authors of  and revised to 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 'DB' behavior from a single node. Section 3 then discusses a number of issues and assumptions made to support the definition in section 2.
RFC 2475 ) in order to get such a bound. However, specific policing and/or shaping rules are outside the scope of the DB PHB definition. Such rules MUST be defined in any per-domain behaviors (PDBs) composed from the DB PHB. A device (hop) delivers DB behavior to appropriately marked traffic received on one or more interfaces (marking is specified in section 2.4). A device SHALL deliver the DB behavior on an interface to DB marked traffic meeting (i.e. less than or equal) a certain arrival rate limit R. If more DB traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the DB behavior. However, although the original source of 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 a 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 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 DB behavior. However, since the goal of characterizing burstiness is to allow useful comparison of DB implementations, vendors and users of DB implementations MAY choose to utilize other burstiness metrics.) The DB PHB definition does NOT mandate or recommend any particular method for achieving DB behavior. Rather, the DB PHB definition identifies parameters that bound the operating range(s) over which an implementation can deliver DB behavior. Implementors characterize their implementations using these parameters, while network designers and testers use these parameters to assess the utility of different DB implementations.
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 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 DB traffic arriving at the device on other ports, and all non-DB traffic arriving at the device on any port. 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 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. 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 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 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 DB behavior is delivered. These constraints MAY include limits on the total DB traffic across the device, or total DB traffic targeted at a given interface from all inputs. This document does not specify any requirements on 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. 4]. By default we suggest an 'experimental' DSCP of 101111 be used to indicate that DB PHB is required. section 2. section 2 is met.
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. section 2.2 covers both the single input/single output case and the more general case where DB traffic is converging on a single output port from multiple input ports. When evaluating the ability of an DB device to offer DB behavior to traffic arriving on one port, DB traffic arriving on other ports is factored in as competing traffic. When considering 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).
1] and clarified through discussions with members of the DiffServ working group (particularly the authors of ). Non-contentious text (such as the use of DB with tunnels, the security considerations, etc.) were drawn directly from equivalent text in RFC 2598. http://www.ietf.org/ipr.html
 Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.  Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.  Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.