idnits 2.17.1 draft-menth-pcn-emft-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 391. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (February 18, 2008) is 5905 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-MFT' is mentioned on line 303, but not defined == Missing Reference: 'DT' is mentioned on line 262, but not defined == Missing Reference: 'R' is mentioned on line 263, but not defined == Outdated reference: A later version (-01) exists of draft-babiarz-pcn-3sm-00 == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-01 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Menth 3 Internet-Draft F. Lehrieder 4 Expires: August 21, 2008 University of Wuerzburg 5 P. Eardley 6 BT 7 A. Charny 8 Cisco Systems, Inc. 9 J. Babiarz 10 Nortel 11 February 18, 2008 13 Edge-Assisted Marked Flow Termination 14 draft-menth-pcn-emft-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 21, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document presents edge-assisted marked flow termination (EMFT) 48 for PCN. It assumes packet-size independent excess marking, i.e. 49 packets exceeding the supportable rate (SR) of a link are marked as 50 "excess-traffic" (ET). EMFT terminates only flows with at least one 51 ET-marked packet. The problem is to avoid that all flows with ET- 52 marked packets are terminated. This draft proposes two solutions. 53 Flow-based EMFT (F-EMFT) considers single flows separately and 54 terminates them when sufficiently many packets of them have been 55 received by the PCN egress node with an ET-mark. Aggregate-based 56 EMFT (A-EMFT) considers ingress-egress-aggregates and terminates 57 flows thereof sufficiently many ET-marked packets have been received 58 for that aggregate. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Required Marking Behavior . . . . . . . . . . . . . . . . . . 7 65 3.1. Conventional Excess Marking . . . . . . . . . . . . . . . 7 66 3.2. Packet Size Independent Excess Marking (PSIEM) . . . . . . 7 67 4. Flow-Based Edge-Assisted Marked Flow Termination (F-EMFT) . . 8 68 5. Aggregate-Based Edge-Assisted Marked Flow Termination 69 (A-EMFT) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 6.3. Other References . . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 13 77 1. Introduction 79 PCN defines a new PCN traffic class that receives preferred treatment 80 by PCN nodes. It provides information to support admission control 81 (AC) and flow termination (FT) for this traffic type. PCN introduces 82 an admissible and a supportable rate threshold (AR(l), SR(l)) for 83 each link l of the network which imply three different link states. 84 If the PCN traffic rate r(l) is below AR(l), there is no pre- 85 congestion and further flows may be admitted. If the PCN traffic 86 rate r(l) is above AR(l), the link is AR-pre-congested and the rate 87 above AR(l) is AR-overload. In this state, no further flows should 88 be admitted. If the PCN traffic rate r(l) is above SR(l), the link 89 is SR-pre-congested and the rate above SR(l) is SR-overload. In this 90 state, some already admitted flows should be terminated. PCN nodes 91 monitor the PCN rate on their links and they remark packets depending 92 on their pre-congestion states. The PCN egress nodes evaluate the 93 packet markings and their essence is reported to the AC and FT 94 entities of the network such that they can take appropriate actions. 95 Therefore, this concept is called pre-congestion notification. This 96 draft proposes a new FT method. 98 The CL draft [I-D.briscoe-tsvwg-cl-architecture] proposes that all 99 packets above SR are marked with "excess-traffic" (ET). Packets of 100 the same ingress-egress aggregate (IEA) are grouped together for a 101 joint evaluation of their markings by the PCN egress node. If 102 packets are ET-marked, the PCN egress node signals the rate of 103 unmarked packets to the PCN ingress node which terminates so many 104 flows that their rate corresponds to the difference of the sent rate 105 per IEA and the rate that was received non-ET-marked by the PCN 106 egress node. We call this solution measured rate termination (MRT). 107 This solution has two major drawbacks: 109 o At low aggregation it is hard for the ingress node to determine an 110 appropriate set of flows to be terminated. Example: only a single 111 flow with 1 Mbit/s in the IEA, and 500 kbit/s should be 112 terminated. When many ingress nodes face the same problem and 113 solve it with the same algorithm, either overtermination or 114 undertermination occurs. 116 o In case of multipath routing, flows of a single IEA may take 117 different routes. The ingress node chooses the set of flows for 118 termination, but does not know which flows are carried over a pre- 119 congested link. Therefore, the wrong flows are possibly 120 terminated. 122 The 3sm draft [I-D.babiarz-pcn-3sm] proposes marked flow termination. 123 If a PCN node receives an ET-marked packet, it notifies the FT entity 124 to terminate the flow. To avoid overtermination, only a subset of 125 the packets above SR are ET-marked. The concept of IEA is not 126 needed. This method is called core-assisted marked flow termination 127 (CMFT) as only marked flows are terminated and core nodes help to 128 identify the flows that should be terminated. This method has one 129 major drawback: 131 o It requires packet size independent excess marking with marking 132 frequency reduction (MFR) which is not yet available in today's 133 routers. 135 Given the two approaches with their drawbacks, a FT method is 136 desirable where conventional excess marking can be used by PCN nodes, 137 that terminates only marked flows, and that is able to cope with IEAs 138 having only a small number of flows. We present such a solution in 139 this draft and call it edge-assisted marked flow termination (EMFT). 140 The motivating idea for EMFT is to roll a dice at the edges to decide 141 whether a marked packet is to be terminated instead of letting the 142 core nodes decide. The actual solution is slightly different and 143 saves the generation of random numbers per packet. 145 The next section clarifies some terminology issues. We then describe 146 the required marking behaviour. We present flow-based and aggregate- 147 based EMFT as new FT mechanisms and discuss security issues. 149 2. Terminology 151 The terminology used in this document conforms to the topology of 152 [I-D.ietf-pcn-architecture]. 154 We use the following exceptions for better readability and provide 155 the synonyms defined in [I-D.ietf-pcn-architecture]. 157 o Admissible rate: PCN-lower-rate 159 o Supportable rate: PCN-upper-rate 161 o Admission-stop marking: first encoding or PCN-lower-rate-marking 163 o Excess-traffic marking: second encoding or PCN-upper-rate-marking 165 New terminology 167 o Flow termination (FT): function to terminate flows in case of SR- 168 pre-congestion 170 o No-pre-congestion (NP) marking: marking for packets that have not 171 yet experience any form of pre-congestion 173 o Packet size independent marking (PSIM): marks all packets 174 exceeding a certain rate, but the marking probability of a packet 175 is independent of its size. This is in contrast to pure excess 176 marking. May be implemented by a threshold marking algorithm. 178 o MFT: marked flow termination terminates only flows with at least 179 one ET-marked packet; guarantees that terminated flow traverses an 180 AR-pre-congested link. 182 o CMFT: core-assisted MFT: core nodes apply marking frequency 183 reduction to control termination speed of MFT 185 o EMFT: edge-assisted MFT: egde nodes control the termination speed 186 of MFT 188 o F-EMFT: flow-based EMFT 190 o A-EMFT: aggregate-based EMFT 192 o IEA: ingress-egress aggregate 194 o Flow termination delay D_T: duration of the interval between the 195 decision for the termination of a flow at the PCN egress node and 196 the time the PCN egress node does not receive packets of that flow 197 anymore. 199 3. Required Marking Behavior 201 EMFT works with conventional excess marking, but for the sake of 202 fairness, packet-size independent excess marking is preferred. We 203 describe both marking behaviours in the following. 205 3.1. Conventional Excess Marking 207 Conventional excess marking is based on a token bucket with size S 208 and Rate R. When a packet arrives, and the number of tokens in the 209 bucket is at least the packet size, the number of tokens is reduced 210 by the packet size. If the number of tokens in the bucket is smaller 211 than the packet size, the packet is marked. 213 Larger packets have a higher probability to be marked. Therefore, 214 marked flow termination (MFT) algorithms terminate flows sending 215 larger packets with a higher probability than flows sending small 216 packets. 218 3.2. Packet Size Independent Excess Marking (PSIEM) 220 PSIEM addresses the above problem and makes the marking probability 221 independent of the packet size. To that end, a marking threshold T 222 is introduced which is set to the maximum transfer unit (MTU). If a 223 packet arrives and the number of tokens in the bucket is T or larger, 224 the number of tokens in the bucket is reduced by the packet size. If 225 the number of tokens in the bucket is smaller than the threshold T, 226 it remains unchanged, but the packet is marked. 228 4. Flow-Based Edge-Assisted Marked Flow Termination (F-EMFT) 230 The PCN egress node keeps a credit counter C for each flow. When an 231 ET-marked packet arrives for a flow, the corresponding credit counter 232 is reduced by the size of that packet. If the credit counter is non- 233 positive at the arrival of a marked packet, the flow is terminated. 235 The difficulty is the suitable initialization of the credit counter 236 when a reservation is set up for a new flow. In [Menth08-PCN-MFT] we 237 have shown that the initial counter size should be exponentially 238 distributed with mean 2*R_f*E[DT]/alpha where R_f is the rate of the 239 flow f, E[DT] is a global average value for the flow termination 240 delay, and alpha is a knob to control the termination speed. The 241 parameter alpha should be set at most 1 to avoid that flows are 242 terminated too fast such that overtermination occurs. Smaller alpha 243 results in a longer time to reduce SR-overload. The impact of these 244 parameters is also studied in [Menth08-PCN-MFT]. 246 Statistical flow termination priorities can be implemented by 247 granting larger initial credit counters to more important flows. 249 We give an example for a potential technical implementation of the 250 exponentially distributed credit counter size distribution. The end 251 system generates a random number x between 0 and 1. Then it 252 determines the initial size of the credit counter by 253 C=-ln(x)*2*R_f*E[D_T]/alpha. 255 5. Aggregate-Based Edge-Assisted Marked Flow Termination (A-EMFT) 257 If it is easy for the PCN egress node to identify all packets of the 258 same PCN ingress node, the packet markings can be evaluated on an 259 aggregate basis. Then, the following algorithm may be used. A 260 credit counter is associated with each IEA and initialized similarly 261 as for F-EMFT, i.e. by an exponential distribution with average value 262 2*E[R]*E[DT]/alpha where E[R] is the average rate of the current 263 flows in the IEA. Usually, E[R] is the rate R_f of the first flow 264 when the system starts with a single flow. 266 When ET-marked packets arrive and the credit counter is positive, the 267 size of the credit counter C is reduced by the packet size. If the 268 credit counter C is not positive, a flow f of the aggregate is 269 terminated and a deterministic increment of I=2*R_f*E[DT]/alpha is 270 added to the credit counter, i.e., the increment is proportional to 271 the rate of the terminated flow f. With this configuration, F-EMFT 272 and A-EMFT lead to the same termination behaviour. 274 Note that the flow f to be terminated can be the flow to which the 275 last ET-marked packet belongs to, but it may also be any other flow 276 for which an ET-marked packet recently arrived. This allows the 277 enforcement of termination policies. For instance, high priority 278 flows may be later terminated than low priority flows. 280 6. References 282 6.1. Normative References 284 6.2. Informative References 286 [I-D.babiarz-pcn-3sm] 287 Babiarz, J., "Three State PCN Marking", 288 draft-babiarz-pcn-3sm-00 (work in progress), July 2007. 290 [I-D.briscoe-tsvwg-cl-architecture] 291 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 292 Congestion Notification: Admission Control over a 293 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 294 (work in progress), October 2006. 296 [I-D.ietf-pcn-architecture] 297 Eardley, P., "Pre-Congestion Notification Architecture", 298 draft-ietf-pcn-architecture-01 (work in progress), 299 October 2007. 301 6.3. Other References 303 [Menth08-PCN-MFT] 304 Menth, M. and F. Lehrieder, "Termination Methods for End- 305 to-End PCN-Based Flow Control", February 2008, . 309 Authors' Addresses 311 Michael Menth 312 University of Wuerzburg 313 Am Hubland 314 Wuerzburg D-97074 315 Germany 317 Phone: +49-931-888-6644 318 Email: menth@informatik.uni-wuerzburg.de 320 Frank Lehrieder 321 University of Wuerzburg 322 Am Hubland 323 Wuerzburg D-97074 324 Germany 326 Phone: +49-931-888-6634 327 Email: lehrieder@informatik.uni-wuerzburg.de 329 Philip Eardley 330 BT 331 B54/77, Sirius House Adastral Park Martlesham Heath 332 Ipswich, Suffolk IP5 3RE 333 United Kingdom 335 Email: philip.eardley@bt.com 337 Anna Charny 338 Cisco Systems, Inc. 339 1414 Mass. Ave. 340 Boxborough, MA 01719 341 USA 343 Email: acharny@cisco.com 344 Jozef Z. Babiarz 345 Nortel 346 3500 Carling Avenue 347 Ottawa, Ont. K2H 8E9 348 Canada 350 Phone: +1-613-763-6098 351 Email: babiarz@nortel.com 353 Full Copyright Statement 355 Copyright (C) The IETF Trust (2008). 357 This document is subject to the rights, licenses and restrictions 358 contained in BCP 78, and except as set forth therein, the authors 359 retain all their rights. 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 364 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 365 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 366 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Intellectual Property 371 The IETF takes no position regarding the validity or scope of any 372 Intellectual Property Rights or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; nor does it represent that it has 376 made any independent effort to identify any such rights. Information 377 on the procedures with respect to rights in RFC documents can be 378 found in BCP 78 and BCP 79. 380 Copies of IPR disclosures made to the IETF Secretariat and any 381 assurances of licenses to be made available, or the result of an 382 attempt made to obtain a general license or permission for the use of 383 such proprietary rights by implementers or users of this 384 specification can be obtained from the IETF on-line IPR repository at 385 http://www.ietf.org/ipr. 387 The IETF invites any interested party to bring to its attention any 388 copyrights, patents or patent applications, or other proprietary 389 rights that may cover technology that may be required to implement 390 this standard. Please address the information to the IETF at 391 ietf-ipr@ietf.org. 393 Acknowledgment 395 Funding for the RFC Editor function is provided by the IETF 396 Administrative Support Activity (IASA).