INTERNET-DRAFT R. Bless Expires: August 2001 K. Wehrle Universitaet Karlsruhe (TH) Document: draft-bless-diffserv-le-phb-00.txt February 2001 A Limited Effort Per-Hop Behavior 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 list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies properties and characteristics of a Limited Effort (LE) per-hop behavior (PHB) for use within and between Differentiated Services domains [1]. The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce. In the latter case, best-effort traffic preempts LE traffic up to a certain configurable level. Depending on that configurable level, LE traffic may still get a minimal share of bandwidth so that it will not be fully preempted by best-effort traffic. There are numerous uses for this PHB, e.g., for transmission of low precedence background traffic such as bulk data transfers with low priority in time or transmission of traffic from non-responsive sources. Bless & Wehrle Expires: August 2001 [Page 1] Internet-Draft Limited Effort PHB February 2001 Table of Contents 1 Purpose and Overview...........................................2 2 Description of LE per-hop behavior.............................5 2.1 Interaction with Other PHB Groups...........................5 2.2 Traffic Conditioning Actions................................8 2.3 Queueing and Discard Behavior...............................9 2.4 Recommended Codepoint for this PHB..........................9 2.5 Configuration and Management Issues.........................9 3 Security Considerations.......................................10 4 Tunneling.....................................................10 5 Implications on Services......................................10 6 Mapping to link-layer QoS mechanisms..........................10 7 Acknowledgments...............................................11 8 References....................................................11 9 Authors' addresses............................................12 1 Purpose and Overview While Differentiated Services (DS) [1,5] will enable deployment of qualitatively better services in the Internet, the current main portion of traffic is up to now forwarded according to the best- effort delivery principle. This "best-effort" (BE) service is still adequate and sufficient for many applications. Even if some applications will profit from future qualitatively better services, some users may not want to pay the higher cost for those better services and may prefer to use the common best-effort service instead. However, there are many cases in which packets can be forwarded with even lower precedence compared to best-effort packets. If forwarding resources for packets of lower precedence are limited by a configurable bound, best-effort service users will benefit from this differentiation, because the impact of low precedence packets on best-effort resources is limited. Therefore, the respective per-hop forwarding behavior (PHB) defined in this document is called Limited Effort (LE). Because this document defines properties of a forwarding behavior within a node and requires only PHB mechanisms it actually defines a PHB. However, this simple PHB can be deployed fast and will Bless & Wehrle Expires: August 2001 [Page 2] Internet-Draft Limited Effort PHB February 2001 be useful as long as a significant portion of traffic remains in the BE class. There are numerous possible uses for this PHB. One application example is the transmission of low precedence background traffic such as bulk data transfers with low priority in time. For instance, transmission of backup data traffic during working hours or traffic caused by web search engines while gathering information from web servers. From this point of view it constitutes a network equivalent to a background priority for processes in an operating system. A low priority in time does not always imply that LE traffic is of minor importance (backup data is surely important). For instance, when using TCP for reliable data transfer it just means that this transfer may last longer due to the more limited resources. Because applications know the precedence of their packets, they may execute an initial marking in DS aware end systems. Another application example is protection of BE traffic from non- responsive sources, i.e., such that do not respond to network congestion situations. Especially, marking traffic of non-responsive applications that demands a lot of resources for receiving this LE PHB may effectively control its overall amount. Network providers may prefer to assign even applications that would usually profit from better qualitatively better services, such as multimedia streaming, to receive this LE PHB. The reason for this policy may be the effective protection of ordinary BE traffic due to the configurable LE limit. As an example, Web radio traffic falls in this category. Moreover, an LE PHB is particularly useful in situations when packets of a better service (something "above best-effort") are re- marked by a node for subsequently receiving a forwarding treatment that is nearly equivalent to the best-effort service. In this situation the LE PHB helps to protect other best-effort packets from experiencing unfair forwarding treatment, because it avoids their preemption by re-marked packets. For instance, this case occurs when heterogeneous multicast groups should be supported. Changing a per-hop forwarding behavior of an incoming packet is sometimes desired or even required, so that the packet is subsequently forwarded with the lowest available priority. Usually, this forwarding behavior would be equivalent to the Default PHB resulting in a best-effort service. But, simply re-marking the DS codepoint (DSCP) to the DSCP value of the Default PHB will probably result in some unfair share of this re-marked traffic relating to best-effort traffic. This is due to the fact that nearly all packets that previously experienced a better service enter the behavior aggregate (BA) of the Default behavior. Consequently, those re-marked packets will preempt other incoming packets carrying a DSCP of the Default PHB if not enough resources are available for the combined traffic. This unfairness against existing best-effort traffic should be avoided. Bless & Wehrle Expires: August 2001 [Page 3] Internet-Draft Limited Effort PHB February 2001 The basic concept behind the proposed Limited Effort per-hop behavior is to discard those re-marked packets in a node more aggressively than packets belonging to the default PHB if resources become scarce. Merely discarding those packets more drastically in the re-marking node is not sufficient, because currently there may be enough resources available in this node, but maybe not in subsequent downstream nodes. Therefore, this re-marked traffic of lower precedence should be identifiable downstream by a separate codepoint. For instance, a re-marking of packets is required when a receiver joins a multicast group and does not want to or even is not able to receive the currently used better service within this group (e.g., 1 Mbit/s "Premium service"). Instead of this, the receiver wants to get the traffic of this group without any quality of service guarantee, i.e., basically a best-effort service. The node which connects the new subtree of this receiver to the already existing multicast delivery tree must therefore degrade the quality of service of the incoming packet stream for replicated packets which are sent downstream on the output link of the newly joined subtree (see Figure 1). Moreover, specific excess traffic of any kind may be marked with the LE codepoint. For example, this excess traffic could consist of packets belonging to non-responsive flows (e.g., UDP flows). Thus, other best-effort traffic (e.g., responsive TCP flows) is segregated from this excess traffic, consequently not being adversely affected by it. || Multicast Group Flow || 1 Mbit/s Premium service \/ +---------+ | || | | || | | //\*) | *) Replicates are re-marked +-//--\---+ with the LE PHB // \ 1 Mbit/s || | Premium || | Limited Effort (LE) Service \/ V . \ . \ // \\ . // \\ . . . +---+ . . | R | New receiver wants no QoS +---+ Figure 1: A new receiver without QoS requirements joining a multicast group that uses Premium service Bless & Wehrle Expires: August 2001 [Page 4] Internet-Draft Limited Effort PHB February 2001 The LE PHB solves the above-mentioned problems by discarding LE packets more rigorously than those of the best-effort BA in case of resource contention for residual bandwidth. Therefore limiting the amount of packets in the LE class in relation to the amount of packets in the best-effort class. This is described more detailed in sections 2.1 and 2.3. The 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 [2]. 2 Description of LE per-hop behavior In general, a Limited Effort per-hop forwarding behavior can be used to protect traffic in the best-effort service class from unfairness that otherwise would have been caused by those packets, which are now in the LE. The latter packets may stem from excess traffic, non- responsive traffic or re-marked traffic that has been experiencing a better service before. Therefore, in order to restrict the impact of those packets on packets in the Default PHB BA, the LE PHB provides forwarding of IP packets with higher drop precedence than Default PHB packets. At first, it will not be necessary to have an LE PHB group comprising more than one PHB, because within its BA, LE PHB essentially resembles best-effort behavior that does not distinguish different types of traffic (e.g., responsive and non-responsive flows), too. However, as more experience is gained with this PHB it may become necessary to provide two PHBs, one for responsive flows (e.g., TCP flows and others that react to congestion in a TCP-like manner) and one for non-responsive flows (e.g., UDP flows without congestion control). The Limited Effort per-hop behavior is intended for general use. There may be many cases in which the LE PHB can be applied. Three of them were already mentioned in section 1. Using this PHB between two adjacent service providers is also useful, because the upstream domain possibly had enough resources left to carry the additional LE traffic volume, whereas the downstream domain has not enough resources, therefore being in need of discarding some portion of this traffic. 2.1 Interaction with Other PHB Groups The LE PHB is essentially defined by its relation to the default PHB: an LE packet is of minor relative importance compared to a best- effort packet. Thus, in case of contention for bandwidth (i.e., a congestion situation), packets receiving best-effort treatment Bless & Wehrle Expires: August 2001 [Page 5] Internet-Draft Limited Effort PHB February 2001 preempt packets of the LE behavior aggregate down to a certain share. This share must be considerably lower than that of the best-effort BA, but should not be equal to zero in order to retain a low portion of LE traffic even when best-effort traffic takes up all available residual bandwidth. Therefore, a minimum configured bandwidth share for LE traffic exists as a lower bound that guarantees transport of LE packets even in case of congestion. On the other hand, this bound also constitutes an upper limit for the share of LE traffic during congestion. This upper bound may be static, that is, fixed in relation to the overall available bandwidth on a particular link (a constant value for 100-Y in Figure 2), or it may be dynamic, i.e., fixed relative to the BE traffic share, thus variable in relation to the overall available bandwidth, because BE traffic may consume resources currently not used by other BAs (a dynamic value for Y that depends on the amount of BE traffic; corresponding to a constant ratio of (100-Y)/(100-X) in Figure 2). 0% X% Y% 100% +----------------------------------------------------------------+ | Other BAs | Best-Effort | LE | +----------------------------------------------------------------+ |<-Upper->| | Bound | Figure 2: Bandwidth share limits for LE traffic. Other behavior aggregates (BA) currently use X% of total available bandwidth, while best-effort and LE traffic share the residual bandwidth. If enough resources are available for other BAs and BE traffic, i.e., residual bandwidth exists that is not used by best-effort traffic, LE packets may use more than the previously defined bound on their share of total bandwidth, because this limit is only needed in case of congestion (see Figure 3 and Figure 4). Therefore, any remaining resources can be used to forward excess LE traffic, because all BE demand is already met. In this case, there is no reason to discard any of the LE packets until they exhaust the residual bandwidth, because their presence does not adversely affect any of the best- effort packets. Bless & Wehrle Expires: August 2001 [Page 6] Internet-Draft Limited Effort PHB February 2001 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% offered traffic ========================================| 40% upper bound OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 40% admitted traffic BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% offered traffic BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 45% admitted traffic LLLLLLLLLLLLLLLLLLLLLLLLLLLL 28% offered traffic ==========| 10% upper bound LLLLLLLLLLLLLLL 15% admitted traffic ---------------------------------------------------> output link bandwidth O: Other BAs, B: Best-Effort BA, L: LE BA Figure 3: Other BAs fully exploit their allotted resources, LE BA gets residual bandwidth that best-effort doesn't use. OOOOOOOOOOOOOOOOOOO 15% offered traffic ========================================| 40% upper bound OOOOOOOOOOOOOOOOOOO 15% admitted traffic BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% offered BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 55% admitted LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic ==========| 10% upper bound LLLLLLLLLLLLLLLLLLLLLLLLLLLLL 30% admitted traffic ---------------------------------------------------> output link bandwidth O: Other BAs, B: Best-Effort BA, L: LE BA Figure 4: Other BAs do not fully use their allotted resources, best-effort utilizes unused bandwidth of the other BAs, LE gets residual bandwidth The primary objective of the LE PHB is to segregate packets of the best-effort behavior aggregate from packets that should receive a less than best-effort treatment in case of congestion. This is achieved by using higher drop precedence for LE packets than for best-effort packets, thereby limiting the overall amount of LE traffic in relation to the best-effort behavior aggregate (see Figure 5). Therefore, a congested node tries to protect best-effort packets from being lost by preferably discarding LE packets. Bless & Wehrle Expires: August 2001 [Page 7] Internet-Draft Limited Effort PHB February 2001 OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% offered traffic ========================================| 40% upper bound OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% admitted traffic BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 60% offered BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 54% admitted LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic ==========| 10% upper bound LLLLLLLLLLL 10% admitted traffic ---------------------------------------------------> output link bandwidth O: Other BAs, B: Best-Effort BA, L: LE BA Figure 5: Other BAs do not fully use their allotted resources, best-effort utilizes unused bandwidth of the other BAs, LE is limited to its specified upper bound. With exception of the Default PHB, the LE PHB is entirely independent of all other existing PHB specifications. Thus, any other PHB groups may co-exist with the LE PHB in the same DS domain, because the LE PHB does not preempt forwarding resources of other PHB groups. If only a part of all packets belonging to a microflow are marked as LE, the probability for reordering this microflow's packets may be increased in dependence on the relation of the prior PHB to the LE PHB and may depend on the actual implementation. However, because a special relation to the Default PHB defines the LE PHB, it is recommended that packets of a microflow are not reordered if they are marked by codepoints associated with these two PHBs. A realization of the LE PHB may use an already existing PHB of higher drop precedence (e.g., AFx2 or AFx3 from an AF PHB group [3]), if its actual implementation fulfills the requirements of this specification (e.g., AFx1 is used for BE traffic). 2.2 Traffic Conditioning Actions As for most other PHBs an initial classification and marking would usually be performed at the first DS boundary node. In many cases, packets may also be pre-marked in DS aware end systems by applications due to their specific knowledge about the particular precedence of packets. Usually, the amount of LE traffic is implicitly limited by queueing mechanisms and related discard actions of the PHB. Therefore, there is normally no need to meter and police LE traffic explicitly. Bless & Wehrle Expires: August 2001 [Page 8] Internet-Draft Limited Effort PHB February 2001 However, a DS domain MAY control the amount of LE traffic that enters or exits the domain, therefore (although not necessary) further traffic conditioning actions MAY be applied. 2.3 Queueing and Discard Behavior All packets of an arbitrary microflow that are marked for the LE PHB MUST NOT be reordered. The dropping algorithm MUST treat all packets within the LE BA identically, i.e., the discard rate of a particular microflow's packets will be proportional to that flow's percentage of the total amount of traffic with this LE BA. It is recommended that LE packets use the same queue as best-effort packets in order to avoid reordering of a microflow's packets that are marked intermittently for receiving best-effort or LE forwarding treatment. One way to achieve the above objectives is to use a common queue for best-effort and LE packets that is actively managed by a Random Early Detection (RED) scheme [4]. A separate RED parameter set is managed for each traffic type. If the "current" queue length (usually a weighted average value) grows beyond a lower threshold, new arriving LE packets for this queue are going to be dropped randomly with increasing probability, until the queue length reaches an upper threshold. Beyond this upper threshold every new incoming LE packet for this queue is going to be discarded. If the threshold values for LE packets are lower than those for best-effort packets, the RED queue will start discarding LE packets earlier than BE packets. However, there are many other possibilities of implementing the LE PHB, and the given example is not to be understood as a prescription for implementation. Other existing PHBs (e.g., an AF PHB) may also be used for implementation, but must be configured in such a way that the properties of the LE PHB defined in this document are satisfied. 2.4 Recommended Codepoint for this PHB As long as this a PHB proposal, the temporary recommended code point is taken from the experimental/local use (EXP/LU) portion of the codepoint space. The recommended temporary codepoint is '000011' (see section 3 of [5] for the meaning of this notation). 2.5 Configuration and Management Issues There is no need for providing any resource-based admission control mechanisms for this PHB. As described in section 2.1, a configurable minimal bandwidth share, respectively upper bound exists for bandwidth used by the LE BA if no residual bandwidth is left and all other bandwidth is used for best-effort. Bless & Wehrle Expires: August 2001 [Page 9] Internet-Draft Limited Effort PHB February 2001 3 Security Considerations Basically, the LE PHB causes no other security implications besides the ones already mentioned in [5]. Because LE PHB provides a quality that is even less compared to the usual best-effort delivery, there is now one more possible PHB to reduce a packet's service. On the other hand, there is currently no PHB providing a worse service, so LE packets cannot be further reduced in service by re- marking. Consequently, re-marking the inner header's codepoint of LE packets at the egress of a tunnel with a codepoint of another PHB would have only a positive effect on these packets. However, this would possibly eliminate the primary objective of the LE and lead to depletion of forwarding resources for other traffic streams in congestion situations. 4 Tunneling When LE packets are tunneled, the tunneling packets SHOULD also be marked as LE. 5 Implications on Services As described in section 2.1, traffic using the current best-effort service should be segregated and protected from LE traffic in congestion situations. Therefore, performance of the common best- effort service is increased under those conditions. 6 Mapping to link-layer QoS mechanisms In a shared medium LE traffic has a very good counterpart in the link-layer QoS mechanisms as defined by IEEE 802.1p: the background traffic type. Therefore, packets carrying a DSCP value of the LE PHB can be mapped to 802.1p background traffic priority, i.e., setting the "user_priority" field to value 1 in all link-layer frames that carry a part of an LE packet as payload. In order to achieve a real support for LE packets, link-layer frames containing best-effort packets should use the default user_priority of 0 for indicating traffic type "Best Effort". LE packets within a switched link-layer could also use available means to indicate higher drop precedence for LE packets. For instance, when using ATM as link-layer, the value encoded in the Cell Loss Priority (CLP) field of the ATM cell header [6] may be set to 1 in all ATM cells carrying a part of an LE packet as payload, whereas cells carrying a part of a best-effort packet as payload should use a CLP value of 0. Bless & Wehrle Expires: August 2001 [Page 10] Internet-Draft Limited Effort PHB February 2001 As another example, when using Frame Relay as link-layer, the Discard Eligibility Indicator (DE) bit can be set to 1 for frames containing an LE packet as payload, indicating that this frame should be discarded in preference to other frames in a congestion situation [7]. All frames carrying a part of a best-effort packet as payload should use a DE bit value of 0. 7 Acknowledgments Thanks to Jochen Schiller for discussion of the LE PHB. 8 References [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Services. RFC 2475, Dec. 1998. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, Mar. 1997 [3] F. Baker, J. Heinanen, W. Weiss, and J. Wroclawski. Assured Forwarding PHB Group. RFC2597, Jun. 1999 [4] S. Floyd and V. Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Vol. 1(4):397--413, Aug. 1993 [5] F. Baker, D. Black, S. Blake, and K. Nichols. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, Dec. 1998. [6] ITU-T. B-ISDN ATM Layer Specification. ITU-T Recommendation I.361, 11/1995 [7] ITU-T. ISDN Data Link Layer Specification for Frame Mode Bearer Services. ITU-T Recommendation Q.922, 1992 Bless & Wehrle Expires: August 2001 [Page 11] Internet-Draft Limited Effort PHB February 2001 9 Authors' addresses Comments and questions related to this draft can be addressed to one of the authors listed below. Roland Bless Institute of Telematics Universitaet Karlsruhe (TH) Zirkel 2 D-76128 Karlsruhe Germany Tel.: +49 721 608 6396 bless@telematik.informatik.uni-karlsruhe.de Klaus Wehrle Institute of Telematics Universitaet Karlsruhe (TH) Zirkel 2 D-76128 Karlsruhe Germany Tel.: +49 721 608 6414 wehrle@telematik.informatik.uni-karlsruhe.de Bless & Wehrle Expires: August 2001 [Page 12]