idnits 2.17.1 draft-ietf-tsvwg-tunnel-congestion-feedback-06.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 109 has weird spacing: '...plement conge...' == Line 320 has weird spacing: '... should be th...' -- The document date (December 4, 2017) is 2334 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 86, but not defined == Missing Reference: 'RFC793' is mentioned on line 90, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC6040' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'CONEX' is defined on line 776, 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 (~~), 8 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: June 7, 2018 Huawei Technologies 6 L.Deng 7 China Mobile 8 December 4, 2017 10 Tunnel Congestion Feedback 11 draft-ietf-tsvwg-tunnel-congestion-feedback-06 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 . . . . . . . . . . . . 4 62 4. Congestion Level Measurement . . . . . . . . . . . . . . . . . 5 63 5. Congestion Information Delivery . . . . . . . . . . . . . . . . 7 64 5.1 IPFIX Extensions . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1.1 tunnelEcnCeCeByteTotalCount . . . . . . . . . . . . . . 8 66 5.1.2 tunnelEcnEct0NectBytetTotalCount . . . . . . . . . . . . 8 67 5.1.3 tunnelEcnEct1NectByteTotalCount . . . . . . . . . . . . 9 68 5.1.4 tunnelEcnCeNectByteTotalCount . . . . . . . . . . . . . 9 69 5.1.5 tunnelEcnCeEct0ByteTotalCount . . . . . . . . . . . . . 9 70 5.1.6 tunnelEcnCeEct1ByteTotalCount . . . . . . . . . . . . . 10 71 5.1.7 tunnelEcnEct0Ect0ByteTotalCount . . . . . . . . . . . . 10 72 5.1.8 tunnelEcnEct1Ect1PacketTotalCount . . . . . . . . . . . 10 73 5.1.9 tunnelEcnCEMarkedRatio . . . . . . . . . . . . . . . . . 11 74 6. Congestion Management . . . . . . . . . . . . . . . . . . . . . 11 75 6.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 80 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 In IP networks, persistent congestion[RFC2914] lowers transport 87 throughput, leading to waste of network resource. Appropriate 88 congestion control mechanisms are therefore critical to prevent the 89 network from falling into the persistent congestion state. Currently, 90 transport protocols such as TCP[RFC793], SCTP[RFC4960], 91 DCCP[RFC4340], have their built-in congestion control mechanisms, and 92 even for certain single transport protocol like TCP there can be a 93 couple of different congestion control mechanisms to choose from. All 94 these congestion control mechanisms are implemented on host side, and 95 there are reasons that only host side congestion control is not 96 sufficient for the whole network to keep away from persistent 97 congestion. For example, (1) some protocol's congestion control 98 scheme may have internal design flaws; (2) improper software 99 implementation of protocol; (3) some transport protocols, e.g. 100 RTP[RFC3550] do not even provide congestion control at all; (4)a 101 heavy load from a much larger than expected number of responsive 102 flows could also lead to persistent congestion. 104 Tunnels are widely deployed in various networks including public 105 Internet, data center network, and enterprise network etc. A tunnel 106 consists of ingress, egress and a set of intermediate routers. For 107 the tunnel scenario, a tunnel-based mechanism is introduced for 108 network traffic control to keep the network from persistent 109 congestion. Here, tunnel ingress will implement congestion 110 management function to control the traffic entering the tunnel. 112 This document provides a mechanism of feeding back inner tunnel 113 congestion level to the ingress. Using this mechanism the egress can 114 feed the tunnel congestion level information it collects back to the 115 ingress. After receiving this information the ingress will be able to 116 perform congestion management according to network management policy. 118 The following subjects are out of scope of current document: it gives 119 no advice on how to select which tunnel endpoints should be used in 120 order to manage traffic over a network criss-crossed by multiple 121 tunnels; if a congested node is part of multiple tunnels, and it 122 causes congestion feedback to multiple traffic management functions 123 at the ingresses of all the tunnels, the draft gives no advice on how 124 all the traffic management functions should respond. 126 2. Conventions And Terminologies 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119] 131 DP: Decision Point, an logical entity that makes congestion 132 management decision based on the received congestion feedback 133 information. 135 EP: Enforcement Point, an logical entity that implements congestion 136 management action according to the decision made by Decision Point. 138 ECT: ECN-Capable Transport code point defined in RFC3168. 140 3. Congestion Information Feedback Models 142 The feedback model mainly consists of tunnel egress and tunnel 143 ingress. The tunnel egress composes of meter function and exporter 144 function; tunnel ingress composes EP (Enforcement Point) function, 145 collector function and DP (Decision Point) function. 147 The Meter function collects network congestion level information, and 148 conveys the information to Exporter which feeds back the information 149 to the collector function. 151 The feedback message contains CE-marked packet ratio, the traffic 152 volumes of all kinds of ECN marking packets. 154 The collector collects congestion level information from exporter, 155 after that congestion management Decision Point (DP) function will 156 make congestion management decision based on the information from 157 collector. 159 The Enforcement Point controls the traffic entering tunnel, and it 160 implements traffic control decision of DP. 162 Feedback 163 +-----------------------------------+ 164 | | 165 | | 166 | V 167 +--------------+ +-------------+ 168 | +--------+ | | +---------+ | 169 | |Exporter| | | |Collector| | 170 | +---|----+ | | +---|-----+ | 171 | +--|--+ | | +|-+ | 172 | |Meter| | traffic | |DP| | 173 | +-----+ |<==================| +--+ | 174 | | | +--+ | 175 | | | |EP| | 176 | | | +--+ | 177 |Egress | | Ingress | 178 +--------------+ +-------------+ 179 Figure 1: Feedback Model. 181 4. Congestion Level Measurement 183 The congestion level measurement is based on ECN (Explicit 184 Congestion Notification) [RFC3168] and packet drop. The network 185 congestion level could be indicated through the ratio of CE-marked 186 packet and the volumes of packet drop, the relationship between 187 these two kinds of indicator is complementary. If the congestion 188 level in tunnel is not high enough, the packets would be marked as 189 CE instead of being dropped, and then it is easy to calculate 190 congestion level according to the ratio of CE-marked packets. If 191 the congestion level is so high that ECT packet will be dropped, 192 then the packet loss ratio could be calculated by comparing total 193 packets entering ingress and total packets arriving at egress over 194 the same span of packets, if packet loss is detected, it could be 195 assumed that severe congestion has occurred in the tunnel. 197 Egress calculates CE-marked packet ratio by counting different 198 kinds of ECN-marked packet, the CE-marked packet ratio will be 199 used as an indication of tunnel load level. It's assumed that 200 routers in the tunnel will not drop packets biased towards certain 201 ECN codepoint, so calculating of CE-marked packet ratio is not 202 affect by packet drop. 204 The calculation of volumes of packet drop is by comparing the 205 traffic volumes between ingress and egress. 207 Faked ECN-capable transport (ECT) is used at ingress to defer 208 packet loss to egress. The basic idea of faked ECT is that, when 209 encapsulating packets, ingress first marks tunnel outer header 210 according to RFC6040, and then remarks outer header of Not-ECT 211 packet as ECT, there will be three kinds of combination of outer 212 header ECN field and inner header ECN field: CE|CE, ECT|N-ECT, 213 ECT|ECT (in the form of outer ECN| inner ECN); when decapsulating 214 packets at egress, RFC6040 defined decapsulation behavior is used, 215 and according to RFC6040, the packets marked as CE|N-ECT will be 216 dropped by egress. Faked-ECT is used to shift some drops to the 217 egress in order to calculate CE-marked packet ratio more precisely 218 by egress. 220 To calculate congestion level, for the same span of packets, the 221 ratio of CE-marked packets will be calculated by egress, and the 222 total bytes count of packets at ingress and egress will be 223 compared to detect the traffic volume loss in tunnel. 225 The basic procedure of packets loss measurement is as follows: 227 +-------+ +------+ 228 |Ingress| |Egress| 229 +-------+ +------+ 230 | | 231 +----------------+ | 232 |cumulative count| | 233 +----------------+ | 234 | | 235 | | 236 |------------------------>| 237 | | 238 |<------------------------| 239 | | 240 | | 242 Figure 2: Procedure of Packet Loss Measurement 244 Ingress encapsulates packets and marks outer header according to 245 faked ECT as described above. Ingress cumulatively counts packet 246 bytes for three types of ECN combination (CE|CE, ECT|N-ECT, ECT|ECT) 247 and then the ingress regularly sends cumulative bytes counts message 248 of each type of ECN combination to the egress. 250 When each message arrives at egress, (1)egress calculates the ratio 251 of CE-marked packet; (2)the egress cumulatively counts packet bytes 252 coming from the ingress and adds its own bytes counts of each type of 253 ECN combination (CE|CE, ECT|N-ECT, CE|N-ECT, CE|ECT, ECT|ECT) to the 254 message for ingress to calculate packet loss. Egress feeds back CE- 255 marked packet ratio and bytes counts information to the ingress for 256 evaluating congestion level in the tunnel. 258 The counting of bytes can be at the granularity of the all traffic 259 from the ingress to the egress to learn about the overall congestion 260 status of the path between the ingress and the egress. The counting 261 can also be at the granularity of individual customer's traffic or a 262 specific set of flows to learn about their congestion contribution. 264 5. Congestion Information Delivery 266 As described above, the tunnel ingress needs to convey a message 267 containing cumulative bytes counts of packets of each type of ECN 268 combination to tunnel egress, and the tunnel egress also needs to 269 feed back the message of cumulative bytes counts of packets of each 270 type of ECN combination and CE-marked packet ratio to the ingress. 271 This section describes how the messages should be conveyed. 273 The message travels along the same path with network data traffic, 274 referred as in-band signal. Because the message is transmitted in 275 band, so the message packet may get lost in case of network 276 congestion. To cope with the situation that the message packet gets 277 lost, the bytes counts values are sent as cumulative counters. Then 278 if a message is lost the next message will recover the missing 279 information. Even though the missing information could be recovered, 280 the message should be transmitted in a much higher priority than 281 users' traffic flows. 283 IPFIX [RFC7011] is selected as a candidate information feedback 284 protocol. IPFIX uses preferably SCTP as transport. SCTP allows 285 partially reliable delivery [RFC3758], which ensures the feedback 286 message will not be blocked in case of packet loss due to network 287 congestion. 289 Ingress can do congestion management at different granularity which 290 means both the overall aggregated inner tunnel congestion level and 291 congestion level contributed by certain traffic(s) could be measured 292 for different congestion management purpose. For example, if the 293 ingress only wants to limit congestion volume caused by certain 294 traffic(s),e.g UDP-based traffic, then congestion volume for the 295 traffic will be fed back; or if the ingress do overall congestion 296 management, the aggregated congestion volume will be fed back. 298 When sending message from ingress to egress, the ingress acts as 299 IPFIX exporter and egress acts as IPFIX collector; When feedback 300 congestion level information from egress to ingress, then the egress 301 acts as IPFIX exporter and ingress acts as IPFIX collector. 303 The combination of congestion level measurement and congestion 304 information delivery procedure should be as following: 306 # The ingress determines IPFIX template record to be used. The 307 template record can be pre-configured or determined at runtime, the 308 content of template record will be determined according to the 309 granularity of congestion management, if the ingress wants to limit 310 congestion volume contributed by specific traffic flow then the 311 elements such as source IP address, destination IP address, flow id 312 and CE-marked packet volume of the flow etc will be included in the 313 template record. 315 # Meter on ingress measures traffic volume according to template 316 record chosen and then the measurement records are sent to egress in 317 band. 319 # Meter on egress measures congestion level information according to 320 template record, the content of template record should be the same 321 as template record of ingress. 323 # Exporter of egress sends measurement record together with the 324 measurement record of ingress back to the ingress. 326 5.1 IPFIX Extensions 328 This sub-section defines a list of new IPFIX Information Elements 329 according to RFC7013 [RFC7013]. 331 5.1.1 tunnelEcnCeCeByteTotalCount 333 Description: The total number of bytes of incoming packets with CE|CE 334 ECN marking combination at the Observation Point since the Metering 335 Process (re-)initialization for this Observation Point. 337 Abstract Data Type: unsigned64 339 Data Type Semantics: totalCounter 341 ElementId: TBD1 343 Statues: current 345 Units: bytes 347 5.1.2 tunnelEcnEct0NectBytetTotalCount 349 Description: The total number of bytes of incoming packets with 350 ECT(0)|N-ECT ECN marking combination 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: TBD2 359 Statues: current 361 Units: bytes 363 5.1.3 tunnelEcnEct1NectByteTotalCount 365 Description: The total number of bytes of incoming packets with 366 ECT(1)|N-ECT ECN marking combination at the Observation Point since 367 the Metering Process (re-)initialization for this Observation Point. 369 Abstract Data Type: unsigned64 371 Data Type Semantics: totalCounter 373 ElementId: TBD3 375 Statues: current 377 Units: bytes 379 5.1.4 tunnelEcnCeNectByteTotalCount 381 Description: The total number of bytes of incoming packets with CE|N- 382 ECT ECN marking combination at the Observation Point since the 383 Metering Process (re-)initialization for this Observation Point. 385 Abstract Data Type: unsigned64 387 Data Type Semantics: totalCounter 389 ElementId: TBD4 391 Statues: current 393 Units: bytes 395 5.1.5 tunnelEcnCeEct0ByteTotalCount 397 Description: The total number of bytes of incoming packets with 398 CE|ECT(0) ECN marking combination at the Observation Point since the 399 Metering Process (re-)initialization for this Observation Point. 401 Abstract Data Type: unsigned64 403 Data Type Semantics: totalCounter 405 ElementId: TBD5 407 Statues: current 409 Units: bytes 411 5.1.6 tunnelEcnCeEct1ByteTotalCount 413 Description: The total number of bytes of incoming packets with 414 CE|ECT(1) ECN marking combination at the Observation Point since the 415 Metering Process (re-)initialization for this Observation Point. 417 Abstract Data Type: unsigned64 419 Data Type Semantics: totalCounter 421 ElementId: TBD6 423 Statues: current 425 Units: bytes 427 5.1.7 tunnelEcnEct0Ect0ByteTotalCount 429 Description: The total number of bytes of incoming packets with 430 ECT(0)|ECT(0) ECN marking combination at the Observation Point since 431 the Metering Process (re-)initialization for this Observation Point. 433 Abstract Data Type: unsigned64 435 Data Type Semantics: totalCounter 437 ElementId: TBD7 439 Statues: current 441 Units: bytes 443 5.1.8 tunnelEcnEct1Ect1PacketTotalCount 445 Description: The total number of bytes of incoming packets with 446 ECT(1)|ECT(1) ECN marking combination at the Observation Point since 447 the Metering Process (re-)initialization for this Observation Point. 449 Abstract Data Type: unsigned64 451 Data Type Semantics: totalCounter 453 ElementId: TBD8 455 Statues: current 457 Units: bytes 459 5.1.9 tunnelEcnCEMarkedRatio 461 Description: The ratio of CE-marked Packet at the Observation Point. 463 Abstract Data Type: float32 465 ElementId: TBD8 467 Statues: current 469 6. Congestion Management 471 After tunnel ingress receives congestion level information, then 472 congestion management actions could be taken based on the 473 information, e.g. if the congestion level is higher than a predefined 474 threshold, then action could be taken to reduce the congestion level. 476 The design of network side congestion management SHOULD take host 477 side e2e congestion control mechanism into consideration, which means 478 the congestion management needs to avoid the impacts on e2e 479 congestion control. For instance, congestion management action must 480 be delayed by more than a worst-case global RTT (e.g. 100ms), 481 otherwise tunnel traffic management will not give normal e2e 482 congestion control enough time to do its job, and the system could go 483 unstable. 485 The detailed description of congestion management is out of scope of 486 this document, as examples, congestion management such as circuit 487 breaker [RFC8084] could be applied. Circuit breaker is an automatic 488 mechanism to estimate congestion, and to terminate flow(s) when 489 persistent congestion is detected to prevent network congestion 490 collapse. 492 6.1 Example 493 This subsection provides an example of how the solution described in 494 this document could work. 496 First of all, IPFIX template records are exchanged between ingress 497 and egress to negotiate the format of data record, the example here 498 is to measure the congestion level for the overall tunnel (caused by 499 all the traffic in tunnel). After the negotiation is finished, 500 ingress sends in-band message to egress, the message contains the 501 number of each kind of ECN-marked packets (i.e. CE|CE, ECT|N-ECT and 502 ECT|ECT) received until the sending of message. 504 After egress receives the message, the egress calculates CE-marked 505 packet ratio and counts number of different kinds of ECN-marking 506 packets received until receiving the message, then the egress sends a 507 feedback message containing the counts together with the information 508 in ingress's message to ingress. 510 Figure 3 to Figure 6 below show the example procedure between ingress 511 and egress. 513 +---------------------------------+----------------------+ 514 |Set ID=2 Length=40 | 515 |---------------------------------|----------------------| 516 |Template ID=256 Field Count =8 | 517 |---------------------------------|----------------------| 518 |tunnelEcnCeCeByteTotalCount Field Length=8 | 519 |---------------------------------|----------------------| 520 |tunnelEcnEctNectByteTotalCount Field Length=8 | 521 |---------------------------------|----------------------| 522 |tunnelEcnEctEctByteTotalCount Field Length=8 | 523 |---------------------------------|----------------------| 524 |tunnelEcnCeCeByteTotalCount Field Length=8 | 525 |---------------------------------|----------------------| 526 |tunnelEcnEctNectByteTotalCount Field Length=8 | 527 |---------------------------------|----------------------| 528 |tunnelEcnEctEctByteTotalCount Field Length=8 | 529 |---------------------------------|----------------------| 530 |tunnelEcnCeNectByteTotalCount Field Length=8 | 531 |---------------------------------|----------------------| 532 |tunnelEcnCeEctByteTotalCount | Field Length=8 | 533 +---------------------------------+----------------------+ 534 |tunnelEcnCEMarkedRatio | Field Length=4 | 535 +---------------------------------+----------------------+ 536 Figure 3: Template Record Sent From Egress to Ingress 538 +---------------------------------+----------------------+ 539 |Set ID=2 Length=28 | 540 |---------------------------------|----------------------| 541 |Template ID=257 Field Count =3 | 542 |---------------------------------|----------------------| 543 |tunnelEcnCeCeByteTotalCount Field Length=8 | 544 |---------------------------------|----------------------| 545 |tunnelEcnEctNectByteTotalCount Field Length=8 | 546 |---------------------------------|----------------------| 547 |tunnelEcnEctEctByteTotalCount Field Length=8 | 548 |---------------------------------|----------------------| 549 Figure 4: Template Record Sent From Ingress to Egress 551 +-------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-------+ 552 | | |M| |P| |P| |P| |M| |P| |P| | | 553 | | +-+ +-+ +-+ +-+ +-+ +-+ +-+ | | 554 | |<---------------------------------------| | 555 | | | | 556 | | | | 557 |egress | +-+ +-+ |ingress| 558 | | |M| |M| | | 559 | | +-+ +-+ | | 560 | |--------------------------------------->| | 561 | | | | 562 | | | | 563 +-------+ +-------+ 565 +-+ 566 |M| : Message Packet 567 +-+ 569 +-+ 570 |P| : User Packet 571 +-+ 573 Figure 5 Traffic flow Between Ingress and Egress 574 Set ID=257, Length=28 575 +------+ A1 +------+ 576 | | B1 | | 577 | | C1 | | 578 | | <----------------------------- | | 579 | | | | 580 | | | | 581 | | SetID=256, Length=72 | | 582 | | A1 | | 583 | | B1 | | 584 |egress| C1 ingress| 585 | | A2 | | 586 | | B2 | | 587 | | C2 | | 588 | | D | | 589 | | E 590 | | R | | 591 | | ----------------------------> | | 592 | | | | 593 +------+ +------+ 595 Figure 6: Message Between Ingress and Egress 597 The following provides an example of how tunnel congestion level 598 could be calculated: 600 Congestion Level could be divided into two categories:(1)slight 601 congestion(no packets dropped); (2)serious congestion (packet 602 dropping happen). 604 For slight congestion, the congestion level is indicated as the ratio 605 of CE-marked packet: 607 ce_marked = R; 609 For serious congestion, the congestion level is indicated as the 610 number of volume loss: 612 total_ingress = (A1 + B1 + C1) 614 total_egress = (A2 + B2 + C2 + D + E) 616 volume_loss = (total_ingress - total_egress) 618 7. Security Considerations 619 This document describes the tunnel congestion calculation and 620 feedback. 622 The tunnel endpoints are assumed to be deployed in the same 623 administrative domain, so the ingress and egress will trust each 624 other, the signaling traffic between ingress and egress will be 625 protected utilizing security mechanism provided IPFIX (see section 11 626 in RFC7011). 628 From the consideration of privacy point of view, in case of fine 629 grained congestion management, ingress is aware of the amount of 630 traffic for specific application flows inside the tunnel which seems 631 to be an invasion of privacy. But in any way, the ingress could The 632 solution doesn't introduce more privacy problem. 634 8. IANA Considerations 636 This document defines a set of new IPFIX Information Elements 637 (IE),which need to be registered at IANA IPFIX Information Element 638 Registry. 640 ElementID: TBD1 641 Name:tunnelEcnCeCePacketTotalCount 642 Data Type: unsigned64 643 Data Type Semantics: totalCounter 644 Status: current 645 Description:The total number of bytes of incoming packets with CE|CE 646 ECN marking combination at the Observation Point since the Metering 647 Process (re-)initialization for this Observation Point. 648 Units: octets 650 ElementID: TBD2 651 Name:tunnelEcnEct0NectPacketTotalCount 652 Data Type: unsigned64 653 Data Type Semantics: totalCounter 654 Status: current 655 Description:The total number of bytes of incoming packets with 656 ECT(0)|N-ECT ECN marking combination at the Observation Point since 657 the Metering Process (re-)initialization for this Observation Point. 658 Units: octets 660 ElementID: TBD3 661 Name: tunnelEcnEct1NectPacketTotalCount 662 Data Type: unsigned64 663 Data Type Semantics: totalCounter 664 Status: current 665 Description:The total number of bytes of incoming packets with 666 ECT(1)|N-ECT ECN marking combination at the Observation Point since 667 the Metering Process (re-)initialization for this Observation Point. 668 Units: octets 670 ElementID: TBD4 671 Name:tunnelEcnCeNectPacketTotalCount 672 Data Type: unsigned64 673 Data Type Semantics: totalCounter 674 Status: current 675 Description:The total number of bytes of incoming packets with CE|N- 676 ECT ECN marking combination at the Observation Point since the 677 Metering Process (re-)initialization for this Observation Point. 678 Units: octets 680 ElementID: TBD5 681 Name:tunnelEcnCeEct0PacketTotalCount 682 Data Type: unsigned64 683 Data Type Semantics: totalCounter 684 Status: current 685 Description:The total number of bytes of incoming packets with 686 CE|ECT(0) ECN marking combination at the Observation Point since the 687 Metering Process (re-)initialization for this Observation Point. 688 Units: octets 690 ElementID: TBD6 691 Name:tunnelEcnCeEct1PacketTotalCount 692 Data Type: unsigned64 693 Data Type Semantics: totalCounter 694 Status: current 695 Description:The total number of bytes of incoming packets with 696 CE|ECT(1) ECN marking combination at the Observation Point since the 697 Metering Process (re-)initialization for this Observation Point. 698 Units: octets 700 ElementID: TBD7 701 Name:tunnelEcnEct0Ect0PacketTotalCount 702 Data Type: unsigned64 703 Data Type Semantics: totalCounter 704 Status: current 705 Description:The total number of bytes of incoming packets with 706 ECT(0)|ECT(0) ECN marking combination at the Observation Point since 707 the Metering Process (re-)initialization for this Observation Point. 708 Units: octets 710 ElementID: TBD8 711 Name:tunnelEcnEct1Ect1PacketTotalCount 712 Data Type: unsigned64 713 Data Type Semantics: totalCounter 714 Status: current 715 Description:The total number of bytes of incoming packets with 716 ECT(1)|ECT(1)ECN marking combination at the Observation Point since 717 the Metering Process (re-)initialization for this Observation Point. 718 Units: octets 720 ElementID: TBD9 721 Name: tunnelEcnCEMarkedRatio 722 Data Type: float32 723 Status: current 724 Description: The ratio of CE-marked Packet at the Observation Point. 726 [TO BE REMOVED: This registration should take place at the following 727 location: http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix- 728 information-elements] 730 9. References 732 9.1 Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997, 736 . 738 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 739 of Explicit Congestion Notification (ECN) to IP", 740 RFC 3168, September 2001, . 743 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 744 Jacobson, "RTP: A Transport Protocol for Real-Time 745 Applications", STD 64, RFC 3550, July 2003, 746 . 748 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 749 Conrad, "Stream Control Transmission Protocol (SCTP) 750 Partial Reliability Extension", RFC 3758, May 2004, 751 . 753 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 754 Congestion Control Protocol (DCCP)", RFC 4340, March 2006, 755 . 757 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 758 RFC 4960, September 2007, . 761 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 762 Notification", RFC 6040, November 2010, . 765 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 766 "Specification of the IP Flow Information Export (IPFIX) 767 Protocol for the Exchange of Flow Information", STD 77, 768 RFC 7011, September 2013, . 771 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 772 Reviewers of IP Flow Information Export (IPFIX) 773 Information Elements", BCP 184, RFC 7013, September 2013, 774 . 776 [CONEX] Matt Mathis, Bob Briscoe. "Congestion Exposure (ConEx) 777 Concepts, Abstract Mechanism and Requirements", RFC7713, 778 December 2015 780 9.2 Informative References 782 [RFC8084] G. Fairhurst. "Network Transport Circuit Breakers", draft- 783 ietf-tsvwg-circuit-breaker-01, April 02, 2015 785 10. Acknowledgements 787 Thanks Bob Briscoe for his insightful suggestions on the basic 788 mechanisms of congestion information collection and many other useful 789 comments. Thanks David Black for his useful technical suggestions. 790 Also, thanks Anthony Chan, Jake Holland, John Kaippallimalil and 791 Vincent Roca for their careful reviews. 793 Authors' Addresses 795 Xinpeng Wei 796 Beiqing Rd. Z-park No.156, Haidian District, 797 Beijing, 100095, P. R. China 798 E-mail: weixinpeng@huawei.com 800 Zhu Lei 801 Beiqing Rd. Z-park No.156, Haidian District, 802 Beijing, 100095, P. R. China 803 E-mail:lei.zhu@huawei.com 804 Lingli Deng 805 Beijing, 100095, P. R. China 806 E-mail: denglingli@gmail.com