idnits 2.17.1 draft-menth-pcn-marking-converter-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Menth08-PCN-Comparison' is mentioned on line 237, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-01 == Outdated reference: A later version (-03) exists of draft-menth-pcn-performance-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Menth 3 Internet-Draft F. Lehrieder 4 Expires: January 8, 2009 University of Wuerzburg 5 July 7, 2008 7 Marking Converter for Excess-Marked Traffic 8 draft-menth-pcn-marking-converter-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document proposes an algorithm that converts packet markings of 42 a stream that was excess-marked based on a lower-rate into packet 43 markings that correspond to a stream that was excess-marked based on 44 a higher-rate. It may be applied in the PCN context to convert 45 marked admissible-rate-overload into marked supportable-rate- 46 overload. This allows to perform marked flow termination when 47 packets are excess-marked based on the admissible rate only. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Algorithm for Conversion of AS-Markings into ET-Markings . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 60 7.3. Other References . . . . . . . . . . . . . . . . . . . . . 10 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 Pre-congestion notification provides information to support admission 67 control and flow termination at the boundary nodes of a Diffserv 68 region in order to protect the quality of service (QoS) of inelastic 69 flows [I-D.ietf-pcn-architecture]. This is achieved by marking 70 packets on interior nodes according to some metering function 71 implemented at each node. Links are associated with an admissible 72 and a supportable rate threshold (AR, SR). 74 o When the PCN traffic rate on a link exceeds the AR of that link, 75 the link is AR-pre-congested and the PCN rate above AR is AR- 76 overload. 78 o When the PCN traffic rate on a link exceeds the SR of that link, 79 the link is SR-pre-congested and the PCN rate above SR is SR- 80 overload. 82 Excess marking is a mechanism marking packets exceeding a certain 83 reference rate. If applied with AR or SR as reference rate on a link 84 of the PCN domain, excess marking marks the AR- or SR-overload. We 85 call the marks based on AR admission-stop (AS) marking and the marks 86 based on SR excess-traffic (ET) marking. Admission control requires 87 AS-marking while flow termination requires ET-marking. Having two 88 different markers is desirable to perform admission control and flow 89 termination based on direct feedback from the network, but it 90 increases hardware and encoding complexity. 92 The single-marking draft [I-D.charny-pcn-single-marking] proposes one 93 method to perform measured rate termination based on AR-overload. It 94 requires that SR=u*AR on all links within the PCN domain. 96 In this document we present a conversion algorithm that converts AS- 97 markings of a packet stream into ET-markings. Admission control can 98 be performed based on the original AS-markings and flow termination 99 can be performed based on the converted ET-markings. To that end, 100 any flow termination method working with SR-overload can be applied 101 ([Menth08-PCN-Comparison], Section 7). 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Terminology 109 Most of the terminology used in this document is defined in 110 [I-D.ietf-pcn-architecture]. The following additional terms are 111 defined. 113 o Admissible rate (AR) - PCN lower rate 115 o Supportable rate (SR) - PCN upper rate 117 o AR-overload - PCN traffic rate above AR 119 o SR-overload - PCN traffic rate above SR 121 o Excess marking - metering and marking mechanism marking all 122 packets exceeding a reference rate (excess rate marking in 123 [I-D.eardley-pcn-marking-behaviour]) 125 o Admission-stop (AS) marking - marking based on AR as reference 126 rate 128 o Excess-traffic (ET) marking - marking based on SR as reference 129 rate 131 3. Algorithm for Conversion of AS-Markings into ET-Markings 133 The conversion algorithm is applied by the egress node on an ingress- 134 egress aggregate basis. It is called for each packet arrival and 135 either converts an existing AS-mark into an ET-mark or clears it. 136 The algorithm is based on a token bucket (TB) with size S, fill state 137 F, and threshold T. It differs from conventional TB implementations 138 as it does not have a constant fill rate R. Its operation is 139 explained in Algorithm 1. 141 Algorithm 1: 143 Input: token bucket parameters S, F, and T, packet size B and marking M 145 1: if (M == unmarked) then 146 2: F = min(S, F + (u - 1) * B); 147 3: else if (F >= T) then 148 4: F = F - B; 149 5: M = unmarked; 150 6: else 151 7: M = ET; 152 8: end if 154 The number of tokens in the bucket F indicates how many AS-marked 155 bytes can be re-marked to unmarked. Initially, the token bucket 156 should be filled. For each non-AS-marked byte, the fill state F is 157 incremented by u-1 tokens (cf. line 1-2). When a packet arrives AS- 158 marked and if the fill state F is larger than a certain threshold T, 159 the packet is re-marked to unmarked and the fill state of the TB is 160 reduced by the packet size B. Otherwise, the packet remains marked 161 which is then interpreted as ET-marking (cf. line 3-8). 163 The threshold T is used to achieve packet-size independent marking 164 conversion and should be set to the maximum transfer unit. A 165 sufficiently large TB size S is needed to tolerate short-term 166 variations of packet markings, i.e. a burst of S AS-marked bytes 167 should not be ET-marked. However, this tolerance also delays initial 168 re-marking. Further experimentation and performance evaluation of 169 this approach is required. 171 First simulations give a proof of concept. The conversion algorithm 172 works well if the rate of the controlled ingress-egress-aggregate is 173 large enough and if it is a rather large fraction (>10%) of the 174 traffic rate on the bottleneck link. If this is not the case, 175 packets with AS-markings occur almost random which leads to a 176 geometrically distributed distance between packet markings within an 177 ingress-egress-aggregate such that very large bursts of AS-marked 178 packets can occur even when the PCN rate is between AR and SR on the 179 bottleneck link. This leads to wrong ET-markings. As a result, 180 there is some chance for overtermination 181 ([I-D.menth-pcn-performance]) when marked flow termination for 182 ingress-egress-aggregates is used. This, however, is not a property 183 of the conversion algorithm, it's rather a property of the single 184 marking approach and also measured rate termination suffers from this 185 phenomenon. Further evaluation is required to configure the 186 conversion algorithm appropriately and to validate flow termination 187 mechanisms in combination with this converter. 189 4. IANA Considerations 191 TBD 193 5. Security Considerations 195 TBD 197 6. Conclusion 199 This document describes an algorithm that converts marked AR-overload 200 into marked SR-overload. It makes flow termination mechanisms 201 requiring SR-overload applicable in networks that mark AR-overload 202 only. This algorithm does not solve the problem that flow 203 termination based on AR-overload does not work well for multipath 204 routing ([Menth08-PCN-Comparison], Section 8.3). 206 7. References 208 7.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, March 1997. 213 7.2. Informative References 215 [I-D.charny-pcn-single-marking] 216 Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre- 217 Congestion Notification Using Single Marking for Admission 218 and Termination", draft-charny-pcn-single-marking-03 219 (work in progress), November 2007. 221 [I-D.eardley-pcn-marking-behaviour] 222 Eardley, P., "", draft-eardley-pcn-marking-behaviour-01 223 (work in progress), I-D Status active, June 2008. 225 [I-D.ietf-pcn-architecture] 226 Eardley, P., "Pre-Congestion Notification Architecture", 227 draft-ietf-pcn-architecture-01 (work in progress), 228 October 2007. 230 [I-D.menth-pcn-performance] 231 Menth, M. and F. Lehrieder, "Performance Evaluation of 232 PCN-Based Algorithms", draft-menth-pcn-performance-02 233 (work in progress), February 2008. 235 7.3. Other References 237 [Menth08-PCN-Comparison] 238 Menth, M., Lehrieder, F., Briscoe, B., Eardley, P., 239 Moncaster, T., Babiarz, J., Chan, K., Charny, A., 240 Karagiannis, G., and X. Zhang, "PCN-Based Admission 241 Control and Flow Termination", 2008, . 245 Authors' Addresses 247 Michael Menth 248 University of Wuerzburg 249 Am Hubland 250 Wuerzburg D-97074 251 Germany 253 Phone: +49-931-888-6644 254 Email: menth@informatik.uni-wuerzburg.de 256 Frank Lehrieder 257 University of Wuerzburg 258 Am Hubland 259 Wuerzburg D-97074 260 Germany 262 Phone: +49-931-888-6651 263 Email: lehrieder@informatik.uni-wuerzburg.de 265 Full Copyright Statement 267 Copyright (C) The IETF Trust (2008). 269 This document is subject to the rights, licenses and restrictions 270 contained in BCP 78, and except as set forth therein, the authors 271 retain all their rights. 273 This document and the information contained herein are provided on an 274 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 275 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 276 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 277 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 278 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 279 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 281 Intellectual Property 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org. 305 Acknowledgment 307 Funding for the RFC Editor function is provided by the IETF 308 Administrative Support Activity (IASA).