idnits 2.17.1 draft-ietf-diffserv-pdb-bh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 272 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '...icient cause for violating the SHOULD....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-pdb-def (ref. 'PDBDEF') ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. 'CBQ' -- No information found for draft-bless-diffserv-phb-lbe - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LBE' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Carpenter 2 Differentiated Services Working Group IBM 3 Internet Draft K. Nichols 4 Expires in July, 2001 Packet Design 5 draft-ietf-diffserv-pdb-bh-02 January, 2001 7 A Bulk Handling Per-Domain Behavior for Differentiated Services 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 This document is a product of the Diffserv working group. Comments 24 on this draft should be directed to the Diffserv mailing list 25 . The list of current Internet-Drafts can be 26 accessed at www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 www.ietf.org/shadow.html. Distribution of this memo is unlimited. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This document proposes a differentiated services per-domain behavior 37 whose traffic may be "starved" (although starvation is not strictly 38 required) in a properly functioning network. This is in contrast 39 to the Internet's "best-effort" or "normal Internet traffic" model. 40 The name, "bulk handling" is loosely based on the United States' 41 Postal Service term for very low priority mail, sent at a reduced 42 rate. This document gives some example uses, but does not propose 43 constraining the PDB's use to any particular type of traffic. 45 1 Description of the Bulk Handling PDB 47 This document proposes a differentiated services per-domain behavior 48 [PDBDEF] called bulk handling (BH) which makes it possible to admit 49 traffic of sufficiently low value (where "value" may be interpreted 50 in any useful way by the network operator) that any other traffic 51 should take precedence over this traffic in consumption of network 52 link bandwidth. There may or may not be memory (buffer) resources 53 allocated for this type of traffic. 55 Some networks carry traffic for which delivery is considered optional; 56 that is, packets of this type of traffic ought to consume network 57 resources only when no other traffic is present. Alternatively, 58 the effect of this type of traffic on all other network traffic 59 is strictly limited. This is distinct from "best-effort" traffic 60 since the network makes no committment to delivering these packets 61 while, in the best-effort case, an implied "good faith" committment 62 that there are at least some network resources available is assumed. 63 This document proposes a Bulk Handling Differentiated Dervices 64 per-domain behavior [PDBDEF] for handling this "optional" traffic 65 in a differentiated services domain. 67 The name, "bulk handling" is loosely based on the United States 68 Postal Service's Bulk Handling deliver for mail: a lower-cost delivery 69 where the items are not handled with the same care or delivered 70 with the same timeliness as items with first-class postage. There 71 is no intrinsic reason to limit the applicability of the BH PDB 72 to any particular application or type of traffic. It is intended 73 as an additional tool for administrators in engineering networks. 75 Note: where not otherwise defined, terminology used in this document 76 is defined in [RFC2474]. 78 2 Applicability 80 A Bulk Handling (BH) PDB is for sending extremely non-critical traffic 81 across a DS domain or DS region. There should be an expectation 82 that packets of the BH PDB may be delayed or dropped when any other 83 traffic is present. Its use might assist a network operator in 84 moving certain kinds of traffic or users to off-peak times. 85 Alternatively, or in addition, packets can be designated for the BH PDB 86 where the goal is to protect all other packet traffic from competition 87 with the BH aggregate while not completely banning BH traffic from 88 the network. A BH PDB should not be used for a customer's "normal 89 internet" traffic nor for packets that ought to simply be dropped 90 as unauthorized. The BH PDB is expected to have applicability in 91 networks that have at least some unused capacity at some times 92 of day. 94 This is a PDB that allows for protecting networks from some types 95 of traffic rather than giving a traffic aggregate preferential 96 treatment. 98 3 Technical Specification 100 Classification and Traffic Conditioning 102 There are no required traffic profiles governing rate and bursts 103 of packets beyond the limits imposed by the ingress link. It is 104 not necessary to limit the BH aggregate using edge techniques since 105 its PHB is to be configured such that packets of the aggregate 106 will be dropped in the network if no forwarding resources are available. 107 The Differentiated Services Architecture [RFC2475] allows packets 108 to be marked upstream of the DS domain or at the DS domain's edge. 109 When packets arrive pre-marked with the DSCP used by the BH PDB, 110 it should not be necessary for the DS domain boundary to police 111 that marking; further (MF) classification for such packets would 112 only be required if there was some reason to suspect the packets 113 should be marked with some other DSCP. 115 If there is not an agreement on DSCP marking with the upstream domain, 116 when a DS domain is using the BH PDB, the boundary must include 117 a classifier that selects the appropriate BH target group of packets 118 out of all arriving packets and steers them to a marker which sets 119 the appropriate DSCP. No other traffic conditioning is required. 121 PHB configuration 123 Either a Class Selector (CS) PHB [RFC2474], an Experimental/ Local 124 Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] 125 may be used as the PHB for the BH traffic aggregate. This document 126 does not specify the exact DSCP to use inside a domain, but instead 127 specifies the necessary properties of the PHB selected by the DSCP. 128 If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. 130 The PHB used by the BH aggregate inside a DS domain should be configured 131 so that its packets are forwarded onto the node output link when 132 the link would otherwise be idle; conceptually, the behavior of 133 a weighted round-robin scheduler with a weight of zero. An operator 134 might choose to configure a very small link share for the BH aggregate 135 and still achieve the desired goals. That is, if the output link 136 scheduler permits, a small fixed rate might be assigned to the 137 PHB, but the behavior beyond that configured rate should be that 138 packets are forwarded only when the link would otherwise be idle. 139 This behavior could be obtained, for example, by using a CBQ [CBQ] 140 scheduler with a small share and with borrowing permited. A PHB 141 that allows packets of the BH aggregate to send more than the configured 142 rate when packets of other traffic aggregates are waiting for the 143 link is not recommended. 145 If a CS PHB is used, note that this configuration will violate the 146 "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will 147 have a less timely forwarding than CS0. An operator's goal of providing 148 a BH PDB provides a sufficient cause for violating the SHOULD. 149 If an AF PHB is used, it must be configured and a DSCP assigned 150 such that it does not violate the "MUST" of paragraph three of 151 section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount 152 of forwarding resources". 154 4 Attributes 156 There are no quantifiable attributes of the PDB. The ingress and 157 egress flow of the BH aggregate can be measured but there are no 158 absolute or statistical metrics that arise from the PDB definition, 159 though a particular network operator may configure the DS domain 160 in such a way that a statistical metric can be associated with 161 that DS domain. When the DS domain is known to be heavily congested 162 with traffic of other PDBs, a network operator should expect to 163 see no (or very few) packets of the BH PDB egress from the domain. 164 When there is no other traffic present, the proportion of the BH 165 aggregate that successfully crosses the domain should be limited 166 only by the capacity of the network relative to the ingress BH 167 traffic aggregate. 169 5 Parameters 171 None required. 173 6 Assumptions 175 A properly functioning network. 177 7 Example uses 179 1. Multimedia applications [this example edited from Yoram Bernet]: 181 Many network managers want to protect their networks from certain 182 applications, in particular, from multimedia applications that 183 typically use such non-adaptive protocols as UDP. 185 Most of the focus in quality-of-service is on achieving attributes 186 that are better than Best Effort. These approaches can provide 187 network managers with the ability to control the amount of multimedia 188 traffic that is given this improved performance with excess relegated 189 to Best Effort. This excess traffic can wreak havoc with network 190 resources even when it is relegated to Best Effort because it is 191 non-adaptive and because it can be significant in volume and duration. 192 These characteristics permit it to sieze network resources, thereby 193 compromising the performance of other, more important applications 194 that are included in the Best Effort traffic aggregate but that 195 use adaptive protocols (e.g., TCP). As a result, network managers 196 often simply refuse to allow multimedia applications to be deployed 197 in resource constrained parts of their network. 199 The BH PDB enables a network manager to allow the deployment of 200 multimedia applications without losing control of network resources. 201 A limited amount of multimedia traffic may (or may not) be assigned 202 to PDBs with attributes that are better than Best Effort. Excess 203 multimedia traffic can be prevented from wreaking havoc with network 204 resources by forcing it to the BH PDB. 206 2. For Netnews and other "bulk mail" of the Internet. 208 3. For "downgraded" traffic from some other PDB. 210 4. For content distribution, Napster traffic, and the like. 212 8 Experiences 214 The authors solicit experiences for this section. 216 9 Security Considerations for BH PDB 218 There are no specific security exposures for this PDB. See the general 219 security considerations in [RFC2474] and [RFC2475]. 221 10 Acknowledgments 223 The notion of having something "lower than Best Effort" was raised 224 in the Diffserv Working Group, most notably by Roland Bless and 225 Klaus Wehrle in their Internet Draft [LBE] and by Yoram Bernet 226 for enterprise multimedia applications. Previous discussion centered 227 on the creation of a new PHB which the authors believe is not required. 228 This document was specifically written to explain how to get less 229 than Best Effort without a new PHB. 231 Yoram Bernet contributed significant text for the "Examples" section 232 of this document and other useful comments that helped in editing. 233 Other Diffserv WG members suggested that the BH PDB is needed for 234 Napster traffic, particularly at universities. 236 References 238 [PDBDEF] "Definition of Differentiated Services Per-Domain Behaviors 239 and Rules for their Specification", K. Nichols, B. Carpenter, 240 draft-ietf-diffserv-pdb-def-03.txt 242 [RFC2474] RFC 2474, "Definition of the Differentiated Services Field 243 (DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, 244 F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt 246 [RFC2475] RFC 2475, "An Architecture for Differentiated Services", 247 S. Blake, D. Black, M.Carlson, E.Davies, Z.Wang,W.Weiss, 248 www.ietf.org/rfc/rfc2475.txt 250 [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J. 251 Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt 253 [CBQ] S. Floyd and V. Jacobson, Link-sharing and Resource Management 254 Models for Packet Networks, IEEE/ACM Transactions on Networking, 255 Vol. 3 No. 4, pp. 365-386, August 1995 257 [LBE] "A Lower Than Best-Effort Per-Hop Behavior", 258 draft-bless-diffserv-phb-lbe-00.txt, R. Bless and K. Wehrle, 1999, 259 (work in progress). 261 Authors' Addresses 263 Brian Carpenter Kathleen Nichols 264 IBM Packet Design 265 c/o iCAIR 66 Willow Place 266 Suite 150 Menlo Park, CA 94025 267 1890 Maple Avenue USA 268 Evanston, IL 60201 269 USA 270 email: brian@icair.org email: nichols@packetdesign.com