Internet Engineering Task Force B. Carpenter Differentiated Services Working Group IBM Internet Draft K. Nichols Expires in July, 2001 Packet Design draft-ietf-diffserv-pdb-bh-02 January, 2001 A Bulk Handling Per-Domain Behavior for Differentiated Services 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." This document is a product of the Diffserv working group. Comments on this draft should be directed to the Diffserv mailing list . The list of current Internet-Drafts can be accessed at www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes a differentiated services per-domain behavior whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model. The name, "bulk handling" is loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. 1 Description of the Bulk Handling PDB This document proposes a differentiated services per-domain behavior [PDBDEF] called bulk handling (BH) which makes it possible to admit traffic of sufficiently low value (where "value" may be interpreted in any useful way by the network operator) that any other traffic should take precedence over this traffic in consumption of network link bandwidth. There may or may not be memory (buffer) resources allocated for this type of traffic. Some networks carry traffic for which delivery is considered optional; that is, packets of this type of traffic ought to consume network resources only when no other traffic is present. Alternatively, the effect of this type of traffic on all other network traffic is strictly limited. This is distinct from "best-effort" traffic since the network makes no committment to delivering these packets while, in the best-effort case, an implied "good faith" committment that there are at least some network resources available is assumed. This document proposes a Bulk Handling Differentiated Dervices per-domain behavior [PDBDEF] for handling this "optional" traffic in a differentiated services domain. The name, "bulk handling" is loosely based on the United States Postal Service's Bulk Handling deliver for mail: a lower-cost delivery where the items are not handled with the same care or delivered with the same timeliness as items with first-class postage. There is no intrinsic reason to limit the applicability of the BH PDB to any particular application or type of traffic. It is intended as an additional tool for administrators in engineering networks. Note: where not otherwise defined, terminology used in this document is defined in [RFC2474]. 2 Applicability A Bulk Handling (BH) PDB is for sending extremely non-critical traffic across a DS domain or DS region. There should be an expectation that packets of the BH PDB may be delayed or dropped when any other traffic is present. Its use might assist a network operator in moving certain kinds of traffic or users to off-peak times. Alternatively, or in addition, packets can be designated for the BH PDB where the goal is to protect all other packet traffic from competition with the BH aggregate while not completely banning BH traffic from the network. A BH PDB should not be used for a customer's "normal internet" traffic nor for packets that ought to simply be dropped as unauthorized. The BH PDB is expected to have applicability in networks that have at least some unused capacity at some times of day. This is a PDB that allows for protecting networks from some types of traffic rather than giving a traffic aggregate preferential treatment. 3 Technical Specification Classification and Traffic Conditioning There are no required traffic profiles governing rate and bursts of packets beyond the limits imposed by the ingress link. It is not necessary to limit the BH aggregate using edge techniques since its PHB is to be configured such that packets of the aggregate will be dropped in the network if no forwarding resources are available. The Differentiated Services Architecture [RFC2475] allows packets to be marked upstream of the DS domain or at the DS domain's edge. When packets arrive pre-marked with the DSCP used by the BH PDB, it should not be necessary for the DS domain boundary to police that marking; further (MF) classification for such packets would only be required if there was some reason to suspect the packets should be marked with some other DSCP. If there is not an agreement on DSCP marking with the upstream domain, when a DS domain is using the BH PDB, the boundary must include a classifier that selects the appropriate BH target group of packets out of all arriving packets and steers them to a marker which sets the appropriate DSCP. No other traffic conditioning is required. PHB configuration Either a Class Selector (CS) PHB [RFC2474], an Experimental/ Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] may be used as the PHB for the BH traffic aggregate. This document does not specify the exact DSCP to use inside a domain, but instead specifies the necessary properties of the PHB selected by the DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. The PHB used by the BH aggregate inside a DS domain should be configured so that its packets are forwarded onto the node output link when the link would otherwise be idle; conceptually, the behavior of a weighted round-robin scheduler with a weight of zero. An operator might choose to configure a very small link share for the BH aggregate and still achieve the desired goals. That is, if the output link scheduler permits, a small fixed rate might be assigned to the PHB, but the behavior beyond that configured rate should be that packets are forwarded only when the link would otherwise be idle. This behavior could be obtained, for example, by using a CBQ [CBQ] scheduler with a small share and with borrowing permited. A PHB that allows packets of the BH aggregate to send more than the configured rate when packets of other traffic aggregates are waiting for the link is not recommended. If a CS PHB is used, note that this configuration will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have a less timely forwarding than CS0. An operator's goal of providing a BH PDB provides a sufficient cause for violating the SHOULD. If an AF PHB is used, it must be configured and a DSCP assigned such that it does not violate the "MUST" of paragraph three of section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount of forwarding resources". 4 Attributes There are no quantifiable attributes of the PDB. The ingress and egress flow of the BH aggregate can be measured but there are no absolute or statistical metrics that arise from the PDB definition, though a particular network operator may configure the DS domain in such a way that a statistical metric can be associated with that DS domain. When the DS domain is known to be heavily congested with traffic of other PDBs, a network operator should expect to see no (or very few) packets of the BH PDB egress from the domain. When there is no other traffic present, the proportion of the BH aggregate that successfully crosses the domain should be limited only by the capacity of the network relative to the ingress BH traffic aggregate. 5 Parameters None required. 6 Assumptions A properly functioning network. 7 Example uses 1. Multimedia applications [this example edited from Yoram Bernet]: Many network managers want to protect their networks from certain applications, in particular, from multimedia applications that typically use such non-adaptive protocols as UDP. Most of the focus in quality-of-service is on achieving attributes that are better than Best Effort. These approaches can provide network managers with the ability to control the amount of multimedia traffic that is given this improved performance with excess relegated to Best Effort. This excess traffic can wreak havoc with network resources even when it is relegated to Best Effort because it is non-adaptive and because it can be significant in volume and duration. These characteristics permit it to sieze network resources, thereby compromising the performance of other, more important applications that are included in the Best Effort traffic aggregate but that use adaptive protocols (e.g., TCP). As a result, network managers often simply refuse to allow multimedia applications to be deployed in resource constrained parts of their network. The BH PDB enables a network manager to allow the deployment of multimedia applications without losing control of network resources. A limited amount of multimedia traffic may (or may not) be assigned to PDBs with attributes that are better than Best Effort. Excess multimedia traffic can be prevented from wreaking havoc with network resources by forcing it to the BH PDB. 2. For Netnews and other "bulk mail" of the Internet. 3. For "downgraded" traffic from some other PDB. 4. For content distribution, Napster traffic, and the like. 8 Experiences The authors solicit experiences for this section. 9 Security Considerations for BH PDB There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475]. 10 Acknowledgments The notion of having something "lower than Best Effort" was raised in the Diffserv Working Group, most notably by Roland Bless and Klaus Wehrle in their Internet Draft [LBE] and by Yoram Bernet for enterprise multimedia applications. Previous discussion centered on the creation of a new PHB which the authors believe is not required. This document was specifically written to explain how to get less than Best Effort without a new PHB. Yoram Bernet contributed significant text for the "Examples" section of this document and other useful comments that helped in editing. Other Diffserv WG members suggested that the BH PDB is needed for Napster traffic, particularly at universities. References [PDBDEF] "Definition of Differentiated Services Per-Domain Behaviors and Rules for their Specification", K. Nichols, B. Carpenter, draft-ietf-diffserv-pdb-def-03.txt [RFC2474] RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt [RFC2475] RFC 2475, "An Architecture for Differentiated Services", S. Blake, D. Black, M.Carlson, E.Davies, Z.Wang,W.Weiss, www.ietf.org/rfc/rfc2475.txt [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt [CBQ] S. Floyd and V. Jacobson, Link-sharing and Resource Management Models for Packet Networks, IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995 [LBE] "A Lower Than Best-Effort Per-Hop Behavior", draft-bless-diffserv-phb-lbe-00.txt, R. Bless and K. Wehrle, 1999, (work in progress). Authors' Addresses Brian Carpenter Kathleen Nichols IBM Packet Design c/o iCAIR 66 Willow Place Suite 150 Menlo Park, CA 94025 1890 Maple Avenue USA Evanston, IL 60201 USA email: brian@icair.org email: nichols@packetdesign.com