idnits 2.17.1 draft-johansson-quic-ecn-01.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 21, 2017) is 2611 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Bagnulo' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'ECN-fallback' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC6789' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC7560' is defined on line 519, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-01 == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Johansson 3 Internet-Draft Ericsson AB 4 Intended status: Informational February 21, 2017 5 Expires: August 25, 2017 7 ECN support in QUIC 8 draft-johansson-quic-ecn-01 10 Abstract 12 This memo outlines the ECN support in QUIC. The intention is that 13 most of the material ends up updating other new or existing QUIC 14 protocol specifications, thus it may be possible that this draft does 15 not warrant a working group status. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 25, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Elements of ECN support . . . . . . . . . . . . . . . . . . . 2 59 2.1. ECN negotialtion . . . . . . . . . . . . . . . . . . . . 3 60 2.2. ECN bits in the IP header, semantics . . . . . . . . . . 4 61 2.3. ECN echo . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Fallback in case of ECN fault . . . . . . . . . . . . . . 8 63 2.5. OS socket specifics, access to the ECN bits . . . . . . . 9 64 2.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 4. Open questions . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 ECN support in transport protocols is a fundamental feature that 77 should be included in the QUIC specification as a mandatory element. 78 The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The 79 ECN support should be implemented to support both present and future 80 ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], 81 of particular interest is the ability to discriminate between classic 82 ECN and L4S ECN by means of differentiation between the use of the 83 ECT(0) and ECT(1) code points. This draft does however not delve 84 into the details of the congestion control implementation. 86 2. Elements of ECN support 88 This draft covers the following aspects of ECN support: 90 o ECN negotiation 92 o ECN echo 94 o ECN bits in the IP header, semantics 96 o Fallback in case of ECN fault 97 o OS socket specifics, access to the ECN bits 99 o Monitoring 101 2.1. ECN negotialtion 103 ECN support in QUIC needs to be negotiated. The reasons is that 104 network elements may not support ECN and may either clear the ECN 105 bits or simply discard packets that have the ECN bits set. In 106 addition, a QUIC implementation may not have access to the ECN bits 107 in the IP header due to OS dependent restrictions, investigations 108 (Piers O'Hanlon) have indicated that this is in certain cases an 109 asymmetric property, for instance while it is possible to set the ECN 110 bits it is not possible to read them. 112 It is also required that the ECN negotiation does not interfere with 113 the connection setup, in other words a failed ECN negotation should 114 not cause an extra roundtrip for the connection setup. 116 The suggested method in this draft is to add an ECN negotiation frame 117 that is transmitted when connection setup is completed. Both peers 118 MUST transmit the ECN negotation frame. The ECN negotiation frame is 119 shown below. 121 0 1 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type |C|R|W|U U U|E E| 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 1: ECN negotation frame 129 The 2nd byte contains the flags: 131 o C: Challenge bit, indicates that the transmitted ECN negotiation 132 frame is a challenge, if bit is not set then it is a response. 134 o R: Possible to read ECN bits in IP header 136 o W: Possible to write ECN bits in IP header 138 o EE : Echo of ECN bits 140 o U: Unused 142 A peer transmits the ECN negotiation frame with the R,W and EE bits 143 in the 2nd byte set to '0' and the C bit set to '1'. This frame is 144 echoed back with the flags set occording to the degree of ECN support 145 and with the ECN bits in the IP header of the received ECN 146 negotiation frame copied to the EE field, the C bit is '0'. As both 147 peers MUST transmit an ECN negotation frame there will be a total of 148 4 ECN negotiation frames transmitted, two challenges and two 149 responses. 151 The IP header for the ECN negotiation frame should set the ECN bits 152 to CE '11'. When the corresponding response is received then an EE 153 pattern of '11' indicates that ECN is likely supported in the 154 network. This does not give a full quarantee that ECN is supported 155 in the network. Monitoring of the ECN field in the ACK-frame serves 156 to give further indication of ECN support once ECN is turned on. 158 A peer is not allowed to set ECT on outgoing data packets until a ECN 159 negotiation response that inticates that ECN is supported is 160 received. In other words it is only the ECN negotiation frame that 161 is allowed to set the ECN bits in the IP header. 163 A lack of an ECN negotiation response may indicate that the ECN 164 challenge frame or the ECN response frame was lost or that a node in 165 the network deliberately discards ECN-CE marked packets. The peer 166 can transmit additonal ECN challeges with given time intervals to 167 rule out accidentail packet loss. The detailed timing for this is 168 T.B.D. 170 The mode mechanism in [RFC6679] can serve as in input to a solution 171 for the support of ECN in the case that OS ECN support is asymmetric. 172 It is however unclear how a QUIC implementation can determine 173 asymmetric ECN support in the underlying OS. For instance the method 174 to send ECN marked packets to the local host to determine OS support 175 does not reveal if the OS ECN support is asymmetric. 177 2.2. ECN bits in the IP header, semantics 179 The ECN bits in the IP header should be set according to the 180 recommendations in [I-D.ietf-tsvwg-ecn-experimentation]. This means 181 that the meaning of ECT(0) and ECT(1) differ. 183 2.3. ECN echo 185 The ECN echo should prefferably go into the ACK frame 186 [I-D.ietf-quic-transport], this is beneficial as the ECN information 187 can then use some of the already existing data in the ACK frame for 188 improved efficiency, this applies especially to alternatives 1 and 2 189 below. It is suggested that the 'U' bit in the ACK frame type is 190 renamed 'E' to indicate the presence of an ECN field in the ACK 191 frame, this makes it possible to omit the ECN information for the 192 cases where ECN is not supported for the connection. 194 Currently there are three alternatives how to add ECN support to the 195 ACK frames . 197 The first alternative inserts a one octet field that contains a 2 bit 198 ECN echo, followed by the ACK block length. The ACK block length 199 then dictates the number of received contiguous frames with the 200 indicated ECN echo. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | ECE (8) | First Ack Block Length (8/16/32/48) ... 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | [Gap 1 (8)] | ECE(8) |[Ack Blk 1 L (8/16/32/48)] ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | [Gap 2 (8)] | ECE(8) |[Ack Blk 2 L (8/16/32/48)] ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ... 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | [Gap N (8)] | ECE(8) |[Ack Blk N L (8/16/32/48)] ... 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 2: ECN field in ACK frame ACK block, alt 1 218 The second alternative encodes a variable length field that contains 219 the ECN echoes for the frames listed in the ACK blocks. The length 220 of the field is inferred from the ACK block lengths. No ECN echoes 221 are indicated for the gaps (it is, after all, impossible to indicate 222 status of the ECN bits for lost packets). For instance if the ACK 223 blocks list 10 frames, then the length of the ECN echo field becomes 224 2*10=20bits, with additional 4 bits of padding the ECN echo field 225 will then become 3 octets long. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | First Ack Block Length (8/16/32/48) ... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ... 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |ECE|ECE|... variable length, padded to full octets ... 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 3: ECN field in ACK frame ACK block, alt 2 245 The third alternative encodes the number of bytes that are marked 246 ECT(0), ECT(1) and CE with 32 bits each, the total extra overhead is 247 thus 12 octets. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | First Ack Block Length (8/16/32/48) ... 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ... 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | # ECT(0) bytes (32) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | # ECT(1) bytes (32) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | # ECN-CE bytes (32) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 4: ECN field in ACK frame ACK block, alt 3 271 The fourth alternative use an extra byte to encode how many bits that 272 encode each of the ECT/CE fields. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | First Ack Block Length (8/16/32/48) ... 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 ... 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |R|R|E1 |E2 |CE | # ECT(0) bytes (0/16/32/48) ... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | # ECT(1) bytes (0/16/32/48) ... 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | # ECN-CE bytes (0/16/32/48) ... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 5: ECN field in ACK frame ACK block, alt 4 296 The E1,E2 and CE fields indicate the length of each encoding for the 297 number of ECT(0), ECT(1) and ECN-CE marked bytes. This is encoded 298 as: 300 o 00: 0 bits 302 o 01: 16 bits 304 o 10: 32 bits 306 o 11: 48bits 308 R indicates reserved bits. 310 There are pros an cons with the four alternatives: 312 o Alt 1: Is very compact in the case where the ECN bits are largely 313 unchanged. However in the worst case where received frames flip 314 forth and back between ECT and CE then each frame will require at 315 least 3 octets overhead (ECE, ACK block length, Gap). 317 o Alt 2: Is quite compact as it only requires two bits encoding per 318 frame. The additional overhead amounts to ceil(N*2/8) octets 319 where the N is the sum of the ACK block lengths. On the downside 320 is that it is a less efficient format for the case that the ECN 321 bits are unchanged. One uncertainty is if STOP_WAITING frames 322 could make this encoding bulky. 324 o Alt 3: Has a fixed 12 octet overhead which may be beneficial as it 325 gives a deterministic overhead. The possible drawback is that it 326 is not possible to know exactly which frames have been remarked, 327 something that can limit the ability to detect network ECN faults 328 based on the method to transmit a pattern on ECT and CE marked 329 packets. 331 o Alt 4: Is a variation to Alt 3 but has a variable length encoding 332 that should consume less space, especially in the cases that one 333 of the ECT code points is not used and for the case that packets 334 are only sporadically ECN-CE marked. This alternative also makes 335 it unnecessary to use a bit in the ACK frame type to indicate the 336 precense of an ECN field as this can be indicated in a efficient 337 way with the one byte header in this format. E0=E1=CE = 00 338 indicates that the following ECT and CE fields are encoded with 339 zero bits. 341 Which of the three formats above (or something else) that is the best 342 alternative is subject to discussion. 344 2.4. Fallback in case of ECN fault 346 ECN can be subject to issues in network equipment, such as remarking 347 to Not-ECN, remarking from ECT(0) to ECT(1) and vice versa or 348 constant remarking to ECN-CE. Furthermore ECT marked packets may be 349 discarded in the network. While these problems seem to be rare, see 350 for instance [McQuistin-Perkins], it is still necessary to safeguard 351 against such problems. 353 A peer should disable ECN for its outgoing packets if ECN fault is 354 detected, it is however still possible for the other peer to use ECN. 356 TODO add more information as regards to how to detect network ECN 357 faults. [ECN-fallback](expired) gives a few examples for fault 358 detection. Examples on how to detect ECN faults include for instance 359 the method to set ECT and CE for outgoing packets according to a 360 given pattern. 362 Fallback in case of ECN faults is not an issue only for QUIC, it is 363 here suggested that mechanisms for this is described in a non QUIC 364 related draft, for instance in TSVWG. 366 2.5. OS socket specifics, access to the ECN bits 368 ECN support in QUIC comes with the additional challenge that it is 369 necessary to somehow access the ECN bits in the IP headers. In TCP 370 this is provided without major concerns as TCP is generally 371 implemented in OS kernel space. QUIC can however be implemented both 372 in user space or kernel space and is layered on top of UDP, which 373 means that access to the ECN bits is not a given, instead various 374 tricks are needed. 376 The text below is copy-pasted from [OHanlon]. 378 "To set ECN on Linux, BSD and OSX one can use IP_TOS socket option, 379 with the setsockopt() call, to set the relevant ECN bits of the TOS 380 byte. On Windows one can use a similar technique though firstly one 381 has to enable TOS byte setting by enabling a particular Registry key 382 ( DisableUserTOSSetting=0 (see https://msdn.microsoft.com/en- 383 us/library/windows/desktop/dd874008%28v=vs.85%29.aspx One could also 384 probably use the libpcap write functionality." 386 "To obtain the ECN bits from a packet one needs a mechanism to 387 retrieve the ECN bits from each packet. On Linux, one needs to 388 firstly set the IP_RECVTOS socket option on the receiving socket, and 389 use the recvmsg() call to receive a packet, and then retrieve the TOS 390 byte from the associated csmg structure returned by the recvmsg() 391 call. This still works with linux-4.2.3. On OSX/BSD there are no 392 suitable socket options to retrieve the ECN/TOS bits and one cannot 393 use raw sockets as they do not function for UDP/TCP sockets (they do 394 work with ICMP), so one has to use alternatives such the bpf 395 interface, or a REDIRECT socket. Whilst on Windows it seems that the 396 only way to retrieve the ECN bits is via a raw socket, or custom NDIS 397 driver, though it's possible there's an API I'm missing." 399 TODO: Write a more detailed description on how to implement ECN 400 support in QUIC for different OS stacks. 402 2.6. Monitoring 404 A QUIC implementation should monitor the ECN functionality in order 405 to provide input to e.g. service providers to improve ECN support in 406 the networks. Items of interest are: 408 o Black holes, ECT or CE marked packets are discarded. 410 o Faulty remarking, e.g. ECT(0) is remarked to ECT(1) or Not-ECT. 412 o Continuous CE marking, possible indication of faulty on/off ECN 413 marking, but can also be an effect of severe congestion. 415 o Degree of L4S support. L4S should generally give low queue 416 latency. Estimation of one way queue delay for L4S enabled QUIC 417 connections can be used to determine if there are congested nodes 418 along the path that are not L4S capable. 420 3. IANA Considerations 422 T.B.D. 424 4. Open questions 426 A list of open questions: 428 o Is it sufficient that one peer sends an ECN negotiation challenge 429 frame?. 431 o Should the ECN field in the ACK frame be mandatory ? (in which 432 case it is not necessary to indicate its presence) 434 o Should all packets be ECT or should there be special patterns to 435 improve fault detection. 437 o Write up a more detailed description on how to implement ECN 438 support in QUIC for different OS stacks. 440 o Determine which ECN echo encoding in the ACK frame is the best 441 alternative. 443 o Is a completely new ACK frame an alternative ? 445 o How do STOP_WAITING frames affect the ECN echo overhead. 447 o Outline possible connection migration actions 449 o Are there any security implications with the smalle ECN 450 negotiation frame ? 452 5. Security Considerations 454 T.B.D 456 6. Acknowledgements 458 The following persons have contributed with comments and suggestions 459 for improvements: Mirja Kuehlewind, Koen De Schepper, Piers O'Hanlon, 460 Michael Welzl, Marcelo Bagnulo Braun, Martin Duke 462 7. References 464 7.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 7.2. Informative References 473 [Bagnulo] "Adding Explicit Congestion Notification (ECN) to TCP 474 control packets and TCP retransmissions", 475 . 478 [ECN-fallback] 479 "A Mechanism for ECN Path Probing and Fallback", 480 . 483 [I-D.ietf-aqm-ecn-benefits] 484 Fairhurst, G. and M. Welzl, "The Benefits of using 485 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 486 ecn-benefits-08 (work in progress), November 2015. 488 [I-D.ietf-quic-transport] 489 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 490 and Secure Transport", draft-ietf-quic-transport-01 (work 491 in progress), January 2017. 493 [I-D.ietf-tsvwg-ecn-experimentation] 494 Black, D., "Explicit Congestion Notification (ECN) 495 Experimentation", draft-ietf-tsvwg-ecn-experimentation-00 496 (work in progress), December 2016. 498 [McQuistin-Perkins] 499 ""Is Explicit Congestion Notification usable with UDP?", 500 Proceedings of the ACM Internet Measurement Conference, 501 Tokyo, Japan, October 2015. DOI:10.1145/2815675.2815716", 502 . 505 [OHanlon] "ECN support in different OS stacks", 506 . 509 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 510 and K. Carlberg, "Explicit Congestion Notification (ECN) 511 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 512 2012, . 514 [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., 515 "Congestion Exposure (ConEx) Concepts and Use Cases", 516 RFC 6789, DOI 10.17487/RFC6789, December 2012, 517 . 519 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 520 "Problem Statement and Requirements for Increased Accuracy 521 in Explicit Congestion Notification (ECN) Feedback", 522 RFC 7560, DOI 10.17487/RFC7560, August 2015, 523 . 525 Author's Address 527 Ingemar Johansson 528 Ericsson AB 529 Laboratoriegraend 11 530 Luleaa 977 53 531 Sweden 533 Phone: +46 730783289 534 Email: ingemar.s.johansson@ericsson.com