idnits 2.17.1 draft-ietf-trill-ecn-support-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 -- The document date (November 20, 2017) is 2342 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Bob Briscoe 4 CableLabs 5 Expires: May 19, 2018 November 20, 2017 7 TRILL: ECN (Explicit Congestion Notification) Support 8 10 Abstract 12 Explicit congestion notification (ECN) allows a forwarding element to 13 notify downstream devices, including the destination, of the onset of 14 congestion without having to drop packets. This can improve network 15 efficiency through better flow control without packet drops. This 16 document extends ECN to TRILL switches, including integration with IP 17 ECN, and provides for ECN marking in the TRILL Header Extension Flags 18 Word (see RFC 7179). 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the TRILL working group mailing list . 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Conventions used in this document......................4 48 2. The ECN Specific Extended Header Flags..................6 50 3. ECN Support.............................................7 51 3.1 Ingress ECN Support....................................7 52 3.2 Transit ECN Support....................................7 53 3.3 Egress ECN Support.....................................8 55 4. TRILL Support for ECN Variants.........................10 56 4.1 Pre-Congestion Notification (PCN).....................10 57 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......11 59 5. IANA Considerations....................................12 60 6. Security Considerations................................13 62 7. Acknowledgements.......................................13 64 Normative References......................................14 65 Informative References....................................15 67 Appendix A. TRILL Transit RBridge Behavior to Support L4S.16 69 Authors' Addresses........................................18 71 1. Introduction 73 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 74 element, such as a router, to notify downstream devices, including 75 the destination, of the onset of congestion without having to drop 76 packets. This can improve network efficiency through better flow 77 control without packet drops. The forwarding element can explicitly 78 mark a proportion of packets in an ECN field instead of dropping the 79 packet. For example, a two-bit field is available for ECN marking in 80 IP headers. 82 ............................. 83 . . 84 +---------+ . 85 +------+ | Ingress | . 86 |Source| +->| RBridge | . +----------+ 87 +---+--+ | | RB1 | . |Forwarding| 88 | | +------+--+ +----------+ . | Element | 89 v | . | | Transit | . | Y | 90 +-------+--+ . +---->| RBridges | . +--------+-+ 91 |Forwarding| . | RBn | . ^ | 92 | Element | . +-------+--+ +---------+ | v 93 | X | . | | Egress | | +-----------+ 94 +----------+ . +---->| RBridge +-+ |Destination| 95 . | RB9 | +-----------+ 96 . TRILL +---------+ 97 . campus . 98 ............................. 100 Figure 1. Example Path Forwarding Nodes 102 In [RFC3168] it was recognized that tunnels and lower layer protocols 103 would need to support ECN, and ECN markings would need to be 104 propagated, as headers were encapsulated and decapsulated. 105 [ECNencapGuide] gives guidelines on the addition of ECN to protocols 106 like TRILL that often encapsulate IP packets, including propagation 107 of ECN from and to IP. 109 In the figure above, assuming IP traffic, RB1 is an encapsulator and 110 RB9 a decapsulator. Traffic from Source to RB1 might or might not get 111 marked as having experienced congestion in forwarding elements, such 112 as X, before being encapsulated at ingress RB1. Any such ECN marking 113 is encapsulated with a TRILL Header [RFC6325]. 115 This specification provides for any ECN marking in the traffic at the 116 ingress to be copied into the TRILL Extension Header Flags Word. It 117 also enables congestion marking by a congested RBridge such as RBn or 118 RB1 above in the TRILL Header Extension Flags Word [RFC7179]. 120 At RB9, the TRILL egress, it specifies how any ECN markings in the 121 TRILL Header Flags Word and in the encapsulated traffic are combined 122 so that subsequent forwarding elements, such as Y and the 123 Destination, can see if congestion was experienced at any previous 124 point in the path from Source. 126 A large part of the guidelines for adding ECN to lower layer 127 protocols [ECNencapGuide] concerns safe propagation of congestion 128 notifications in scenarios where some of the nodes do not support or 129 understand ECN. Such ECN ignorance is not a major problem with 130 RBridges using this specification because the method specified 131 assures that, if an egress RBridge is ECN ignorant (so it cannot 132 further propagate ECN) and congestion has been encountered, the 133 egress RBridge will at least drop the packet and this drop will 134 itself indicate congestion to end stations. 136 1.1 Conventions used in this document 138 The terminology and acronyms defined in [RFC6325] are used herein 139 with the same meaning. 141 In this documents, "IP" refers to both IPv4 and IPv6. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119] [RFC8174] 146 when, and only when, they appear in all capitals, as shown here. 148 Acronyms: 150 AQM - Active Queue Management 152 CCE - Critical Congestion Experienced 154 CE - Congestion Experienced 156 CItE - Critical Ingress-to-Egress 158 ECN - Explicit Congestion Notification 160 ECT - ECN Capable Transport 162 L4S - Low Latency, Low Loss, Scalable throughput 164 NCHbH - Non-Critical Hop-by-Hop 166 NCCE - Non-Critical Congestion Experienced 167 Not-ECT - Not ECN-Capable Transport 169 PCN - Pre-Congestion Notification 171 2. The ECN Specific Extended Header Flags 173 The extension header fields for explicit congestion notification 174 (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit 175 Critical Congestion Experienced (CCE) field in the 32-bit TRILL 176 Header Extension Flags Word [RFC7780]. 178 These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN 179 field consists of bits 12 and 13, which are in the range reserved for 180 non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 181 26, which is in the range reserved for Critical Ingress-to-Egress 182 (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary 183 bit and will be one if and only if any of the bits in the CItE range 184 (21-26) is one or there is a critical feature invoked in some further 185 extension of the TRILL Header after the Extesnion Flags Word. The 186 other bits and fields shown in Figure 2 are not relevant to ECN. See 187 [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these 188 other bits and fields. 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 194 |.....|.........|...........|.....|.......|...........|.........| 195 |C|C|C| |C|N| | | | | | | | | 196 |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | 197 |H|I|R| |C|C| | | Hop | | |C|Clr| | 198 |b|t|s| |A|A| | | Cnt | | |E| | | 199 |H|E|v| |F|F| | | | | | | | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2 The ECN and CCE TRILL Header Extension Flags Word Fields 204 Table 1 shows the meaning of the codepoints in the TRILL-ECN field. 205 The first three have the same meaning as the corresponding ECN field 206 codepoints in the IPv4 or IPv6 header as defined in [RFC3168]. 207 However codepoint 0b11 is called Non-Critical Congestion Experienced 208 (NCCE) to distinguish it from Congestion Experienced in IP. 210 Binary Name Meaning 211 ------ ------- ----------------------------------- 212 00 Not-ECT Not ECN-Capable Transport 213 01 ECT(1) ECN-Capable Transport (1) 214 10 ECT(0) ECN-Capable Transport (0) 215 11 NCCE Non-Critical Congestion Experienced 217 Table 1. TRILL-ECN Field Codepoints 219 3. ECN Support 221 The subsections below describe the required behavior to support ECN 222 at TRILL ingress, transit, and egress. The ingress behavior occurs as 223 a native frame is encapsulated with a TRILL Header to produce a TRILL 224 Data packet. The transit behavior occurs in all RBridges where TRILL 225 Data packets are queued, usually at the output port. The egress 226 behavior occurs where a TRILL Data packet is decapsulated and output 227 as a native frame through an RBridge port. 229 An RBridge that supports ECN MUST behave as described in the relevant 230 subsections below, which correspond to the recommended provisions of 231 [ECNencapGuide]. Nonetheless, the scheme is designed to safely 232 propagate some form of congestion notification even if some RBridges 233 in the path followed by a TRILL Data packet support ECN and others do 234 not. 236 3.1 Ingress ECN Support 238 The behavior at an ingress RBridge is as follows: 240 o When encapsulating an IP frame, the ingress RBridge MUST: 242 + set the F flag in the main TRILL header [RFC7780]; 243 + create a Flags Word as part of the TRILL Header; 244 + copy the two ECN bits from the IP header into the TRILL-ECN 245 field (Flags Word bits 12 and 13) 246 + ensure the CCE flag is set to zero (Flags Word bit 26). 248 o When encapsulating a frame for a non-IP protocol, where that 249 protocol has a means of indicating ECN that is understood by the 250 ingress RBridge, it MUST follow the guidelines in [ECNencapGuide] 251 to add a Flags Word to the TRILL Header. For a non-IP protocol 252 with a similar ECN field to IP, this would be achieved by copying 253 into the TRILL-ECN field from the encapsulated native frame. 255 3.2 Transit ECN Support 257 The transit behavior, shown below, is required at all RBridges where 258 TRILL Data packets are queued, usually at the output port. 260 o An RBridge that supports ECN MUST implement some form of active 261 queue management (AQM) according to the guidelines of [RFC7567]. 262 The RBridge detects congestion either by monitoring its own queue 263 depth or by participating in a link-specific protocol. 265 o If the TRILL Header Flags Word is present, whenever the AQM 266 algorithm decides to indicate congestion on a TRILL Data packet it 267 MUST set the CCE flag (Flags Word bit 26). 269 o If the TRILL header Flags Word is not present, to indicate 270 congestion the RBridge will either drop the packet or it MAY do 271 all of the following instead: 273 + set the F flag in the main TRILL header; 274 + add a Flags Word to the TRILL Header; 275 + set the TRILL-ECN field to Not-ECT (00); 276 + and set the CCE flag and the Ingress-to-Egress critical summary 277 bit (CRIbE). 279 Note that a transit RBridge that supports ECN does not refer to the 280 TRILL-ECN field before signalling CCE in a packet. It signals CCE 281 irrespective of whether the packet indicates that the transport is 282 ECN-capable. The egress/decapsulation behavior (described next) 283 ensures that a CCE indication is converted to a drop if the transport 284 is not ECN-capable. 286 3.3 Egress ECN Support 288 If the egress RBridge does not support ECN, that RBridge will ignore 289 bits 12 and 13 of any Flags Word that is present, because it does not 290 contain any special ECN logic. Nonetheless, if a transit RBridge has 291 set the CCE flag, the egress will drop the packet. This is because 292 drop is the default behavior for an RBridge decapsulating a Critical 293 Ingress-to-Egress flag when it has no specific logic to understand 294 it. Drop is the intended behavior for such a packet, as required by 295 [ECNencapGuide]. 297 If an RBridge supports ECN, the egress behavior is as follows: 299 o When decapsulating an inner IP packet, the RBridge sets the ECN 300 field of the outgoing native IP packet using Table 2. It MUST set 301 the ECN field of the outgoing IP packet to the codepoint at the 302 intersection of the row for the arriving encapsulated IP packet 303 and the column for 3-bit ECN codepoint in the arriving outer TRILL 304 Data packet TRILL Header. If no TRILL Header Extension Flags Word 305 is present, the 3-bit ECN codepoint is assumed to be all zero 306 bits. 307 The name of the TRILL 3-bit ECN codepoint is defined using the 308 combination of the TRILL-ECN and CCE fields in Table 3. 309 Specifically, the TRILL 3-bit ECN codepoint is called CE if either 310 NCCE or CCE is set in the TRILL Header Extension Flags Word. 311 Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. 312 In the case where the TRILL 3-bit ECN codepoint indicates 314 congestion experienced (CE) but the encapsulated native IP frame 315 indicates a not ECN-capable transport (Not-ECT), the RBridge MUST 316 drop the packet. Such packet dropping is necessary because a 317 transport above the IP layer that is not ECN-capable will have no 318 ECN logic, so it will only understand dropped packets as an 319 indication of congestion. 321 o When decapsulating a non-IP protocol frame with a means of 322 indicating ECN that is understood by the RBridge, it MUST follow 323 the guideines in [ECNencapGuide] when setting the ECN information 324 in the decapsulated native frame. For a non-IP protocol with a 325 similar ECN field to IP, this would be achieved by combining the 326 information in the TRILL Header Flags Word with the encapsulated 327 non-IP native frame, as specified in Table 2. 329 +---------+----------------------------------------------+ 330 | Inner | Arriving TRILL 3-bit ECN Codepoint Name | 331 | Native +---------+------------+------------+----------+ 332 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 333 +---------+---------+------------+------------+----------+ 334 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | 335 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 336 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 337 | CE | CE | CE | CE(*) | CE | 338 +---------+---------+------------+------------+----------+ 340 Table 2: Egress ECN Behavior 342 An asterisk in the above table indicates a currently unused 343 combination that SHOULD be logged. In contrast to [RFC6040], in TRILL 344 the drop condition is the result of a valid combination of events and 345 need not be logged. 347 +------------+-----+---------------------+ 348 | TRILL-ECN | CCE | Arriving TRILL 3-bit| 349 | | | ECN codepoint name | 350 +------------+-----+---------------------+ 351 | Not-ECT 00 | 0 | Not-ECT | 352 | ECT(1) 01 | 0 | ECT(1) | 353 | ECT(0) 10 | 0 | ECT(0) | 354 | NCCE 11 | 0 | CE | 355 | Not-ECT 00 | 1 | CE | 356 | ECT(1) 01 | 1 | CE | 357 | ECT(0) 10 | 1 | CE | 358 | NCCE 11 | 1 | CE | 359 +------------+-----+---------------------+ 361 Table 3: Mapping of TRILL-ECN and CCE Fields to TRILL 3-bit ECN 362 Codepoint Name 364 4. TRILL Support for ECN Variants 366 This section is informative, not normative. 368 Section 3 specifies interworking between TRILL and the original 369 standardized form of ECN in IP [RFC3168]. 371 The ECN wire protocol for TRILL (Section 2) has been designed to 372 support the other known variants of ECN, as detailed below. New 373 variants of ECN will have to comply with the guidelines for defining 374 alternative ECN semantics [RFC4774]. It is expected that the TRILL 375 ECN wire protocol is generic enough to support such potential future 376 variants. 378 4.1 Pre-Congestion Notification (PCN) 380 The PCN wire protocol [RFC6660] is recognised by the use of a PCN- 381 compatible Diffserv codepoint in the IP header and a non-zero IP-ECN 382 field. For TRILL or any lower layer protocol, equivalent traffic 383 classification codepoints would have to be defined, but that is 384 outside the scope of the current document. 386 The PCN wire protocol is similar to ECN, except it indicates 387 congestion with two levels of severity. It uses: 389 o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) 390 codepoint 392 o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked 393 (ThM) codepoint. (This difference between ECT(1) and ECT(0) only 394 applies to PCN, not to the classic ECN support specified for TRILL 395 in this document before Section 4.) 397 To implement PCN on a transit RBridge would require a detailed 398 specification. But in brief: 400 o the TRILL Critical Congestion Experienced (CCE) flag would be used 401 for the Excess-Traffic-Marked (ETM) codepoint; 403 o ECT(1) in the TRILL-ECN field would be used for the Threshold- 404 Marked codepoint. 406 Then the ingress and egress behaviors defined in Section 3 would not 407 need to be altered to ensure support for PCN as well as ECN. 409 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) 411 L4S is currently on the IETF's experimental track. An outline of how 412 a transit TRILL RBridge would support L4S [ECNL4S] is given in 413 Appendix A. 415 5. IANA Considerations 417 IANA is requested to update the TRILL Extended Header Flags registry 418 by replacing the lines for bits 9-13 and for bits 21-26 with the 419 following: 421 Bits Purpose Reference 422 ----- ------- --------- 423 9-11 available non-critical hop-by-hop flags 424 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 426 21-25 available critical ingress-to-egress flags 427 26 Critical Congestion Experienced (CCE) [this doc] 429 6. Security Considerations 431 TRILL support of ECN is a straight forward combination of previously 432 specified ECN and TRILL with no significnat new security 433 considerations. 435 For ECN tunneling security considerations, see [RFC6040]. 437 For general TRILL protocol security considerations, see [RFC6325]. 439 7. Acknowledgements 441 The helpful comments of Loa Andersson are hereby acknowledged. 443 This document was prepared with basic NROFF. All macros used were 444 defined in the source file. 446 Normative References 448 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 450 March 1997, . 452 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 453 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 454 10.17487/RFC3168, September 2001, . 457 [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the 458 Explicit Congestion Notification (ECN) Field", BCP 124, RFC 459 4774, DOI 10.17487/RFC4774, November 2006, . 462 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 463 Ghanwani, "Routing Bridges (RBridges): Base Protocol 464 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 465 . 467 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 468 C. Bestler, "Transparent Interconnection of Lots of Links 469 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 470 2014, . 472 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 473 Recommendations Regarding Active Queue Management", BCP 197, 474 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 477 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 478 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 479 Lots of Links (TRILL): Clarifications, Corrections, and 480 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 481 . 483 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 485 2017, 487 [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, 488 "Guidelines for Adding Congestion Notification to Protocols 489 that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, 490 work in progress. 492 Informative References 494 [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit 495 Congestion Notification (ECN) Semantics for Ultra-Low Queueing 496 Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. 498 [IANAthFlags] - IANA TRILL Extended Header word flags: 499 http://www.iana.org/assignments/trill-parameters/trill- 500 parameters.xhtml#extended-header-flags 502 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 503 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 504 . 506 [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 507 Pre-Congestion Notification (PCN) States in the IP Header Using 508 a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 509 10.17487/RFC6660, July 2012, . 512 Appendix A. TRILL Transit RBridge Behavior to Support L4S 514 The specification of the Low Latency, Low Loss, Scalable throughput 515 (L4S) wire protocol for IP is given in [ECNL4S]. It is similar to the 516 original ECN wire protoocl for IP [RFC3168], except: 518 o An AQM that supports L4S classifies packets with ECT(1) or CE in 519 the IP header into an L4S queue and a "Classic" queue otherwise. 521 o the meaning of CE markings applied by an L4S queue is not the same 522 as the meaning of a drop by a "Classic" queue (contrary to the 523 original requirement for ECN [RFC3168]). Instead the likelihood 524 that the Classic queue drops packets is defined as the square of 525 the likelihood that the L4S queue marks packets (e.g. when there 526 is a drop probability of 0.0009 (0.09%) the L4S marking 527 probability will be 0.03 (3%)). 529 This seems to present a problem for the way that a transit TRILL 530 RBridge defers the choice between marking and dropping to the egress. 531 Nonetheless, the following pseudocode outlines how a transit TRILL 532 RBridge can implement L4S marking in such a way that the egress 533 behavior already described in Section 3.3 for Classic ECN [RFC3168] 534 will produce the desired outcome. 536 /* p is an internal variable calculated by any L4S AQM 537 * dependent on the delay being experienced in the Classic queue. 538 * bit13 is the least significant bit of the TRILL-ECN field 539 */ 541 % On TRILL transit 542 if (bit13 == 0 ) { 543 % Classic Queue 544 if (p > max(random(), random()) ) 545 mark(CCE) % likelihood: p^2 547 } else { 548 % L4S Queue 549 if (p > random() ) { 550 if (p > random() ) 551 mark(CCE) % likelihood: p^2 552 else 553 mark(NCCE) % likelihood: p - p^2 554 } 555 } 557 With the above transit behavior, an egress that supports ECN (Section 558 3.3) will drop packets or propagate their ECN markings depending on 559 whether the arriving inner header is from a non-ECN-capable or ECN- 560 capable transport. 562 Even if an egress has no L4S-specific logic of its own, it will drop 563 packets with the square of the probability that an egress would if it 564 did support ECN, for the following reasons: 566 o Egress with ECN support: 568 + L4S: propagates both the Critical and Non-Critical CE marks 569 (CCE & NCCE) as a CE mark. 571 Likelihood: p^2 + p - p^2 = p 573 + Classic: Propagates CCE marks as CE or drop, depending on 574 inner. 576 Likelihood: p^2 578 o Egress without ECN support: 580 + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. 582 Likelihood: p^2 584 + Classic: drops CCE marks. 586 Likelihood: p^2 588 Authors' Addresses 590 Donald E. Eastlake, 3rd 591 Huawei Technologies 592 155 Beaver Street 593 Milford, MA 01757 USA 595 Tel: +1-508-333-2270 596 Email: d3e3e3@gmail.com 598 Bob Briscoe 599 CableLabs 600 UK 602 Email: ietf@bobbriscoe.net 603 URI: http://bobbriscoe.net/ 605 Copyright and IPR Provisions 607 Copyright (c) 2017 IETF Trust and the persons identified as the 608 document authors. All rights reserved. 610 This document is subject to BCP 78 and the IETF Trust's Legal 611 Provisions Relating to IETF Documents 612 (http://trustee.ietf.org/license-info) in effect on the date of 613 publication of this document. Please review these documents 614 carefully, as they describe your rights and restrictions with respect 615 to this document. Code Components extracted from this document must 616 include Simplified BSD License text as described in Section 4.e of 617 the Trust Legal Provisions and are provided without warranty as 618 described in the Simplified BSD License. The definitive version of 619 an IETF Document is that published by, or under the auspices of, the 620 IETF. Versions of IETF Documents that are published by third parties, 621 including those that are translated into other languages, should not 622 be considered to be definitive versions of IETF Documents. The 623 definitive version of these Legal Provisions is that published by, or 624 under the auspices of, the IETF. Versions of these Legal Provisions 625 that are published by third parties, including those that are 626 translated into other languages, should not be considered to be 627 definitive versions of these Legal Provisions. For the avoidance of 628 doubt, each Contributor to the IETF Standards Process licenses each 629 Contribution that he or she makes as part of the IETF Standards 630 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 631 language to the contrary, or terms, conditions or rights that differ 632 from or are inconsistent with the rights and licenses granted under 633 RFC 5378, shall have any effect and shall be null and void, whether 634 published or posted by such Contributor, or included with or in such 635 Contribution.