idnits 2.17.1 draft-johansson-quic-ecn-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2017) is 2516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Bagnulo' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'ECN-fallback' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC6789' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC7560' is defined on line 468, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-02 Summary: 0 errors (**), 0 flaws (~~), 8 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 May 30, 2017 5 Expires: December 1, 2017 7 ECN support in QUIC 8 draft-johansson-quic-ecn-03 10 Abstract 12 This memo outlines the ECN (Explicit Congestion Notification) support 13 in QUIC. The draft specifies the ECN negotiation and the ECN echo 14 and in addition, different aspects of fallback in case of ECN failure 15 as well as OS specific issues with ECN and monitoring for ECN 16 capability. The intention is that most of the material ends up 17 updating other new or existing QUIC protocol specifications, thus it 18 may be possible that this draft does not warrant a working group 19 status. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 1, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Elements of ECN support . . . . . . . . . . . . . . . . . . . 3 75 2.1. ECN negotiation . . . . . . . . . . . . . . . . . . . . . 3 76 2.1.1. Challenge/Response . . . . . . . . . . . . . . . . . 4 77 2.1.2. Determine degree of ECN support . . . . . . . . . . . 5 78 2.2. ECN bits in the IP header, semantics . . . . . . . . . . 6 79 2.3. ECN echo . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.4. Fallback in case of ECN fault . . . . . . . . . . . . . . 7 81 2.5. OS socket specifics, access to the ECN bits . . . . . . . 7 82 2.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 83 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 4. Open questions . . . . . . . . . . . . . . . . . . . . . . . 8 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 7.2. Informative References . . . . . . . . . . . . . . . . . 9 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 ECN support in transport protocols is a fundamental feature that 95 should be included in the QUIC specification as a mandatory element. 96 ECN has the key benefit that it allows for non-destructive congestion 97 notification by network node, i.e packets are marked instead 98 discarded. This is particularly beneficial for realtime applications 99 with requirements on latency, ECN also has the benefit that it 100 provides with a congestion signal that is unambiguous. The benefits 101 with ECN is described in more detail in [I-D.ietf-aqm-ecn-benefits]. 102 The ECN support should be implemented to support both present and 103 future ECN, the latter is outlined in 104 [I-D.ietf-tsvwg-ecn-experimentation], of particular interest is the 105 ability to discriminate between classic ECN and L4S ECN by means of 106 differentiation between the use of the ECT(0) and ECT(1) code points. 107 This draft does however not delve into the details of the congestion 108 control implementation. 110 2. Elements of ECN support 112 This draft covers the following aspects of ECN support: 114 o ECN negotiation 116 o ECN echo 118 o ECN bits in the IP header, semantics 120 o Fallback in case of ECN fault 122 o OS socket specifics, access to the ECN bits 124 o Monitoring 126 2.1. ECN negotiation 128 ECN support in QUIC needs to be negotiated. The reasons is that 129 network elements may not support ECN and may either clear the ECN 130 bits or simply discard packets that have the ECN bits set. In 131 addition, a QUIC implementation may not have access to the ECN bits 132 in the IP header due to OS dependent restrictions, investigations 133 (Piers O'Hanlon) have indicated that this is in certain cases an 134 asymmetric property, for instance while it is possible to set the ECN 135 bits it is not possible to read them. 137 It is also required that the ECN negotiation does not interfere with 138 the connection setup, in other words a failed ECN negotiation should 139 not cause an extra roundtrip for the connection setup. 141 The suggested method in this draft is to send an ECN negotiation 142 frame when connection setup is completed. Both peers MUST transmit 143 the ECN negotiation frame. The ECN negotiation frame is shown below. 145 0 1 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type |C|R|W|U U U|E E| 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: ECN negotation frame 153 The 2nd byte contains the flags: 155 o C: Challenge bit, indicates that the transmitted ECN negotiation 156 frame is a challenge, if bit is not set then it is a response. 158 o R: Possible to read ECN bits in IP header 160 o W: Possible to write ECN bits in IP header 162 o EE : Echo of ECN bits 164 o U: Unused 166 The ECN negotiation has two steps. 168 o Challenge/response 170 o Determine degree of ECN support 172 2.1.1. Challenge/Response 174 A peer transmits the ECN negotiation frame with the R,W and EE bits 175 in the 2nd byte set to '0' and the C bit set to '1'. This frame is 176 echoed back with the flags set according to the degree of ECN support 177 and with the ECN bits in the IP header of the received ECN 178 negotiation frame copied to the EE field, the C bit is '0'. As both 179 peers MUST transmit an ECN negotiation frame there will be a total of 180 4 ECN negotiation frames transmitted, two challenges and two 181 responses. 183 An ECN negotiation frame should be transmitted in a unique packet, 184 this to avoid that possible loss of ECN negotiation packets cause 185 loss of other frames than the ECN negotiation frame. 187 The IP header for the ECN negotiation frame should set the ECN bits 188 to CE '11'. When the corresponding response is received then an EE 189 pattern of '11' indicates that ECN is likely supported in the 190 network. This does not give a full guarantee that ECN is supported 191 in the network. Monitoring of the ECN field in the ACK-frame serves 192 to give further indication of ECN support once ECN is turned on. 194 An ECN negotiation is declared successful when an ECN negotiation 195 response is received that indicates ECN support. A peer is not 196 allowed to set ECT on outgoing data packets until a successful ECN 197 negotiation is done. In other words it is only the ECN negotiation 198 frame that is allowed to set the ECN bits in the IP header until ECN 199 negotiation is concluded and successful. 201 A lack of an ECN negotiation response may indicate that the ECN 202 challenge frame or the ECN response frame was lost or that a node in 203 the network deliberately discards ECN-CE marked packets. The peer 204 should transmit an additional ECN challenge within an RTO interval in 205 case a negotiation response is not received, a maximum of 206 retransmissions are attempted. 208 A failed challenge/response phase indicates that ECN should not be 209 used in the connection. [NOTE, a special case is where one peer does 210 not receive an ECN negotiation response but still receives ECT and CE 211 marked packets from the other peer. It is T.B.D how this should be 212 handled] 214 2.1.2. Determine degree of ECN support 216 If the ECN challenge/response is successful, the degree of ECN 217 capability depends on how the R, W and EE bits are set. 219 o R='1' and EE= '11': It is possible to set the ECN bits in outgoing 220 packets. 222 o R='0' or EE <> '11': ECN support is not certain as it is either 223 not possible for remote peer to read the ECN bits or that the ECN 224 bits are altered. 226 o W='1' : It is meaningful to send ECN feedback 228 o W='0' : It is not meaningful to send ECN feedback as the remote 229 peer cannot set (write) the ECN bits in the IP header. 231 The mode mechanism in [RFC6679] can serve as in input to a solution 232 for the support of ECN in the case that OS ECN support is asymmetric. 233 It is however unclear how a QUIC implementation can determine 234 asymmetric ECN support in the underlying OS. For instance the method 235 to send ECN marked packets to the local host to determine OS support 236 does not reveal if the OS ECN support is asymmetric. 238 2.2. ECN bits in the IP header, semantics 240 The ECN bits in the IP header should be set according to the 241 recommendations in [I-D.ietf-tsvwg-ecn-experimentation]. This means 242 that the meaning of ECT(0) and ECT(1) differ. 244 2.3. ECN echo 246 The ECN echo should go into the ACK frame [I-D.ietf-quic-transport], 247 this is beneficial as the ECN information can then use some of the 248 already existing data in the ACK frame for improved efficiency. 250 The proposed alternative use one byte to encode how many bits that 251 encode each of the ECT/CE fields. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | First Ack Block Length (8/16/32/48) ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | [Gap 1 (8)] | [Ack Block 1 Length (8/16/32/48)] ... 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | [Gap 2 (8)] | [Ack Block 2 Length (8/16/32/48)] ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | [Gap N (8)] | [Ack Block N Length (8/16/32/48)] ... 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |R|R|E1 |E2 |CE | # ECT(0) bytes (0/16/32/48) ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | # ECT(1) bytes (0/16/32/48) ... 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | # ECN-CE bytes (0/16/32/48) ... 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: ECN field in ACK frame ACK block 275 The E1,E2 and CE fields indicate the length of each encoding for the 276 number of ECT(0), ECT(1) and ECN-CE marked bytes. This is encoded 277 as: 279 o 00: 0 bits 281 o 01: 16 bits 283 o 10: 32 bits 285 o 11: 48bits 286 R indicates reserved bits. 288 The proposed encoding enables flexible encoding of the ECN 289 information, with a minimal 1 octet overhead for the cases where ECN 290 is not supported by the connection. 292 2.4. Fallback in case of ECN fault 294 ECN can be subject to issues in network equipment, such as remarking 295 to Not-ECN, remarking from ECT(0) to ECT(1) and vice versa or 296 constant remarking to ECN-CE. Furthermore ECT marked packets may be 297 discarded in the network. While these problems seem to be rare, see 298 for instance [McQuistin-Perkins]and [APPLE-ECN], it is still 299 necessary to safeguard against such problems. 301 A peer should disable ECN for its outgoing packets if ECN fault is 302 detected, it is however still possible for the other peer to use ECN. 304 TODO add more information as regards to how to detect network ECN 305 faults. [ECN-fallback](expired) gives a few examples for fault 306 detection. Examples on how to detect ECN faults include for instance 307 the method to set ECT and CE for outgoing packets according to a 308 given pattern. 310 Fallback in case of ECN faults is not an issue only for QUIC, it is 311 here suggested that mechanisms for this is described in a non QUIC 312 related draft, for instance in TSVWG. 314 2.5. OS socket specifics, access to the ECN bits 316 ECN support in QUIC comes with the additional challenge that it is 317 necessary to somehow access the ECN bits in the IP headers. In TCP 318 this is provided without major concerns as TCP is generally 319 implemented in OS kernel space. QUIC can however be implemented both 320 in user space or kernel space and is layered on top of UDP, which 321 means that access to the ECN bits is not a given, instead various 322 tricks are needed. 324 The text below is copy-pasted from [OHanlon]. 326 "To set ECN on Linux, BSD and OSX one can use IP_TOS socket option, 327 with the setsockopt() call, to set the relevant ECN bits of the TOS 328 byte. On Windows one can use a similar technique though firstly one 329 has to enable TOS byte setting by enabling a particular Registry key 330 ( DisableUserTOSSetting=0 (see https://msdn.microsoft.com/en- 331 us/library/windows/desktop/dd874008%28v=vs.85%29.aspx One could also 332 probably use the libpcap write functionality." 333 "To obtain the ECN bits from a packet one needs a mechanism to 334 retrieve the ECN bits from each packet. On Linux, one needs to 335 firstly set the IP_RECVTOS socket option on the receiving socket, and 336 use the recvmsg() call to receive a packet, and then retrieve the TOS 337 byte from the associated csmg structure returned by the recvmsg() 338 call. This still works with linux-4.2.3. On OSX/BSD there are no 339 suitable socket options to retrieve the ECN/TOS bits and one cannot 340 use raw sockets as they do not function for UDP/TCP sockets (they do 341 work with ICMP), so one has to use alternatives such the bpf 342 interface, or a REDIRECT socket. Whilst on Windows it seems that the 343 only way to retrieve the ECN bits is via a raw socket, or custom NDIS 344 driver, though it's possible there's an API I'm missing." 346 TODO: Write a more detailed description on how to implement ECN 347 support in QUIC for different OS stacks. 349 2.6. Monitoring 351 A QUIC implementation should monitor the ECN functionality in order 352 to provide input to e.g. service providers to improve ECN support in 353 the networks. Items of interest are: 355 o Black holes, ECT or CE marked packets are discarded. 357 o Faulty remarking, e.g. ECT(0) is remarked to ECT(1) or Not-ECT. 359 o Continuous CE marking, possible indication of faulty on/off ECN 360 marking, but can also be an effect of severe congestion. 362 o Degree of L4S support. L4S should generally give low queue 363 latency. Estimation of one way queue delay for L4S enabled QUIC 364 connections can be used to determine if there are congested nodes 365 along the path that are not L4S capable. 367 3. IANA Considerations 369 T.B.D. 371 4. Open questions 373 A list of open questions: 375 o Is it sufficient that one peer sends an ECN negotiation challenge 376 frame?. 378 o Should all packets be ECT or should there be special patterns to 379 improve fault detection. 381 o Write up a more detailed description on how to implement ECN 382 support in QUIC for different OS stacks. 384 o Is a completely new ACK frame an alternative ? 386 o Should amount on ECT(0), ECT(1) and CE marked bytes account for 387 the IP+UDP headers or is it only the QUIC header + data that 388 counts ? 390 o Outline possible connection migration actions 392 o Are there any security implications with the small ECN negotiation 393 frame ? 395 5. Security Considerations 397 T.B.D 399 6. Acknowledgements 401 The following persons have contributed with comments and suggestions 402 for improvements: Mirja Kuehlewind, Koen De Schepper, Piers O'Hanlon, 403 Michael Welzl, Marcelo Bagnulo Braun, Martin Duke 405 7. References 407 7.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 7.2. Informative References 416 [APPLE-ECN] 417 Apple Inc., "TCP ECN: Experience with Enabling ECN on the 418 Internet", . 422 [Bagnulo] "Adding Explicit Congestion Notification (ECN) to TCP 423 control packets and TCP retransmissions", 424 . 427 [ECN-fallback] 428 "A Mechanism for ECN Path Probing and Fallback", 429 . 432 [I-D.ietf-aqm-ecn-benefits] 433 Fairhurst, G. and M. Welzl, "The Benefits of using 434 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 435 ecn-benefits-08 (work in progress), November 2015. 437 [I-D.ietf-quic-transport] 438 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 439 and Secure Transport", draft-ietf-quic-transport-03 (work 440 in progress), May 2017. 442 [I-D.ietf-tsvwg-ecn-experimentation] 443 Black, D., "Explicit Congestion Notification (ECN) 444 Experimentation", draft-ietf-tsvwg-ecn-experimentation-02 445 (work in progress), April 2017. 447 [McQuistin-Perkins] 448 ""Is Explicit Congestion Notification usable with UDP?", 449 Proceedings of the ACM Internet Measurement Conference, 450 Tokyo, Japan, October 2015. DOI:10.1145/2815675.2815716", 451 . 454 [OHanlon] "ECN support in different OS stacks", 455 . 458 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 459 and K. Carlberg, "Explicit Congestion Notification (ECN) 460 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 461 2012, . 463 [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., 464 "Congestion Exposure (ConEx) Concepts and Use Cases", 465 RFC 6789, DOI 10.17487/RFC6789, December 2012, 466 . 468 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 469 "Problem Statement and Requirements for Increased Accuracy 470 in Explicit Congestion Notification (ECN) Feedback", 471 RFC 7560, DOI 10.17487/RFC7560, August 2015, 472 . 474 Author's Address 476 Ingemar Johansson 477 Ericsson AB 478 Laboratoriegraend 11 479 Luleaa 977 53 480 Sweden 482 Phone: +46 730783289 483 Email: ingemar.s.johansson@ericsson.com