idnits 2.17.1 draft-ietf-tsvwg-tunnel-congestion-feedback-04.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 106 has weird spacing: '...plement conge...' == Line 305 has weird spacing: '... should be th...' == Line 575 has weird spacing: '... number of CE...' == 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 (January 25, 2017) is 2647 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: 'RFC2914' is mentioned on line 85, but not defined == Missing Reference: 'RFC793' is mentioned on line 89, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC6040' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'CONEX' is defined on line 742, 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 (~~), 10 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: July 29, 2017 Huawei Technologies 6 L.Deng 7 China Mobile 8 January 25, 2017 10 Tunnel Congestion Feedback 11 draft-ietf-tsvwg-tunnel-congestion-feedback-04 13 Abstract 15 This document describes a method to measure congestion on a tunnel 16 segment based on recommendations from RFC 6040, "Tunneling of 17 Explicit Congestion Notification", and to use IPFIX to communicate 18 the congestion measurements from the tunnel's egress to a controller 19 which can respond by modifying the traffic control policies at the 20 tunnel's ingress. 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 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions And Terminologies . . . . . . . . . . . . . . . . . 3 61 3. Congestion Information Feedback Models . . . . . . . . . . . . 3 62 4. Congestion Level Measurement . . . . . . . . . . . . . . . . . 4 63 5. Congestion Information Delivery . . . . . . . . . . . . . . . . 6 64 5.1 IPFIX Extensions . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1.1 tunnelEcnCeCePacketTotalCount . . . . . . . . . . . . . 8 66 5.1.2 tunnelEcnEct0NectPacketTotalCount . . . . . . . . . . . 8 67 5.1.3 tunnelEcnEct1NectPacketTotalCount . . . . . . . . . . . 8 68 5.1.4 tunnelEcnCeNectPacketTotalCount . . . . . . . . . . . . 9 69 5.1.5 tunnelEcnCeEct0PacketTotalCount . . . . . . . . . . . . 9 70 5.1.6 tunnelEcnCeEct1PacketTotalCount . . . . . . . . . . . . 9 71 5.1.7 tunnelEcnEct0Ect0PacketTotalCount . . . . . . . . . . . 10 72 5.1.8 tunnelEcnEct1Ect1PacketTotalCount . . . . . . . . . . . 10 73 6. Congestion Management . . . . . . . . . . . . . . . . . . . . . 10 74 6.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 79 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 In IP networks, persistent congestion[RFC2914] lowers transport 86 throughput, leading to waste of network resource. Appropriate 87 congestion control mechanisms are therefore critical to prevent the 88 network from falling into the persistent congestion state. Currently, 89 transport protocols such as TCP[RFC793], SCTP[RFC4960], 90 DCCP[RFC4340], have their built-in congestion control mechanisms, and 91 even for certain single transport protocol like TCP there can be a 92 couple of different congestion control mechanisms to choose from. All 93 these congestion control mechanisms are implemented on host side, and 94 there are reasons that only host side congestion control is not 95 sufficient for the whole network to keep away from persistent 96 congestion. For example, (1) some protocol's congestion control 97 scheme may have internal design flaws; (2) improper software 98 implementation of protocol; (3) some transport protocols, e.g. 99 RTP[RFC3550] do not even provide congestion control at all. 101 Tunnels are widely deployed in various networks including public 102 Internet, data center network, and enterprise network etc. A tunnel 103 consists of ingress, egress and a set of intermediate routers. For 104 the tunnel scenario, a tunnel-based mechanism is introduced for 105 network traffic control to keep the network from persistent 106 congestion. Here, tunnel ingress will implement congestion 107 management function to control the traffic entering the tunnel. 109 This document provides a mechanism of feeding back inner tunnel 110 congestion level to the ingress. Using this mechanism the egress can 111 feed the tunnel congestion level information it collects back to the 112 ingress. After receiving this information the ingress will be able to 113 perform congestion management according to network management policy. 115 2. Conventions And Terminologies 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119] 121 DP: Decision Point, an logical entity that makes congestion 122 management decision based on the received congestion feedback 123 information. 125 AP: Action Point, an logical entity that implements congestion 126 management action according to the decision made by Decision Point. 128 ECT: ECN-Capable Transport code point defined in RFC3168. 130 3. Congestion Information Feedback Models 131 The feedback model mainly consists of tunnel egress and tunnel 132 ingress. The tunnel egress composes of meter function and exporter 133 function; tunnel ingress composes AP (Action Point) function, 134 collector function and DP (Decision Point) function. 136 The Meter function collects network congestion level information, and 137 conveys the information to Exporter which feeds back the information 138 to the collector function. 140 The collector collects congestion level information from exporter, 141 after that congestion management Decision Point (DP) function will 142 make congestion management decision based on the information from 143 collector. 145 The action point controls the traffic entering tunnel, and it 146 implements traffic control decision of DP. 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 +--------------+ +-------------+ 165 Figure 1: Feedback Model. 167 4. Congestion Level Measurement 169 This section describes how to measure congestion level in a 170 tunnel. 172 The congestion level measurement is based on ECN (Explicit 173 Congestion Notification) [RFC3168] and packet drop. If the routers 174 support ECN, after router's queue length is over a predefined 175 threshold, the routers will mark the ECN-capable packets as 176 Congestion Experienced (CE) or drop not-ECT packets with the 177 probability proportional to queue length; if the queue overflows 178 all packets will be dropped. If the routers do not support ECN, 179 after router's queue length is over a predefined threshold, the 180 routers will drop both the ECN-capable packets and the not-ECT 181 packets with the probability proportional to the queue length. 183 The network congestion level could be indicated through the ratio 184 of CE-marked packet and the ratio of packet drop, the relationship 185 between these two kinds of indicator is complementary. If the 186 congestion level in tunnel is not high enough, the packets would 187 be marked as CE instead of being dropped, and then it is easy to 188 calculate congestion level according to the ratio of CE-marked 189 packets. If the congestion level is so high that ECT packet will 190 be dropped, then the packet loss ratio could be calculated by 191 comparing total packets entering ingress and total packets 192 arriving at egress over the same span of packets, if packet loss 193 is detected, it could be assumed that severe congestion has 194 occurred in the tunnel. Because loss is only ever a sign of 195 serious congestion, so it doesn't need to measure loss ratio 196 accurately. 198 Faked ECN-capable transport (ECT) is used at ingress to defer 199 packet loss to egress. The basic idea of faked ECT is that, when 200 encapsulating packets, ingress first marks tunnel outer header 201 according to RFC6040, and then remarks outer header of Not-ECT 202 packet as ECT, there will be three kinds of combination of outer 203 header ECN field and inner header ECN field: CE|CE, ECT|N-ECT, 204 ECT|ECT (in the form of outer ECN| inner ECN); when decapsulating 205 packets at egress, RFC6040 defined decapsulation behavior is used, 206 and according to RFC6040, the packets marked as CE|N-ECT will be 207 dropped by egress. 209 To calculate congestion level, for the same span of packets, the 210 number of each kind of ECN marking packet at ingress and egress 211 will be compared to get the volume of CE-marked packet in the 212 tunnel; and the total number of packets at ingress and egress will 213 be compared to detect the packet loss. 215 The basic procedure of congestion level measurement is as follows: 217 +-------+ +------+ 218 |Ingress| |Egress| 219 +-------+ +------+ 220 | | 221 +----------------+ | 222 |cumulative count| | 223 +----------------+ | 224 | | 225 | | 226 |------------------------>| 227 | | 228 |<------------------------| 229 | | 230 | | 232 Figure 2: Procedure of Congestion Level Measurement 234 Ingress encapsulates packets and marks outer header according to 235 faked ECT as described above. Ingress cumulatively counts packets for 236 three types of ECN combination (CE|CE, ECT|N-ECT, ECT|ECT) and then 237 the ingress regularly sends cumulative packet counts message of each 238 type of ECN combination to the egress. When each message arrives, the 239 egress cumulatively counts packets coming from the ingress and adds 240 its own packet counts of each type of ECN combination (CE|CE, ECT|N- 241 ECT, CE|N-ECT, CE|ECT, ECT|ECT) to the message and returns the whole 242 message to the ingress. 244 The counting of packets can be at the granularity of the all traffic 245 from the ingress to the egress to learn about the overall congestion 246 status of the path between the ingress and the egress. The counting 247 can also be at the granularity of individual customer's traffic or a 248 specific set of flows to learn about their congestion contribution. 250 5. Congestion Information Delivery 252 As described above, the tunnel ingress needs to convey a message 253 containing cumulative packet counts of each type of ECN combination 254 to tunnel egress, and the tunnel egress also needs to feed back the 255 message of cumulative packet counts of each type of ECN combination 256 to the ingress. This section describes how the messages should be 257 conveyed. 259 The message travels along the same path with network data traffic, 260 referred as in-band signal. Because the message is transmitted in 261 band, so the message packet may get lost in case of network 262 congestion. To cope with the situation that the message packet gets 263 lost, the packet counts values are sent as cumulative counters. Then 264 if a message is lost the next message will recover the missing 265 information. Even though the missing information could be recovered, 266 the message should be transmitted in a much higher priority than 267 users' traffic flows. 269 IPFIX [RFC7011] is selected as information feedback protocol. IPFIX 270 uses preferably SCTP as transport. SCTP allows partially reliable 271 delivery [RFC3758], which ensures the feedback message will not be 272 blocked in case of packet loss due to network congestion. 274 Ingress can do congestion management at different granularity which 275 means both the overall aggregated inner tunnel congestion level and 276 congestion level contributed by certain traffic(s) could be measured 277 for different congestion management purpose. For example, if the 278 ingress only wants to limit congestion volume caused by certain 279 traffic(s),e.g UDP-based traffic, then congestion volume for the 280 traffic will be fed back; or if the ingress do overall congestion 281 management, the aggregated congestion volume will be fed back. 283 When sending message from ingress to egress, the ingress acts as 284 IPFIX exporter and egress acts as IPFIX collector; When feedback 285 congestion level information from egress to ingress, then the egress 286 acts as IPFIX exporter and ingress acts as IPFIX collector. 288 The combination of congestion level measurement and congestion 289 information delivery procedure should be as following: 291 # The ingress determines IPFIX template record to be used. The 292 template record can be preconfigured or determined at runtime, the 293 content of template record will be determined according to the 294 granularity of congestion management, if the ingress wants to limit 295 congestion volume contributed by specific traffic flow then the 296 elements such as source IP address, destination IP address, flow id 297 and CE-marked packet volume of the flow etc will be included in the 298 template record. 300 # Meter on ingress measures traffic volume according to template 301 record chosen and then the measurement records are sent to egress in 302 band. 304 # Meter on egress measures congestion level information according to 305 template record, the content of template record should be the same 306 as template record of ingress. 308 # Exporter of egress sends measurement record together with the 309 measurement record of ingress back to the ingress. 311 5.1 IPFIX Extensions 312 This sub-section defines a list of new IPFIX Information Elements 313 according to RFC7013 [RFC7013]. 315 5.1.1 tunnelEcnCeCePacketTotalCount 317 Description: The total number of incoming packets with CE|CE ECN 318 marking combination for this Flow at the Observation Point since the 319 Metering Process (re-)initialization for this Observation Point. 321 Abstract Data Type: unsigned64 323 Data Type Semantics: totalCounter 325 ElementId: TBD1 327 Statues: current 329 Units: packets 331 5.1.2 tunnelEcnEct0NectPacketTotalCount 333 Description: The total number of incoming packets with ECT(0)|N-ECT 334 ECN marking combination for this Flow at the Observation Point since 335 the Metering Process (re-)initialization for this Observation Point. 337 Abstract Data Type: unsigned64 339 Data Type Semantics: totalCounter 341 ElementId: TBD2 343 Statues: current 345 Units: packets 347 5.1.3 tunnelEcnEct1NectPacketTotalCount 349 Description: The total number of incoming packets with ECT(1)|N-ECT 350 ECN marking combination for this Flow at the Observation Point since 351 the Metering Process (re-)initialization for this Observation Point. 353 Abstract Data Type: unsigned64 355 Data Type Semantics: totalCounter 357 ElementId: TBD3 359 Statues: current 360 Units: packets 362 5.1.4 tunnelEcnCeNectPacketTotalCount 364 Description: The total number of incoming packets with CE|N-ECT ECN 365 marking combination for this Flow at the Observation Point since the 366 Metering Process (re-)initialization for this Observation Point. 368 Abstract Data Type: unsigned64 370 Data Type Semantics: totalCounter 372 ElementId: TBD4 374 Statues: current 376 Units: packets 378 5.1.5 tunnelEcnCeEct0PacketTotalCount 380 Description: The total number of incoming packets with CE|ECT(0) ECN 381 marking combination for this Flow at the Observation Point since the 382 Metering Process (re-)initialization for this Observation Point. 384 Abstract Data Type: unsigned64 386 Data Type Semantics: totalCounter 388 ElementId: TBD5 390 Statues: current 392 Units: packets 394 5.1.6 tunnelEcnCeEct1PacketTotalCount 396 Description: The total number of incoming packets with CE|ECT(1) ECN 397 marking combination for this Flow at the Observation Point since the 398 Metering Process (re-)initialization for this Observation Point. 400 Abstract Data Type: unsigned64 402 Data Type Semantics: totalCounter 404 ElementId: TBD6 406 Statues: current 407 Units: packets 409 5.1.7 tunnelEcnEct0Ect0PacketTotalCount 411 Description: The total number of incoming packets with ECT(0)|ECT(0) 412 ECN marking combination for this Flow at the Observation Point since 413 the Metering Process (re-)initialization for this Observation Point. 415 Abstract Data Type: unsigned64 417 Data Type Semantics: totalCounter 419 ElementId: TBD7 421 Statues: current 423 Units: packets 425 5.1.8 tunnelEcnEct1Ect1PacketTotalCount 427 Description: The total number of incoming packets with ECT(1)|ECT(1) 428 ECN marking combination for this Flow at the Observation Point since 429 the Metering Process (re-)initialization for this Observation Point. 431 Abstract Data Type: unsigned64 433 Data Type Semantics: totalCounter 435 ElementId: TBD8 437 Statues: current 439 Units: packets 441 6. Congestion Management 443 After tunnel ingress receives congestion level information, then 444 congestion management actions could be taken based on the 445 information, e.g. if the congestion level is higher than a predefined 446 threshold, then action could be taken to reduce the congestion level. 448 The design of network side congestion management SHOULD take host 449 side e2e congestion control mechanism into consideration, which means 450 the congestion management needs to avoid the impacts on e2e 451 congestion control. For instance, congestion management action must 452 be delayed by more than a worst-case global RTT (e.g. 100ms), 453 otherwise tunnel traffic management will not give normal e2e 454 congestion control enough time to do its job, and the system could go 455 unstable. 457 The detailed description of congestion management is out of scope of 458 this document, as examples, congestion management such as circuit 459 breaker [CB] could be applied. Circuit breaker is an automatic 460 mechanism to estimate congestion, and to terminate flow(s) when 461 persistent congestion is detected to prevent network congestion 462 collapse. 464 6.1 Example 466 This subsection provides an example of how the solution described in 467 this document could work. 469 First of all, IPFIX template records are exchanged between ingress 470 and egress to negotiate the format of data record, the example here 471 is to measure the congestion level for the overall tunnel (caused by 472 all the traffic in tunnel). After the negotiation is finished, 473 ingress sends in-band message to egress, the message contains the 474 number of each kind of ECN-marked packets (i.e. CE|CE, ECT|N-ECT and 475 ECT|ECT) received until the sending of message. 477 After egress receives the message, the egress counts number of 478 different kinds of ECN-marking packets received until receiving the 479 message, then the egress sends a feedback message containing the 480 counts together with the information in ingress's message to ingress. 482 Figure 3 to Figure 6 below show the example procedure between ingress 483 and egress. 485 +---------------------------------+----------------------+ 486 |Set ID=2 Length=40 | 487 |---------------------------------|----------------------| 488 |Template ID=256 Field Count =8 | 489 |---------------------------------|----------------------| 490 |tunnelEcnCeCePacketTotalCount Field Length=8 | 491 |---------------------------------|----------------------| 492 |tunnelEcnEctNectPacketTotalCount Field Length=8 | 493 |---------------------------------|----------------------| 494 |tunnelEcnEctEctPacketTotalCount Field Length=8 | 495 |---------------------------------|----------------------| 496 |tunnelEcnCeCePacketTotalCount Field Length=8 | 497 |---------------------------------|----------------------| 498 |tunnelEcnEctNectPacketTotalCount Field Length=8 | 499 |---------------------------------|----------------------| 500 |tunnelEcnEctEctPacketTotalCount Field Length=8 | 501 |---------------------------------|----------------------| 502 |tunnelEcnCeNectPacketTotalCount Field Length=8 | 503 |---------------------------------|----------------------| 504 |tunnelEcnCeEctPacketTotalCount | Field Length=8 | 505 +---------------------------------+----------------------+ 506 Figure 3: Template Record Sent From Egress to Ingress 508 +---------------------------------+----------------------+ 509 |Set ID=2 Length=28 | 510 |---------------------------------|----------------------| 511 |Template ID=257 Field Count =3 | 512 |---------------------------------|----------------------| 513 |tunnelEcnCeCePacketTotalCount Field Length=8 | 514 |---------------------------------|----------------------| 515 |tunnelEcnEctNectPacketTotalCount Field Length=8 | 516 |---------------------------------|----------------------| 517 |tunnelEcnEctEctPacketTotalCount Field Length=8 | 518 |---------------------------------|----------------------| 519 Figure 4: Template Record Sent From Ingress to Egress 521 +-------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-------+ 522 | | |M| |P| |P| |P| |M| |P| |P| | | 523 | | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | 524 | |<---------------------------------------| | 525 | | | | 526 | | | | 527 |egress | +-+ +-+ |ingress| 528 | | |M| |M| | | 529 | | +-+ +-+ | | 530 | |--------------------------------------->| | 531 | | | | 532 | | | | 533 +-------+ +-------+ 535 +-+ 536 |M| : Message Packet 537 +-+ 539 +-+ 540 |P| : User Packet 541 +-+ 543 Figure 5 Traffic flow Between Ingress and Egress 545 Set ID=257, Length=28 546 +------+ A1 +------+ 547 | | B1 | | 548 | | C1 | | 549 | | <----------------------------- | | 550 | | | | 551 | | | | 552 | | SetID=256, Length=68 | | 553 | | A1 | | 554 | | B1 | | 555 |egress| C1 ingress| 556 | | A2 | | 557 | | B2 | | 558 | | C2 | | 559 | | D | | 560 | | E | | 561 | | ----------------------------> | | 562 | | | | 563 +------+ +------+ 565 Figure 6: Message Between Ingress and Egress 567 The following provides an example of how tunnel congestion level 568 could be calculated: 570 Congestion Level could be divided into two categories:(1)slight 571 congestion(no packets dropped); (2)serious congestion (packet 572 dropping happen). 574 For slight congestion, the congestion level is indicated as the 575 number of CE-marked packet: 577 ce_marked = (A2 + D + E) - A1; 579 For serious congestion, the congestion level is indicated as the 580 number of lost packets: 582 total_ingress = (A1 + B1 + C1) 584 total_egress = (A2 + B2 + C2 + D + E) 586 packet_loss = (total_ingress - total_egress) 588 7. Security Considerations 590 This document describes the tunnel congestion calculation and 591 feedback. 593 The tunnel endpoints are assumed to be deployed in the same 594 administrative domain, so the ingress and egress will trust each 595 other, the signaling traffic between ingress and egress will be 596 protected utilizing security mechanism provided IPFIX (see section 11 597 in RFC7011). 599 From the consideration of privacy point of view, in case of fine 600 grained congestion management, ingress is aware of the amount of 601 traffic for specific application flows inside the tunnel which seems 602 to be an invasion of privacy. But in any way, the ingress could The 603 solution doesn't introduce more privacy problem. 605 8. IANA Considerations 607 This document defines a set of new IPFIX Information Elements 608 (IE),which need to be registered at IANA IPFIX Information Element 609 Registry. 611 ElementID: TBD1 612 Name:tunnelEcnCeCePacketTotalCount 613 Data Type: unsigned64 614 Data Type Semantics: totalCounter 615 Status: current 616 Description:The total number of incoming packets with CE|CE ECN 617 marking combination for this Flow at the Observation Point since the 618 Metering Process (re-)initialization for this Observation Point. 619 Units: packets 621 ElementID: TBD2 622 Name:tunnelEcnEct0NectPacketTotalCount 623 Data Type: unsigned64 624 Data Type Semantics: totalCounter 625 Status: current 626 Description:The total number of incoming packets with ECT(0)|N-ECT 627 ECN marking combination for this Flow at the Observation Point since 628 the Metering Process (re-)initialization for this Observation Point. 629 Units: packets 631 ElementID: TBD3 632 Name: tunnelEcnEct1NectPacketTotalCount 633 Data Type: unsigned64 634 Data Type Semantics: totalCounter 635 Status: current 636 Description:The total number of incoming packets with ECT(1)|N-ECT 637 ECN marking combination for this Flow at the Observation Point since 638 the Metering Process (re-)initialization for this Observation Point. 639 Units: packets 641 ElementID: TBD4 642 Name:tunnelEcnCeNectPacketTotalCount 643 Data Type: unsigned64 644 Data Type Semantics: totalCounter 645 Status: current 646 Description:The total number of incoming packets with CE|N-ECT ECN 647 marking combination for this Flow at the Observation Point since the 648 Metering Process (re-)initialization for this Observation Point. 649 Units: packets 651 ElementID: TBD5 652 Name:tunnelEcnCeEct0PacketTotalCount 653 Data Type: unsigned64 654 Data Type Semantics: totalCounter 655 Status: current 656 Description:The total number of incoming packets with CE|ECT(0) ECN 657 marking combination for this Flow at the Observation Point since the 658 Metering Process (re-)initialization for this Observation Point. 659 Units: packets 661 ElementID: TBD6 662 Name:tunnelEcnCeEct1PacketTotalCount 663 Data Type: unsigned64 664 Data Type Semantics: totalCounter 665 Status: current 666 Description:The total number of incoming packets with CE|ECT(1) ECN 667 marking combination for this Flow at the Observation Point since the 668 Metering Process (re-)initialization for this Observation Point. 669 Units: packets 671 ElementID: TBD7 672 Name:tunnelEcnEct0Ect0PacketTotalCount 673 Data Type: unsigned64 674 Data Type Semantics: totalCounter 675 Status: current 676 Description:The total number of incoming packets with ECT(0)|ECT(0) 677 ECN marking combination for this Flow at the Observation Point since 678 the Metering Process (re-)initialization for this Observation Point. 679 Units: packets 681 ElementID: TBD8 682 Name:tunnelEcnEct1Ect1PacketTotalCount 683 Data Type: unsigned64 684 Data Type Semantics: totalCounter 685 Status: current 686 Description:The total number of incoming packets with 687 ECT(1)|ECT(1)ECN marking combination for this Flow at the Observation 688 Point since the Metering Process (re-)initialization for this 689 Observation Point. 690 Units: packets 692 [TO BE REMOVED: This registration should take place at the following 693 location: http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix- 694 information-elements] 696 9. References 698 9.1 Normative References 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997, 702 . 704 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 705 of Explicit Congestion Notification (ECN) to IP", 706 RFC 3168, September 2001, . 709 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 710 Jacobson, "RTP: A Transport Protocol for Real-Time 711 Applications", STD 64, RFC 3550, July 2003, 712 . 714 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 715 Conrad, "Stream Control Transmission Protocol (SCTP) 716 Partial Reliability Extension", RFC 3758, May 2004, 717 . 719 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 720 Congestion Control Protocol (DCCP)", RFC 4340, March 2006, 721 . 723 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 724 RFC 4960, September 2007, . 727 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 728 Notification", RFC 6040, November 2010, . 731 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 732 "Specification of the IP Flow Information Export (IPFIX) 733 Protocol for the Exchange of Flow Information", STD 77, 734 RFC 7011, September 2013, . 737 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 738 Reviewers of IP Flow Information Export (IPFIX) 739 Information Elements", BCP 184, RFC 7013, September 2013, 740 . 742 [CONEX] Matt Mathis, Bob Briscoe. "Congestion Exposure (ConEx) 743 Concepts, Abstract Mechanism and Requirements", RFC7713, 744 December 2015 746 9.2 Informative References 748 [CB] G. Fairhurst. "Network Transport Circuit Breakers", draft-ietf- 749 tsvwg-circuit-breaker-01, April 02, 2015 751 10. Acknowledgements 753 Thanks Bob Briscoe for his insightful suggestions on the basic 754 mechanisms of congestion information collection and many other useful 755 comments. Thanks David Black for his useful technical suggestions. 757 Also, thanks Anthony Chan, Jake Holland, John Kaippallimalil and 758 Vincent Roca for their careful reviews. 760 Authors' Addresses 762 Xinpeng Wei 763 Beiqing Rd. Z-park No.156, Haidian District, 764 Beijing, 100095, P. R. China 765 E-mail: weixinpeng@huawei.com 767 Zhu Lei 768 Beiqing Rd. Z-park No.156, Haidian District, 769 Beijing, 100095, P. R. China 770 E-mail:lei.zhu@huawei.com 772 Lingli Deng 773 Beijing, 100095, P. R. China 774 E-mail: denglingli@gmail.com