idnits 2.17.1 draft-ietf-tsvwg-tunnel-congestion-feedback-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 18 has weird spacing: '...A basic model...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 30, 2016) is 2765 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC793' is mentioned on line 91, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'ConEx' is mentioned on line 105, but not defined == Unused Reference: 'RFC3168' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC6040' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'CONEX' is defined on line 675, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-circuit-breaker-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Wei 3 INTERNET-DRAFT Huawei Technologies 4 Intended Status: Informational L.Zhu 5 Expires: April 3, 2017 Huawei Technologies 6 L.Deng 7 China Mobile 8 September 30, 2016 10 Tunnel Congestion Feedback 11 draft-ietf-tsvwg-tunnel-congestion-feedback-03 13 Abstract 15 This document describes a mechanism to calculate congestion of a 16 tunnel segment based on RFC6040 recommendations, and a feedback 17 protocol by which to send the measured congestion of the tunnel from 18 egress to ingress . A basic model for measuring tunnel congestion 19 and feedback is described, and a protocol for carrying the feedback 20 data is outlined. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions And Terminologies . . . . . . . . . . . . . . . . . 3 62 3. Congestion Information Feedback Models . . . . . . . . . . . . 4 63 3.1 Direct Model . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2 Centralized Model . . . . . . . . . . . . . . . . . . . . . 4 65 4. Congestion Level Measurement . . . . . . . . . . . . . . . . . 5 66 5. Congestion Information Delivery . . . . . . . . . . . . . . . . 8 67 5.1 IPFIX Extentions . . . . . . . . . . . . . . . . . . . . . . 9 68 5.1.1 ce-cePacketTotalCount . . . . . . . . . . . . . . . . . 9 69 5.1.2 ect0-nectPacketTotalCount . . . . . . . . . . . . . . . 9 70 5.1.3 ect1-nectPacketTotalCount . . . . . . . . . . . . . . . 10 71 5.1.4 ce-nectPacketTotalCount . . . . . . . . . . . . . . . . 10 72 5.1.5 ce-ect0PacketTotalCount . . . . . . . . . . . . . . . . 10 73 5.1.6 ce-ect1PacketTotalCount . . . . . . . . . . . . . . . . 11 74 5.1.7 ect0-ect0PacketTotalCount . . . . . . . . . . . . . . . 11 75 5.1.8 ect1-ect1PacketTotalCount . . . . . . . . . . . . . . . 11 76 6. Congestion Management . . . . . . . . . . . . . . . . . . . . . 12 77 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 81 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 In IP network, persistent congestion (or named congestion collapse) 88 lowers transport throughput, leading to waste of network resource. 89 Appropriate congestion control mechanisms are therefore critical to 90 prevent the network from falling into the persistent congestion 91 state. Currently, transport protocols such as TCP[RFC793], 92 SCTP[RFC4960], DCCP[RFC4340], have their built-in congestion control 93 mechanisms, and even for certain single transport protocol like TCP 94 there can be a couple of different congestion control mechanisms to 95 choose from. All these congestion control mechanisms are implemented 96 on host side, and there are reasons that only host side congestion 97 control is not sufficient for the whole network to keep away from 98 persistent congestion. For example, (1) some protocol's congestion 99 control scheme may have internal design flaws; (2) improper software 100 implementation of protocol; (3) some transport protocols do not even 101 provide congestion control at all. 103 In order to have a better control on network congestion status, it's 104 necessary for the network side to do certain kind of traffic control. 105 For example, ConEx [ConEx] provides a method for network operator to 106 learn about traffic's congestion contribution information, and then 107 congestion management action can be taken based on this information. 109 Tunnels are widely deployed in various networks including public 110 Internet, datacenter network, and enterprise network etc. A tunnel 111 consists of ingress, egress and a set of interior routers. For the 112 tunnel scenario, a tunnel-based mechanism which is different from 113 ConEx is introduced for network traffic control to keep the network 114 from persistent congestion. Here, tunnel ingress will implement 115 congestion management function to control the traffic entering the 116 tunnel. 118 In order to perform congestion management at ingress, the ingress 119 must first obtain the inner tunnel congestion level information. Yet 120 the ingress cannot use the locally visible traffic rates, because it 121 would require additional knowledge of downstream capacity and 122 topology, as well as cross traffic that does not pass through this 123 ingress. 125 This document provides a mechanism of feeding back inner tunnel 126 congestion level to the ingress. Using this mechanism the egress can 127 feed the tunnel congestion level information it collects back to the 128 ingress. After receiving this information the ingress will be able to 129 perform congestion management according to network management policy. 131 2. Conventions And Terminologies 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119] 136 DP: Decision Point, an logical entity that make congestion management 137 decision based on the received congestion feedback information. 139 AP: Action Point, an logical entity that implements congestion 140 management action according to the decision made by Decision Point. 142 3. Congestion Information Feedback Models 144 According to specific network deployment, there are two kinds of 145 feedback model: direct model and centralized model. 147 3.1 Direct Model 148 Feedback 149 +-----------------------------------+ 150 | | 151 | | 152 | V 153 +--------------+ +-------------+ 154 | +--------+ | | +---------+ | 155 | |Exporter| | | |Collector| | 156 | +---|----+ | | +---|-----+ | 157 | +--|--+ | | +|-+ | 158 | |Meter| | | |DP| | 159 | +-----+ | | +--+ | 160 | | | +--+ | 161 | | | |AP| | 162 | | | +--+ | 163 |Egress | | Ingress | 164 +--------------+ +-------------+ 166 (a) Direct Feedback Model. 168 Direct model means egress feeds information directly to ingress. The 169 egress consists of Meter function and Exporter function, the Meter 170 function collects network congestion level information, and convey 171 the information to Exporter which feeds back the information to the 172 Collector function locating at ingress, after that congestion 173 management Decision Point (DP) function on ingress will make 174 congestion management decision based on the information from 175 Collector. The ingress here will act as both the decision point that 176 decides how to do congestion management and the action point that 177 implements congestion management decision. 179 3.2 Centralized Model 180 +-------------------+ 181 |+---------+ +--+ | 182 feedback ||Collector|---|DP| | 183 +---->|+---------+ +--+ |######### 184 | | | # 185 | | Controller | # 186 | +-------------------+ # 187 | # 188 | # 189 +--------------+ +------V------+ 190 | +--------+ | | | 191 | |Exporter| | | | 192 | +---|----+ | | | 193 | +--|--+ | | | 194 | |Meter| | | | 195 | +-----+ | | | 196 | | | +--+ | 197 | | | |AP| | 198 | | | +--+ | 199 |Egress | | Ingress | 200 +--------------+ +-------------+ 202 (b) Centralized Feedback Model 204 In the centralized model, the ingress only takes the role of action 205 point, and it implements traffic control decision from another entity 206 named "controller". Here, after Exporter function on egress has 207 collected network congestion level information, it feeds back the 208 information to the collector of a controller instead of the ingress. 209 Then the controller makes congestion management decision and sends 210 the decision to the ingress to implement. 212 4. Congestion Level Measurement 214 This section describes how to measure congestion level in a tunnel. 216 There could be different approaches of packet loss detection for 217 different tunneling protocol scenarios. For instance, if there is a 218 sequence field in the tunneling protocol header, it will be easy for 219 egress to detect packet loss through the gaps in sequence number 220 space. Another approach is to compare the number of packets entering 221 ingress and the number of packets arriving at egress over the same 222 span of packets. This document will focus on the latter one which is 223 a more general approach. 225 If the routers support Explicit Congestion Notification (ECN), after 226 router's queue length is over a predefined threshold, the routers 227 will marks the ECN-capable packets as Congestion Experienced (CE) or 228 drop not-ECT packets with the probability proportional to queue 229 length; if the queue overflows all packets will be dropped. If the 230 routers do not support ECN, after router's queue length is over a 231 predefined threshold, the routers will drop both the ECN-capable 232 packets and the not-ECT packets with the probability proportional to 233 the queue length. It's assumed all routers in the tunnel support ECN. 235 Faked ECN-capable transport (ECT) is used at ingress to defer packet 236 loss to egress. The basic idea of faked ECT is that, when 237 encapsulating packets, ingress first marks tunnel outer header 238 according to RFC6040, and then remarks outer header of Not-ECT packet 239 as ECT, there will be three kinds of combination of outer header ECN 240 field and inner header ECN field: CE|CE, ECT|N-ECT, ECT|ECT (in the 241 form of outer ECN| inner ECN); when decapsulating packets at egress, 242 RFC6040 defined decapsulation behavior is used, and according to 243 RFC6040, the packets marked as CE|N-ECT will be dropped by egress. 245 In case all interior routers support ECN, the network congestion 246 level could be indicated through the ratio of CE-marked packet and 247 the ratio of packet drop, the relationship between these two kinds of 248 indicator is complementary. If the congestion level in tunnel is not 249 high enough, the packets would be marked as CE instead of being 250 dropped, and then it is easy to calculate congestion level according 251 to the ratio of CE-marked packets. If the congestion level is so high 252 that ECT packet will be dropped, then the packet loss ratio could be 253 calculated by comparing total packets entering ingress and total 254 packets arriving at egress over the same span of packets, if packet 255 loss is detected, it could be assumed that severe congestion has 256 occurred in the tunnel. Because loss is only ever a sign of serious 257 congestion, so it doesn't need to measure loss ratio accurately. 259 The basic procedure of congestion level measurement is as follows: 261 +-------+ +------+ 262 |Ingress| |Egress| 263 +-------+ +------+ 264 | | 265 +----------------+ | 266 |cumulative count| | 267 +----------------+ | 268 | | 269 | | 270 |------------------------>| 271 | | 272 |<------------------------| 273 | | 274 | | 276 (a) Direct model feedback procedure 278 +----------+ +-------+ +------+ 279 |Controller| |Ingress| |Egress| 280 +----------+ +-------+ +------+ 281 | | | 282 | +----------------+ | 283 | |cumulative count| | 284 | +----------------+ | 285 | | | 286 | | | 287 | |------------------------>| 288 | | | 289 | | 290 | | 291 | | 292 | | 293 |<---------------------------------------| 294 | | 295 | | 296 | | 298 (b) Centralized model feedback procedure 300 Ingress encapsulates packets and marks outer header according to 301 faked ECT as described above. Ingress cumulatively counts packets for 302 three types of ECN combination (CE|CE, ECT|N-ECT, ECT|ECT) and then 303 the ingress regularly sends cumulative packet counts message of each 304 type of ECN combination to the egress. When each message arrives, the 305 egress cumulatively counts packets coming from the ingress and adds 306 its own packet counts of each type of ECN combination (CE|CE, ECT|N- 307 ECT, CE|N-ECT, CE|ECT, ECT|ECT) to the message and either returns the 308 whole message to the ingress, or to a central controller. 310 The counting of packets can be at the granularity of the all traffic 311 from the ingress to the egress to learn about the overall congestion 312 status of the path between the ingress and the egress. The counting 313 can also be at the granularity of individual customer's traffic or a 314 specific set of flows to learn about their congestion contribution. 316 5. Congestion Information Delivery 318 As described above, the tunnel ingress needs to convey message of 319 cumulative packet counts of each type of ECN combination to tunnel 320 egress, and the tunnel egress also needs to feed the message of 321 cumulative packet counts of each type of ECN combination to the 322 ingress or central collector. This section describes how the messages 323 could be conveyed. 325 The message can travel along the same path with network data traffic, 326 referred as in band signal; or go through a different path from 327 network data traffic, referred as out of band signal. Because out of 328 band scheme needs additional separate path which might limit its 329 actual deployment, the in band scheme will be discussed here. 331 Because the message is transmitted in band, so the message packet may 332 get lost in case of network congestion. To cope with the situation 333 that the message packet gets lost, the packet counts values are sent 334 as cumulative counters. Then if a message is lost the next message 335 will recover the missing information. 337 IPFIX [RFC7011] is selected as information feedback protocol. IPFIX 338 is preferred to use SCTP as transport. SCTP allows partially reliable 339 delivery [RFC3758], which ensures the feedback message will not be 340 blocked in case of packet loss due to network congestion. 342 Ingress can do congestion management at different granularity which 343 means both the overall aggregated inner tunnel congestion level and 344 congestion level contributed by certain traffic(s) could be measured 345 for different congestion management purpose. For example, if the 346 ingress only wants to limit congestion volume caused by certain 347 traffic(s),e.g UDP-based traffic, then congestion volume for the 348 traffic will be fed back; or if the ingress do overall congestion 349 management, the aggregated congestion volume will be fed back. 351 When sending message from ingress to egress, the ingress acts as 352 IPFIX exporter and egress acts as IPFIX collector; When feedback 353 congestion level information from egress to ingress or to controller, 354 the the egress acts as IPFIX exporter and ingress or controller acts 355 as IPFIX collector. 357 The combination of congestion level measurement and congestion 358 information delivery procedure should be as following: 360 # The ingress determines template record to be used. The template 361 record can be preconfigured or determined at runtime, the content of 362 template record will be determined according to the granularity of 363 congestion management, if the ingress wants to limit congestion 364 volume contributed by specific traffic flow then the elements such as 365 source IP address, destination IP address, flow id and CE-marked 366 packet volume of the flow etc will be included in the template 367 record. 369 # Meter on ingress measures traffic volume according to template 370 record chosen and then the measurement records are sent to egress in 371 band. 373 # Meter on egress measures congestion level information according to 374 template record, the template record can be preconfigured or use the 375 template record from ingress, the content of template record should 376 be the same as template record of ingress. 378 # Exporter of egress sends measurement record together with the 379 measurement record of ingress to Controller or back to the ingress. 381 5.1 IPFIX Extentions 383 This sub-section defines a list of new IPFIX Information Elements 384 according to RFC7013 [RFC7013]. 386 5.1.1 ce-cePacketTotalCount 388 Description: The total number of incoming packets with CE|CE ECN 389 marking combination for this Flow at the Observation Point since the 390 Metering Process (re-)initialization for this Observation Point. 392 Abstract Data Type: unsigned64 394 Data Type Semantics: totalCounter 396 ElementId: TBD1 398 Statues: current 400 Units: packets 402 5.1.2 ect0-nectPacketTotalCount 403 Description: The total number of incoming packets with ECT(0)|N-ECT 404 ECN marking combination for this Flow at the Observation Point since 405 the Metering Process (re-)initialization for this Observation Point. 407 Abstract Data Type: unsigned64 409 Data Type Semantics: totalCounter 411 ElementId: TBD2 413 Statues: current 415 Units: packets 417 5.1.3 ect1-nectPacketTotalCount 419 Description: The total number of incoming packets with ECT(1)|N-ECT 420 ECN marking combination for this Flow at the Observation Point since 421 the Metering Process (re-)initialization for this Observation Point. 423 Abstract Data Type: unsigned64 425 Data Type Semantics: totalCounter 427 ElementId: TBD3 429 Statues: current 431 Units: packets 433 5.1.4 ce-nectPacketTotalCount 435 Description: The total number of incoming packets with CE|N-ECT ECN 436 marking combination for this Flow at the Observation Point since the 437 Metering Process (re-)initialization for this Observation Point. 439 Abstract Data Type: unsigned64 441 Data Type Semantics: totalCounter 443 ElementId: TBD4 445 Statues: current 447 Units: packets 449 5.1.5 ce-ect0PacketTotalCount 450 Description: The total number of incoming packets with CE|ECT(0) ECN 451 marking combination for this Flow at the Observation Point since the 452 Metering Process (re-)initialization for this Observation Point. 454 Abstract Data Type: unsigned64 456 Data Type Semantics: totalCounter 458 ElementId: TBD5 460 Statues: current 462 Units: packets 464 5.1.6 ce-ect1PacketTotalCount 466 Description: The total number of incoming packets with CE|ECT(1) ECN 467 marking combination for this Flow at the Observation Point since the 468 Metering Process (re-)initialization for this Observation Point. 470 Abstract Data Type: unsigned64 472 Data Type Semantics: totalCounter 474 ElementId: TBD6 476 Statues: current 478 Units: packets 479 5.1.7 ect0-ect0PacketTotalCount 481 Description: The total number of incoming packets with ECT(0)|ECT(0) 482 ECN marking combination for this Flow at the Observation Point since 483 the Metering Process (re-)initialization for this Observation Point. 485 Abstract Data Type: unsigned64 487 Data Type Semantics: totalCounter 489 ElementId: TBD7 491 Statues: current 493 Units: packets 495 5.1.8 ect1-ect1PacketTotalCount 497 Description: The total number of incoming packets with ECT(1)|ECT(1) 498 ECN marking combination for this Flow at the Observation Point since 499 the Metering Process (re-)initialization for this Observation Point. 501 Abstract Data Type: unsigned64 503 Data Type Semantics: totalCounter 505 ElementId: TBD8 507 Statues: current 509 Units: packets 511 6. Congestion Management 513 After tunnel ingress (or controller) receives congestion level 514 information, then congestion management actions could be taken based 515 on the information, e.g. if the congestion level is higher than a 516 predefined threshold, then action could be taken to reduce the 517 congestion level. 519 The design of network side congestion management SHOULD take host 520 side e2e congestion control mechanism into consideration, which means 521 the congestion management needs to avoid the impacts on e2e 522 congestion control. For instance, congestion management action must 523 be delayed by more than a worst-case global RTT, otherwise tunnel 524 traffic management will not give normal e2e congestion control enough 525 time to do its job, and the system could go unstable. 527 The detailed description of congestion management is out of scope of 528 this document, as examples, congestion management such as circuit 529 breaker [CB] and congestion policing [CP] could be applied. Circuit 530 breaker is an automatic mechanism to estimate congestion, and to 531 terminate flow(s) when persistent congestion is detected to prevent 532 network congestion collapse; Congestion policing is used in data 533 center to limit the amount of congestion any tenant can cause 534 according to the congestion information in the tunnels. 536 7. Security 538 This document describes the tunnel congestion calculation and 539 feedback. For feeding back congestion, security mechanisms of IPFIX 540 are expected to be sufficient. No additional security concerns are 541 expected. 543 8. IANA Considerations 545 This document defines a set of new IPFIX Information Elements 546 (IE),which need to be registered at IANA IPFIX Information Element 547 Registry. 549 ElementID: TBD1 550 Name:ce-cePacketTotalCount 551 Data Type: unsigned64 552 Data Type Semantics: totalCounter 553 Status: current 554 Description:The total number of incoming packets with CE|CE ECN 555 marking combination for this Flow at the Observation Point since the 556 Metering Process (re-)initialization for this Observation Point. 557 Units: packets 559 ElementID: TBD2 560 Name:ect0-nectPacketTotalCount 561 Data Type: unsigned64 562 Data Type Semantics: totalCounter 563 Status: current 564 Description:The total number of incoming packets with ECT(0)|N-ECT 565 ECN marking combination for this Flow at the Observation Point since 566 the Metering Process (re-)initialization for this Observation Point. 567 Units: packets 569 ElementID: TBD3 570 Name: ect1-nectPacketTotalCount 571 Data Type: unsigned64 572 Data Type Semantics: totalCounter 573 Status: current 574 Description:The total number of incoming packets with ECT(1)|N-ECT 575 ECN marking combination for this Flow at the Observation Point since 576 the Metering Process (re-)initialization for this Observation Point. 577 Units: packets 579 ElementID: TBD4 580 Name:ce-nectPacketTotalCount 581 Data Type: unsigned64 582 Data Type Semantics: totalCounter 583 Status: current 584 Description:The total number of incoming packets with CE|N-ECT ECN 585 marking combination for this Flow at the Observation Point since the 586 Metering Process (re-)initialization for this Observation Point. 587 Units: packets 589 ElementID: TBD5 590 Name:ce-ect0PacketTotalCount 591 Data Type: unsigned64 592 Data Type Semantics: totalCounter 593 Status: current 594 Description:The total number of incoming packets with CE|ECT(0) ECN 595 marking combination for this Flow at the Observation Point since the 596 Metering Process (re-)initialization for this Observation Point. 597 Units: packets 599 ElementID: TBD6 600 Name:ce-ect1PacketTotalCount 601 Data Type: unsigned64 602 Data Type Semantics: totalCounter 603 Status: current 604 Description:The total number of incoming packets with CE|ECT(1) ECN 605 marking combination for this Flow at the Observation Point since the 606 Metering Process (re-)initialization for this Observation Point. 607 Units: packets 609 ElementID: TBD7 610 Name:ect0-ect0PacketTotalCount 611 Data Type: unsigned64 612 Data Type Semantics: totalCounter 613 Status: current 614 Description:The total number of incoming packets with ECT(0)|ECT(0) 615 ECN marking combination for this Flow at the Observation Point since 616 the Metering Process (re-)initialization for this Observation Point. 617 Units: packets 619 ElementID: TBD8 620 Name:ect1-ect1PacketTotalCount 621 Data Type: unsigned64 622 Data Type Semantics: totalCounter 623 Status: current 624 Description:The total number of incoming packets with 625 ECT(1)|ECT(1)ECN marking combination for this Flow at the Observation 626 Point since the Metering Process (re-)initialization for this 627 Observation Point. 628 Units: packets 630 [TO BE REMOVED: This registration should take place at the following 631 location: http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix- 632 information-elements] 634 9. References 636 9.1 Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997, 640 . 642 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 643 of Explicit Congestion Notification (ECN) to IP", 644 RFC 3168, September 2001, . 647 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 648 Conrad, "Stream Control Transmission Protocol (SCTP) 649 Partial Reliability Extension", RFC 3758, May 2004, 650 . 652 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 653 Congestion Control Protocol (DCCP)", RFC 4340, March 2006, 654 . 656 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 657 RFC 4960, September 2007, . 660 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 661 Notification", RFC 6040, November 2010, . 664 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 665 "Specification of the IP Flow Information Export (IPFIX) 666 Protocol for the Exchange of Flow Information", STD 77, 667 RFC 7011, September 2013, . 670 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 671 Reviewers of IP Flow Information Export (IPFIX) 672 Information Elements", BCP 184, RFC 7013, September 2013, 673 . 675 [CONEX] Matt Mathis, Bob Briscoe. "Congestion Exposure (ConEx) 676 Concepts, Abstract Mechanism and Requirements", RFC7713, 677 December 2015 679 9.2 Informative References 681 [CB] G. Fairhurst. "Network Transport Circuit Breakers", draft-ietf- 682 tsvwg-circuit-breaker-01, April 02, 2015 684 [CP] Bob Briscoe, Murari Sridharan. "Network Performance Isolation 685 in Data Centres using Congestion Policing", draft-briscoe- 686 conex-data-centre-02, February 14, 2014 688 10. Acknowledgements 689 Thanks Bob Briscoe for his insightful suggestions on the basic 690 mechanisms of congestion information collection and many other useful 691 comments. Thanks David Black for his useful technical suggestions. 692 Also, thanks Anthony Chan and John Kaippallimalil for their careful 693 reviews. 695 Authors' Addresses 697 Xinpeng Wei 698 Beiqing Rd. Z-park No.156, Haidian District, 699 Beijing, 100095, P. R. China 700 E-mail: weixinpeng@huawei.com 702 Zhu Lei 703 Beiqing Rd. Z-park No.156, Haidian District, 704 Beijing, 100095, P. R. China 705 E-mail:lei.zhu@huawei.com 707 Lingli Deng 708 Beijing, 100095, P. R. China 709 E-mail: denglingli@gmail.com