INTERNET-DRAFT R. Bless Expires: March 2000 K. Wehrle Universitaet Karlsruhe (TH) September 1999 A Lower Than Best-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 describes a Lower than Best-Effort (LBE) per-hop behavior (PHB) for use within and between Differentiated Services domains [3]. The primary objective of this LBE PHB is to separate LBE traffic from best-effort traffic in congestion situations, i.e., when resources become scarce. Furthermore, LBE traffic gets a minimal share of bandwidth so that it will not be fully preempted by best-effort traffic. This is achieved by discarding LBE packets more aggressively than best-effort packets while trying to enqueue them in case of congestion. There are numerous uses for this PHB, e.g., for transmission of background traffic such as bulk data transfers of minor importance, backup data traffic during working hours or traffic caused by web search engines while gathering information from web servers. Thus, it constitutes the network equivalent to a background priority for processes in an operating system. Moreover, it is particularly useful in cases when packets of a better service are re-marked by a node Bless & Wehrle Expires: March 2000 [Page 1] Internet-Draft Lower Than Best-Effort PHB September 1999 for subsequently receiving a forwarding treatment that is equivalent to the best-effort service. In this situation the LBE 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. 1 Purpose and Overview In some situations changing a per-hop forwarding behavior (PHB) of an incoming packet is desired or 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 which previously experienced a better service enter the behavior aggregate (BA) of the Default behavior. Consequently, other incoming packets carrying a DSCP of the Default PHB will be preempted by those re-marked packets if not enough resources are available for the combined traffic. This unfairness against existing best-effort traffic should be avoided. The basic concept behind the proposed Lower-Than-Best-Effort per-hop behavior (LBE PHB) is to discard those re-marked packets 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 should be identifyable 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., 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 Fig. 1). Moreover, specific excess traffic of any kind may be marked with the LBE 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. Bless & Wehrle Expires: March 2000 [Page 2] Internet-Draft Lower Than Best-Effort PHB September 1999 || Multicast Group Flow || 1 Mbit/s Premium service \/ +---------+ | || | | || | | // \*) | *) replicates are re-marked +-//---\--+ with the LBE PHB // \ 1 Mbit/s || | Premium || | Lower than Best-Effort (LBE) service service \/ V . \ . \ // \\ . // \\ . . . +---+ . . | R | New receiver wants no QoS +---+ Figure 1: A new receiver without QoS requirements joining a multicast group that uses Premium service As a further example, the LBE can be used as a separate service class for background traffic (e.g., bulk transfers of low priority) that should not impact the usual best-effort traffic. Examples for this kind of background traffic are backup data traffic sent over the network during normal working hours and traffic from web search engines gathering data from web servers. Additionally, applications in DS aware end-systems are able to pre-mark packets of minor importance, while allowing to use the traditional inexpensive best-effort service for all other more important packets. The LBE PHB solves the above mentioned problems by discarding LBE 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 LBE class in relation to 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 [4]. 2 Description of LBE per-hop behavior A lower than best-effort service can be used in general to protect traffic in the best-effort service class from unfairness that would otherwise have been caused by those packets which are now in the LBE. The latter packets may stem from excess traffic or re-marked traffic that has been experiencing a better service before. Therefore, in order Bless & Wehrle Expires: March 2000 [Page 3] Internet-Draft Lower Than Best-Effort PHB September 1999 to restrict the impact of those packets on packets in the Default PHB BA, the LBE PHB provides forwarding of IP packets with a higher drop precedence than Default PHB packets. It is not necessary to have an LBE PHB group comprising more than one PHB, because within its BA, LBE PHB essentially resembles best-effort behavior that does not distinguish different types of traffic (e.g., responsive and non-responsive flows), too. The Lower than Best-Effort per-hop behavior is intended for general use. There may be many cases in which the LBE 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 LBE 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 LBE PHB is essentially defined by its relation to the default PHB: an LBE 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 preempt packets of the LBE 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 LBE traffic even when best-effort traffic takes up all available residual bandwidth. Therefore, a minimum configured bandwidth share for LBE traffic exists as a lower bound that guarantees transport of LBE packets even in case of congestion. On the other hand, this bound also constitutes an upper limit for the share of LBE 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 Fig. 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 Fig. 2). 0% X% Y% 100% +----------------------------------------------------------------+ | Other BAs | Best-Effort | LBE | +----------------------------------------------------------------+ |<-Upper->| | Bound | Figure 2: Bandwidth share limits for LBE traffic. Other behavior aggregates (BA) currently use X% of total available bandwidth, while best-effort and LBE traffic share the residual bandwidth. Bless & Wehrle Expires: March 2000 [Page 4] Internet-Draft Lower Than Best-Effort PHB September 1999 If enough resources are available for other BAs and BE traffic, i.e., residual bandwidth exists that is not used by best-effort traffic, LBE 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 Fig. 3 and 4). Therefore, any remaining resources can be used to forward excess LBE traffic, because all BE demand is already met. In this case, there is no reason to discard any of the LBE packets until the residual bandwidth is exhausted by them, because their presence does not adversely affect any of the best-effort packets. 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: LBE BA Figure 3: Other BAs fully exploit their allotted resources, LBE 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: LBE BA Figure 4: Other BAs do not fully use their allotted resources, best-effort utilizes unused bandwidth of the other BAs, LBE gets residual bandwidth The primary objective of the LBE PHB is to segregate packets of the best-effort behavior aggregate from packets which should receive a lower than best-effort treatment in case of congestion. This is achieved by Bless & Wehrle Expires: March 2000 [Page 5] Internet-Draft Lower Than Best-Effort PHB September 1999 using a higher drop precedence for LBE packets than for best-effort packets, and by limiting the overall amount of LBE traffic in relation to the best-effort behavior aggregate (see Fig. 5). Therefore, a congested node tries to protect best-effort packets from being lost by preferably discarding LBE packets. OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% offered traffic ========================================| 40% upper bound OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 36% admitted traffic BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 60% offered BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 54% admitted LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 40% offered traffic ==========| 10% upper bound LLLLLLLLLLL 10% admitted traffic ---------------------------------------------------> output link bandwidth O: Other BAs, B: Best-Effort BA, L: LBE BA Figure 5: Other BAs do not fully use their allotted resources, best-effort utilizes unused bandwidth of the other BAs, LBE is limited to its specified upper bound. With exception of the Default PHB, the LBE PHB is entirely independent of all other existing PHB specifications. Thus, any other PHB groups may co-exist with the LBE PHB in the same DS domain, because the LBE PHB does not preempt forwarding resources of other PHB groups. If only a part of all packets belonging to a microflow are marked as LBE, the probability for reordering this microflow's packets may be increased in dependence on the relation of the prior PHB to the LBE PHB and may depend on the actual implementation. However, because the LBE PHB is defined by a special relation to the Default 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 LBE PHB may use an already existing PHB of higher drop precedence (e.g., AFx2 or AFx3 from the AF PHB group [2]), if its actual implementation fulfills the requirements of this specification. 2.2 Traffic Conditioning Actions Usually, the amount of LBE traffic is implicitly limited by queueing mechanisms and related discard actions. Therefore, there is normally no need to meter and police LBE traffic explicitly. However, a DS domain MAY control the amount of LBE traffic that enters or exits the domain. Traffic conditioning actions MAY include traffic shaping and discarding of packets. Bless & Wehrle Expires: March 2000 [Page 6] Internet-Draft Lower Than Best-Effort PHB September 1999 2.3 Queueing and Discard Behavior All packets of an arbitrary microflow that are marked for the LBE PHB MUST NOT be reordered. The dropping algorithm MUST treat all packets within the LBE 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 LBE BA. It is recommended that LBE packets use the same queue as best-effort packets in order to avoid reordering of a microflow's packets that are marked intermittently for best-effort or LBE forwarding. One way to achieve the above objectives is to use a common queue for best-effort and LBE packets that is actively managed by a Random Early Detection (RED) scheme [5]. 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 LBE 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 LBE packet for this queue is going to be discarded. If the threshold values for LBE packets are lower than those for best-effort packets, the RED queue will start discarding packets earlier. 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 '101011' (see section 3 of [1] 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 LBE BA if no residual bandwidth is left and all other bandwidth is used for best-effort. 3 Security Considerations Basically, the LBE PHB causes no other security implications besides the ones already mentioned in [1]. Because LBE PHB provides a quality that is even lower compared to the usual best-effort delivery, there is now one more possible PHB to reduce a packet's service. Bless & Wehrle Expires: March 2000 [Page 7] Internet-Draft Lower Than Best-Effort PHB September 1999 On the other hand, there is currently no PHB providing a worse service, so LBE packets cannot be further reduced in service by re-marking. Consequently, re-marking the inner header's codepoint of LBE 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 LBE and lead to depletion of forwarding resources for other traffic streams in congestion situations. 4 Tunneling When LBE packets are tunneled, the tunneling packets must also be marked as LBE. 5 Implications on Services As described in section 2.1, traffic using the current best-effort service should be segregated and protected from LBE 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 LBE 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 LBE 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 LBE packet as payload. In order to achieve a real support for LBE packets, link-layer frames containing best-effort packets should use the default user_priority of 0 for indicating traffic type "Best Effort". LBE packets within a switched link-layer could also use available means to indicate a higher drop precedence for LBE 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 LBE packet as payload, whereas cells carrying a part of a best-effort packet as payload should use a CLP value of 0. 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 LBE 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. Bless & Wehrle Expires: March 2000 [Page 8] Internet-Draft Lower Than Best-Effort PHB September 1999 7 Acknowledgments Thanks to Jochen Schiller for discussion of the LBE PHB. References [1] 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. [2] F. Baker, J. Heinanen, W. Weiss, and J. Wroclawski. Assured Forwarding PHB Group. RFC2597, June 1999. [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Services. RFC 2475, Dec. 1998. [4] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, Mar. 1997. [5] S. Floyd and V. Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transaction on Networking, 1(4):397--413, Aug. 1993. [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. 8 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: March 2000 [Page 9]