idnits 2.17.1 draft-ietf-trill-ecn-support-05.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 (February 4, 2018) is 2273 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: August 3, 2018 February 4, 2018 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 congestion control without packet drops. 16 This document extends ECN to TRILL switches, including integration 17 with IP ECN, and provides for ECN marking in the TRILL Header 18 Extension Flags 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 54 3.3.1 Non-ECN Egress RBridges..............................8 55 3.3.2 ECN Egress RBridges..................................8 57 4. TRILL Support for ECN Variants.........................11 58 4.1 Pre-Congestion Notification (PCN).....................11 59 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 61 5. IANA Considerations....................................13 62 6. Security Considerations................................14 64 7. Acknowledgements.......................................14 66 Normative References......................................15 67 Informative References....................................16 69 Appendix A. TRILL Transit RBridge Behavior to Support L4S.17 71 Authors' Addresses........................................19 73 1. Introduction 75 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 76 element (such as a router) to notify downstream devices, including 77 the destination, of the onset of congestion without having to drop 78 packets. This can improve network efficiency through better 79 congestion control without packet drops. The forwarding element can 80 explicitly mark a proportion of packets in an ECN field instead of 81 dropping the packet. For example, a two-bit field is available for 82 ECN marking in IP headers. 84 ............................. 85 . . 86 +---------+ . 87 +------+ | Ingress | . 88 |Source| +->| RBridge | . +----------+ 89 +---+--+ | | RB1 | . |Forwarding| 90 | | +------+--+ +----------+ . | Element | 91 v | . | | Transit | . | Y | 92 +-------+--+ . +---->| RBridges | . +--------+-+ 93 |Forwarding| . | RBn | . ^ | 94 | Element | . +-------+--+ +---------+ | v 95 | X | . | | Egress | | +-----------+ 96 +----------+ . +---->| RBridge +-+ |Destination| 97 . | RB9 | +-----------+ 98 . TRILL +---------+ 99 . campus . 100 ............................. 102 Figure 1. Example Path Forwarding Nodes 104 In [RFC3168] it was recognized that tunnels and lower layer protocols 105 would need to support ECN, and ECN markings would need to be 106 propagated, as headers were encapsulated and decapsulated. 107 [ECNencapGuide] gives guidelines on the addition of ECN to protocols 108 like TRILL that often encapsulate IP packets, including propagation 109 of ECN from and to IP. 111 In the figure above, assuming IP traffic, RB1 is an encapsulator and 112 RB9 a decapsulator. Traffic from Source to RB1 might or might not get 113 marked as having experienced congestion in forwarding elements, such 114 as X, before being encapsulated at ingress RB1. Any such ECN marking 115 is encapsulated with a TRILL Header [RFC6325]. 117 This document specifies how ECN marking in traffic at the ingress is 118 copied into the TRILL Extension Header Flags Word and requires such 119 copying for IP traffic. It also enables congestion marking by a 120 congested RBridge such as RBn or RB1 above in the TRILL Header 121 Extension Flags Word [RFC7179]. 123 At RB9, the TRILL egress, it specifies how any ECN markings in the 124 TRILL Header Flags Word and in the encapsulated traffic are combined 125 so that subsequent forwarding elements, such as Y and the 126 Destination, can see if congestion was experienced at any previous 127 point in the path from Source. 129 A large part of the guidelines for adding ECN to lower layer 130 protocols [ECNencapGuide] concerns safe propagation of congestion 131 notifications in scenarios where some of the nodes do not support or 132 understand ECN. Such ECN ignorance is not a major problem with 133 RBridges using this specification because the method specified 134 assures that, if an egress RBridge is ECN ignorant (so it cannot 135 further propagate ECN) and congestion has been encountered, the 136 egress RBridge will at least drop the packet and this drop will 137 itself indicate congestion to end stations. 139 1.1 Conventions used in this document 141 The terminology and acronyms defined in [RFC6325] are used herein 142 with the same meaning. 144 In this documents, "IP" refers to both IPv4 and IPv6. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119] [RFC8174] 149 when, and only when, they appear in all capitals, as shown here. 151 Acronyms: 153 AQM - Active Queue Management 155 CCE - Critical Congestion Experienced 157 CE - Congestion Experienced 159 CItE - Critical Ingress-to-Egress 161 ECN - Explicit Congestion Notification 163 ECT - ECN Capable Transport 165 L4S - Low Latency, Low Loss, Scalable throughput 167 NCHbH - Non-Critical Hop-by-Hop 169 NCCE - Non-Critical Congestion Experienced 170 Not-ECT - Not ECN-Capable Transport 172 PCN - Pre-Congestion Notification 174 2. The ECN Specific Extended Header Flags 176 The extension header fields for explicit congestion notification 177 (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit 178 Critical Congestion Experienced (CCE) field in the 32-bit TRILL 179 Header Extension Flags Word [RFC7780]. 181 These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN 182 field consists of bits 12 and 13, which are in the range reserved for 183 non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 184 26, which is in the range reserved for Critical Ingress-to-Egress 185 (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary 186 bit and will be one if and only if any of the bits in the CItE range 187 (21-26) is one or there is a critical feature invoked in some further 188 extension of the TRILL Header after the Extension Flags Word. The 189 other bits and fields shown in Figure 2 are not relevant to ECN. See 190 [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these 191 other bits and fields. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 197 |.....|.........|...........|.....|.......|...........|.........| 198 |C|C|C| |C|N| | | | | | | | | 199 |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | 200 |H|I|R| |C|C| | | Hop | | |C|Clr| | 201 |b|t|s| |A|A| | | Cnt | | |E| | | 202 |H|E|v| |F|F| | | | | | | | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2. The TRILL-ECN and CCE 206 TRILL Header Extension Flags Word Fields 208 Table 1 shows the meaning of the codepoints in the TRILL-ECN field. 209 The first three have the same meaning as the corresponding ECN field 210 codepoints in the IPv4 or IPv6 header as defined in [RFC3168]. 211 However codepoint 0b11 is called Non-Critical Congestion Experienced 212 (NCCE) to distinguish it from Congestion Experienced in IP. 214 Binary Name Meaning 215 ------ ------- ----------------------------------- 216 00 Not-ECT Not ECN-Capable Transport 217 01 ECT(1) ECN-Capable Transport (1) 218 10 ECT(0) ECN-Capable Transport (0) 219 11 NCCE Non-Critical Congestion Experienced 221 Table 1. TRILL-ECN Field Codepoints 223 3. ECN Support 225 The subsections below describe the required behavior to support ECN 226 at TRILL ingress, transit, and egress. The ingress behavior occurs as 227 a native frame is encapsulated with a TRILL Header to produce a TRILL 228 Data packet. The transit behavior occurs in all RBridges where TRILL 229 Data packets are queued, usually at the output port. The egress 230 behavior occurs where a TRILL Data packet is decapsulated and output 231 as a native frame through an RBridge port. 233 An RBridge that supports ECN MUST behave as described in the relevant 234 subsections below, which correspond to the recommended provisions in 235 Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the scheme is 236 designed to safely propagate some form of congestion notification 237 even if some RBridges in the path followed by a TRILL Data packet 238 support ECN and others do not. 240 3.1 Ingress ECN Support 242 The behavior at an ingress RBridge is as follows: 244 o When encapsulating an IP frame, the ingress RBridge MUST: 246 + set the F flag in the main TRILL header [RFC7780]; 247 + create a Flags Word as part of the TRILL Header; 248 + copy the two ECN bits from the IP header into the TRILL-ECN 249 field (Flags Word bits 12 and 13) 250 + ensure the CCE flag is set to zero (Flags Word bit 26). 252 o When encapsulating a frame for a non-IP protocol, where that 253 protocol has a means of indicating ECN that is understood by the 254 ingress RBridge, it MUST follow the guidelines in Section 5.3 of 255 [ECNencapGuide] to add a Flags Word to the TRILL Header. For a 256 non-IP protocol with a similar ECN field to IP, this would be 257 achieved by copying into the TRILL-ECN field from the encapsulated 258 native frame. 260 3.2 Transit ECN Support 262 The transit behavior, shown below, is required at all RBridges where 263 TRILL Data packets are queued, usually at the output port. 265 o An RBridge that supports ECN MUST implement some form of active 266 queue management (AQM) according to the guidelines of [RFC7567]. 267 The RBridge detects congestion either by monitoring its own queue 268 depth or by participating in a link-specific protocol. 270 o If the TRILL Header Flags Word is present, whenever the AQM 271 algorithm decides to indicate congestion on a TRILL Data packet it 272 MUST set the CCE flag (Flags Word bit 26). 274 o If the TRILL header Flags Word is not present, to indicate 275 congestion the RBridge will either drop the packet or it MAY do 276 all of the following instead: 278 + set the F flag in the main TRILL header; 279 + add a Flags Word to the TRILL Header; 280 + set the TRILL-ECN field to Not-ECT (00); 281 + and set the CCE flag and the Ingress-to-Egress critical summary 282 bit (CRIbE). 284 Note that a transit RBridge that supports ECN does not refer to the 285 TRILL-ECN field before signalling CCE in a packet. It signals CCE 286 irrespective of whether the packet indicates that the transport is 287 ECN-capable. The egress/decapsulation behavior (described next) 288 ensures that a CCE indication is converted to a drop if the transport 289 is not ECN-capable. 291 3.3 Egress ECN Support 293 3.3.1 Non-ECN Egress RBridges 295 If the egress RBridge does not support ECN, that RBridge will ignore 296 bits 12 and 13 of any Flags Word that is present, because it does not 297 contain any special ECN logic. Nonetheless, if a transit RBridge has 298 set the CCE flag, the egress will drop the packet. This is because 299 drop is the default behavior for an RBridge decapsulating a Critical 300 Ingress-to-Egress flag when it has no specific logic to understand 301 it. Drop is the intended behavior for such a packet, as required by 302 Section 5.4 or [ECNencapGuide]. 304 3.3.2 ECN Egress RBridges 306 If an RBridge supports ECN, for the two cases of an IP and a non-IPR 307 inner packet, the egress behavior is as follows: 309 Decapsulating an inner IP packet: The RBridge sets the ECN field 310 of the outgoing native IP packet using Table 3. It MUST set the 311 ECN field of the outgoing IP packet to the codepoint at the 312 intersection of the row for the arriving encapsulated IP packet 313 and the column for 3-bit ECN codepoint in the arriving outer 314 TRILL Data packet TRILL Header. If no TRILL Header Extension 315 Flags Word is present, the 3-bit ECN codepoint is assumed to be 316 all zero bits. 318 The name of the TRILL 3-bit ECN codepoint is defined using the 319 combination of the TRILL-ECN and CCE fields in Table 2. 320 Specifically, the TRILL 3-bit ECN codepoint is called CE if 321 either NCCE or CCE is set in the TRILL Header Extension Flags 322 Word. Otherwise it has the same name as the 2-bit TRILL-ECN 323 codepoint. 325 In the case where the TRILL 3-bit ECN codepoint indicates 326 congestion experienced (CE) but the encapsulated native IP 327 frame indicates a not ECN-capable transport (Not-ECT), it can 328 be seen that the RBridge MUST drop the packet. Such packet 329 dropping is necessary because a transport above the IP layer 330 that is not ECN-capable will have no ECN logic, so it will only 331 understand dropped packets as an indication of congestion. 333 Decapsulating a non-IP protocol frame: If the frame has a means of 334 indicating ECN that is understood by the RBridge, it MUST 335 follow the guideines in Section 5.4 of [ECNencapGuide] when 336 setting the ECN information in the decapsulated native frame. 337 For a non-IP protocol with a similar ECN field to IP, this 338 would be achieved by combining the information in the TRILL 339 Header Flags Word with the encapsulated non-IP native frame, as 340 specified in Table 3. 342 +------------+-----+---------------------+ 343 | TRILL-ECN | CCE | Arriving TRILL 3-bit| 344 | | | ECN codepoint name | 345 +------------+-----+---------------------+ 346 | Not-ECT 00 | 0 | Not-ECT | 347 | ECT(1) 01 | 0 | ECT(1) | 348 | ECT(0) 10 | 0 | ECT(0) | 349 | NCCE 11 | 0 | CE | 350 | Not-ECT 00 | 1 | CE | 351 | ECT(1) 01 | 1 | CE | 352 | ECT(0) 10 | 1 | CE | 353 | NCCE 11 | 1 | CE | 354 +------------+-----+---------------------+ 356 Table 2. Mapping of TRILL-ECN and CCE Fields to 357 the TRILL 3-bit ECN Codepoint Name 359 +---------+----------------------------------------------+ 360 | Inner | Arriving TRILL 3-bit ECN Codepoint Name | 361 | Native +---------+------------+------------+----------+ 362 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 363 +---------+---------+------------+------------+----------+ 364 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | 365 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 366 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 367 | CE | CE | CE | CE(*) | CE | 368 +---------+---------+------------+------------+----------+ 370 Table 3. Egress ECN Behavior 372 An asterisk in the above table indicates a currently unused 373 combination that SHOULD be logged. In contrast to [RFC6040], in TRILL 374 the drop condition is the result of a valid combination of events and 375 need not be logged. 377 4. TRILL Support for ECN Variants 379 This section is informative, not normative. 381 Section 3 specifies interworking between TRILL and the original 382 standardized form of ECN in IP [RFC3168]. 384 The ECN wire protocol for TRILL (Section 2) has been designed to 385 support the other known variants of ECN, as detailed below. New 386 variants of ECN will have to comply with the guidelines for defining 387 alternative ECN semantics [RFC4774]. It is expected that the TRILL 388 ECN wire protocol is generic enough to support such potential future 389 variants. 391 4.1 Pre-Congestion Notification (PCN) 393 The PCN wire protocol [RFC6660] is recognised by the use of a PCN- 394 compatible Diffserv codepoint in the IP header and a non-zero IP-ECN 395 field. For TRILL or any lower layer protocol, equivalent traffic 396 classification codepoints would have to be defined, but that is 397 outside the scope of the current document. 399 The PCN wire protocol is similar to ECN, except it indicates 400 congestion with two levels of severity. It uses: 402 o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) 403 codepoint 405 o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked 406 (ThM) codepoint. (This difference between ECT(1) and ECT(0) only 407 applies to PCN, not to the classic ECN support specified for TRILL 408 in this document before Section 4.) 410 To implement PCN on a transit RBridge would require a detailed 411 specification. But in brief: 413 o the TRILL Critical Congestion Experienced (CCE) flag would be used 414 for the Excess-Traffic-Marked (ETM) codepoint; 416 o ECT(1) in the TRILL-ECN field would be used for the Threshold- 417 Marked codepoint. 419 Then the ingress and egress behaviors defined in Section 3 would not 420 need to be altered to ensure support for PCN as well as ECN. 422 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) 424 L4S is currently on the IETF's experimental track. An outline of how 425 a transit TRILL RBridge would support L4S [ECNL4S] is given in 426 Appendix A. 428 5. IANA Considerations 430 IANA is requested to update the TRILL Extended Header Flags registry 431 by replacing the lines for bits 9-13 and for bits 21-26 with the 432 following: 434 Bits Purpose Reference 435 ----- ------- --------- 436 9-11 available non-critical hop-by-hop flags 437 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 439 21-25 available critical ingress-to-egress flags 440 26 Critical Congestion Experienced (CCE) [this doc] 442 6. Security Considerations 444 TRILL support of ECN is a straight forward combination of previously 445 specified ECN and TRILL with no significnat new security 446 considerations. 448 For ECN tunneling security considerations, see [RFC6040]. 450 For general TRILL protocol security considerations, see [RFC6325]. 452 7. Acknowledgements 454 The helpful comments of Loa Andersson are hereby acknowledged. 456 This document was prepared with basic NROFF. All macros used were 457 defined in the source file. 459 Normative References 461 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 463 March 1997, . 465 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 466 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 467 10.17487/RFC3168, September 2001, . 470 [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the 471 Explicit Congestion Notification (ECN) Field", BCP 124, RFC 472 4774, DOI 10.17487/RFC4774, November 2006, . 475 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 476 Ghanwani, "Routing Bridges (RBridges): Base Protocol 477 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 478 . 480 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 481 C. Bestler, "Transparent Interconnection of Lots of Links 482 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 483 2014, . 485 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 486 Recommendations Regarding Active Queue Management", BCP 197, 487 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 490 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 491 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 492 Lots of Links (TRILL): Clarifications, Corrections, and 493 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 494 . 496 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 498 2017, 500 [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, 501 "Guidelines for Adding Congestion Notification to Protocols 502 that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, 503 work in progress. 505 Informative References 507 [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit 508 Congestion Notification (ECN) Semantics for Ultra-Low Queueing 509 Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. 511 [IANAthFlags] - IANA TRILL Extended Header word flags: 512 http://www.iana.org/assignments/trill-parameters/trill- 513 parameters.xhtml#extended-header-flags 515 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 516 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 517 . 519 [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 520 Pre-Congestion Notification (PCN) States in the IP Header Using 521 a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 522 10.17487/RFC6660, July 2012, . 525 Appendix A. TRILL Transit RBridge Behavior to Support L4S 527 The specification of the Low Latency, Low Loss, Scalable throughput 528 (L4S) wire protocol for IP is given in [ECNL4S]. It is similar to the 529 original ECN wire protoocl for IP [RFC3168], except: 531 o An AQM that supports L4S classifies packets with ECT(1) or CE in 532 the IP header into an L4S queue and a "Classic" queue otherwise. 534 o the meaning of CE markings applied by an L4S queue is not the same 535 as the meaning of a drop by a "Classic" queue (contrary to the 536 original requirement for ECN [RFC3168]). Instead the likelihood 537 that the Classic queue drops packets is defined as the square of 538 the likelihood that the L4S queue marks packets (e.g. when there 539 is a drop probability of 0.0009 (0.09%) the L4S marking 540 probability will be 0.03 (3%)). 542 This seems to present a problem for the way that a transit TRILL 543 RBridge defers the choice between marking and dropping to the egress. 544 Nonetheless, the following pseudocode outlines how a transit TRILL 545 RBridge can implement L4S marking in such a way that the egress 546 behavior already described in Section 3.3 for Classic ECN [RFC3168] 547 will produce the desired outcome. 549 /* p is an internal variable calculated by any L4S AQM 550 * dependent on the delay being experienced in the Classic queue. 551 * bit13 is the least significant bit of the TRILL-ECN field 552 */ 554 % On TRILL transit 555 if (bit13 == 0 ) { 556 % Classic Queue 557 if (p > max(random(), random()) ) 558 mark(CCE) % likelihood: p^2 560 } else { 561 % L4S Queue 562 if (p > random() ) { 563 if (p > random() ) 564 mark(CCE) % likelihood: p^2 565 else 566 mark(NCCE) % likelihood: p - p^2 567 } 568 } 570 With the above transit behavior, an egress that supports ECN (Section 571 3.3) will drop packets or propagate their ECN markings depending on 572 whether the arriving inner header is from a non-ECN-capable or ECN- 573 capable transport. 575 Even if an egress has no L4S-specific logic of its own, it will drop 576 packets with the square of the probability that an egress would if it 577 did support ECN, for the following reasons: 579 o Egress with ECN support: 581 + L4S: propagates both the Critical and Non-Critical CE marks 582 (CCE & NCCE) as a CE mark. 584 Likelihood: p^2 + p - p^2 = p 586 + Classic: Propagates CCE marks as CE or drop, depending on 587 inner. 589 Likelihood: p^2 591 o Egress without ECN support: 593 + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. 595 Likelihood: p^2 597 + Classic: drops CCE marks. 599 Likelihood: p^2 601 Authors' Addresses 603 Donald E. Eastlake, 3rd 604 Huawei Technologies 605 155 Beaver Street 606 Milford, MA 01757 USA 608 Tel: +1-508-333-2270 609 Email: d3e3e3@gmail.com 611 Bob Briscoe 612 CableLabs 613 UK 615 Email: ietf@bobbriscoe.net 616 URI: http://bobbriscoe.net/ 618 Copyright and IPR Provisions 620 Copyright (c) 2018 IETF Trust and the persons identified as the 621 document authors. All rights reserved. 623 This document is subject to BCP 78 and the IETF Trust's Legal 624 Provisions Relating to IETF Documents 625 (http://trustee.ietf.org/license-info) in effect on the date of 626 publication of this document. Please review these documents 627 carefully, as they describe your rights and restrictions with respect 628 to this document. Code Components extracted from this document must 629 include Simplified BSD License text as described in Section 4.e of 630 the Trust Legal Provisions and are provided without warranty as 631 described in the Simplified BSD License. The definitive version of 632 an IETF Document is that published by, or under the auspices of, the 633 IETF. Versions of IETF Documents that are published by third parties, 634 including those that are translated into other languages, should not 635 be considered to be definitive versions of IETF Documents. The 636 definitive version of these Legal Provisions is that published by, or 637 under the auspices of, the IETF. Versions of these Legal Provisions 638 that are published by third parties, including those that are 639 translated into other languages, should not be considered to be 640 definitive versions of these Legal Provisions. For the avoidance of 641 doubt, each Contributor to the IETF Standards Process licenses each 642 Contribution that he or she makes as part of the IETF Standards 643 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 644 language to the contrary, or terms, conditions or rights that differ 645 from or are inconsistent with the rights and licenses granted under 646 RFC 5378, shall have any effect and shall be null and void, whether 647 published or posted by such Contributor, or included with or in such 648 Contribution.