idnits 2.17.1 draft-ferrieuxhamchaoui-tsvwg-lossbits-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 date (July 28, 2020) is 1367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-11 == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-21) exists of draft-ietf-tsvwg-transport-encrypt-16 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-08 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG A. Ferrieux, Ed. 3 Internet-Draft I. Hamchaoui, Ed. 4 Intended status: Informational Orange Labs 5 Expires: January 29, 2021 I. Lubashev, Ed. 6 Akamai Technologies 7 D. Tikhonov, Ed. 8 LiteSpeed Technologies 9 July 28, 2020 11 Packet Loss Signaling for Encrypted Protocols 12 draft-ferrieuxhamchaoui-tsvwg-lossbits-03 14 Abstract 16 This document describes a protocol-independent method that employs 17 two bits to allow endpoints to signal packet loss in a way that can 18 be used by network devices to measure and locate the source of the 19 loss. The signaling method applies to all protocols with a protocol- 20 specific way to identify packet loss. The method is especially 21 valuable when applied to protocols that encrypt transport header and 22 do not allow an alternative method for loss detection. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 29, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation for Passive On-Path Loss Observation . . . . . 3 60 1.2. On-Path Loss Observation . . . . . . . . . . . . . . . . 3 61 1.3. On-Path Loss Signaling . . . . . . . . . . . . . . . . . 4 62 1.4. Recommended Use of the Signals . . . . . . . . . . . . . 4 63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 64 3. Loss Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Setting the sQuare Bit on Outgoing Packets . . . . . . . 5 66 3.1.1. Q Run Length Selection . . . . . . . . . . . . . . . 5 67 3.2. Setting the Loss Event Bit on Outgoing Packets . . . . . 5 68 4. Using the Loss Bits for Passive Loss Measurement . . . . . . 6 69 4.1. End-To-End Loss . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. Upstream Loss . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3. Correlating End-to-End and Upstream Loss . . . . . . . . 7 72 4.4. Downstream Loss . . . . . . . . . . . . . . . . . . . . . 7 73 4.5. Observer Loss . . . . . . . . . . . . . . . . . . . . . . 7 74 5. ECN-Echo Event Bit . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Setting the ECN-Echo Event Bit on Outgoing Packets . . . 8 76 5.2. Using E Bit for Passive ECN-Reported Congestion 77 Measurement . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Protocol Ossification Considerations . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7.1. Optimistic ACK Attack . . . . . . . . . . . . . . . . . . 10 81 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 10.1. Since version 02 . . . . . . . . . . . . . . . . . . . . 10 85 10.2. Since version 01 . . . . . . . . . . . . . . . . . . . . 11 86 10.3. Since version 00 . . . . . . . . . . . . . . . . . . . . 11 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 12.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 1.1. Motivation for Passive On-Path Loss Observation 97 Packet loss is hard and pervasive problem of day-to-day network 98 operation. Proactively detecting, measuring, and locating it is 99 crucial to maintaining high QoS and timely resolution of crippling 100 end-to-end throughput issues. To this effect, in a TCP-dominated 101 world, network operators have been heavily relying on information 102 present in the clear in TCP headers: sequence and acknowledgment 103 numbers and SACKs when enabled (see [RFC8517]). These allow for 104 quantitative estimation of packet loss by passive on-path 105 observation. Additionally, the lossy segment (upstream or downstream 106 from the observation point) can be quickly identified by moving the 107 passive observer around. 109 With encrypted protocols, the equivalent transport headers are 110 encrypted and passive packet loss observation is not possible, as 111 described in [TRANSPORT-ENCRYPT]. 113 Measuring TCP loss between similar endpoints cannot be relied upon to 114 evaluate encrypted protocol loss. Different protools could be routed 115 by the network differently and the fraction of Internet traffic 116 delivered using protocols other than TCP is increasing every year. 117 It is imperative to measure packet loss experienced by encrypted 118 protocol users directly. 120 1.2. On-Path Loss Observation 122 There are three sources of loss that network operators need to 123 observe to guarantee high QoS: 125 - _upstream loss_ - loss between the sender and the observation 126 point (Section 4.2) 128 - _downstream loss_ - loss between the observation point and the 129 destination (Section 4.4) 131 - _observer loss_ - loss by the observer itself that does not cause 132 downstream loss (Section 4.5) 134 The upstream and downstream loss together constitute _end-to-end 135 loss_ (Section 4.1). 137 1.3. On-Path Loss Signaling 139 Following the recommendation in [RFC8558] of making path signals 140 explicit, this document proposes adding two explicit loss bits to the 141 clear portion of the protocol headers to restore network operators' 142 ability to maintain high QoS. These bits can be added to an 143 unencrypted portion of a header belonging to any protocol layer, e.g. 144 IP (see [IP]) and IPv6 (see [IPv6]) headers or extensions, such as 145 [IPv6AltMark], UDP surplus space (see [UDP-OPTIONS] and 146 [UDP-SURPLUS]), reserved bits in a QUIC v1 header (see 147 [QUIC-TRANSPORT]). 149 1.4. Recommended Use of the Signals 151 The loss signal is not designed for use in automated control of the 152 network in environments where loss bits are set by untrusted hosts, 153 Instead, the signal is to be used for troubleshooting individual 154 flows as well as for monitoring the network by aggregating 155 information from multiple flows and raising operator alarms if 156 aggregate statistics indicate a potential problem. 158 2. Notational Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. Loss Bits 166 The draft introduces two bits that are to be present in packets 167 capable of loss reporting. These are packets that include protocol 168 headers with the loss bits. Only loss of packets capable of loss 169 reporting is reported using loss bits. 171 Whenever this specification refers to packets, it is referring only 172 to packets capable of loss reporting. 174 - Q: The "sQuare signal" bit is toggled every N outgoing packets as 175 explained below in Section 3.1. 177 - L: The "Loss event" bit is set to 0 or 1 according to the 178 Unreported Loss counter, as explained below in Section 3.2. 180 Each endpoint maintains appropriate counters independently and 181 separately for each separately identifiable flow (each subflow for 182 multipath connections). 184 3.1. Setting the sQuare Bit on Outgoing Packets 186 The sQuare Value is initialized to the Initial Q Value (0) and is 187 reflected in the Q bit of every outgoing packet. The sQuare value is 188 inverted after sending every N packets (a Q Run). Hence, Q Period is 189 2*N. The Q bit represents "packet color" as defined by [RFC8321]. 190 The sQuare Bit can also be called an Alernate Marking bit. 192 Observation points can estimate the upstream losses by counting the 193 number of packets during a half period of the square signal, as 194 described in Section 4. 196 3.1.1. Q Run Length Selection 198 The sender is expected to choose N (Q run length) based on the 199 expected amount of loss and reordering on the path. The choice of N 200 strikes a compromise - the observation could become too unreliable in 201 case of packet reordering and/or severe loss if N is too small, while 202 short flows may not yield a useful upstream loss measurement if N is 203 too large (see Section 4.2). 205 The value of N MUST be at least 64 and be a power of 2. This 206 requirement allows an Observer to infer the Q run length by observing 207 one period of the square signal. It also allows the Observer to 208 identify flows that set the loss bits to arbitrary values (see 209 Section 6). 211 If the sender does not have sufficient information to make an 212 informed decision about Q run length, the sender SHOULD use N=64, 213 since this value has been extensively tried in large-scale field 214 tests and yielded good results. Alternatively, the sender MAY also 215 choose a random N for each flow, increasing the chances of using a Q 216 run length that gives the best signal for some flows. 218 The sender MUST keep the value of N constant for a given flow. 220 3.2. Setting the Loss Event Bit on Outgoing Packets 222 The Unreported Loss counter is initialized to 0, and L bit of every 223 outgoing packet indicates whether the Unreported Loss counter is 224 positive (L=1 if the counter is positive, and L=0 otherwise). The 225 value of the Unreported Loss counter is decremented every time a 226 packet with L=1 is sent. 228 The value of the Unreported Loss counter is incremented for every 229 packet that the protocol declares lost, using whatever loss detection 230 machinery the protocol employs. If the protocol is able to rescind 231 the loss determination later, a positive Unreported Loss counter MAY 232 be decremented due to the rescission, but it SHOULD NOT become 233 negative due to the rescission. 235 This loss signaling is similar to loss signaling in [ConEx], except 236 the Loss Event bit is reporting the exact number of lost packets, 237 whereas Echo Loss bit in [ConEx] is reporting an approximate number 238 of lost bytes. 240 For protocols, such as TCP ([TCP]), that allow network devices to 241 change data segmentation, it is possible that only a part of the 242 packet is lost. In these cases, the sender MUST increment Unreported 243 Loss counter by the fraction of the packet data lost (so Unreported 244 Loss counter may become negative when a packet with L=1 is sent after 245 a partial packet has been lost). 247 Observation points can estimate the end-to-end loss, as determined by 248 the upstream endpoint, by counting packets in this direction with the 249 L bit equal to 1, as described in Section 4. 251 4. Using the Loss Bits for Passive Loss Measurement 253 4.1. End-To-End Loss 255 The Loss Event bit allows an observer to calculate the end-to-end 256 loss rate by counting packets with L bit value of 0 and 1 for a given 257 flow. The end-to-end loss rate is the fraction of packets with L=1. 259 The assumption here is that upstream loss affects packets with L=0 260 and L=1 equally. If some loss is caused by tail-drop in a network 261 device, this may be a simplification. If the sender's congestion 262 controller reduces the packet send rate after loss, there may be a 263 sufficient delay before sending packets with L=1 that they have a 264 greater chance of arriving at the observer. 266 4.2. Upstream Loss 268 Blocks of N (Q Run length) consecutive packets are sent with the same 269 value of the Q bit, followed by another block of N packets with an 270 inverted value of the Q bit. Hence, knowing the value of N, an on- 271 path observer can estimate the amount of upstream loss after 272 observing at least N packets. The upstream loss rate ("u") is one 273 minus the average number of packets in a block of packets with the 274 same Q value ("p") divided by N ("u=1-avg(p)/N"). 276 The observer needs to be able to tolerate packet reordering that can 277 blur the edges of the square signal. 279 The observer needs to differentiate packets as belonging to different 280 flows, since they use independent counters. 282 4.3. Correlating End-to-End and Upstream Loss 284 Upstream loss is calculated by observing packets that did not suffer 285 the upstream loss. End-to-end loss, however, is calculated by 286 observing subsequent packets after the sender's protocol detected the 287 loss. Hence, end-to-end loss is generally observed with a delay of 288 between 1 RTT (loss declared due to multiple duplicate 289 acknowledgments) and 1 RTO (loss declared due to a timeout) relative 290 to the upstream loss. 292 The flow RTT can sometimes be estimated by timing protocol handshake 293 messages. This RTT estimate can be greatly improved by observing a 294 dedicated protocol mechanism for conveying RTT information, such as 295 the Latency Spin bit of [QUIC-TRANSPORT]. 297 Whenever the observer needs to perform a computation that uses both 298 upstream and end-to-end loss rate measurements, it SHOULD use 299 upstream loss rate leading the end-to-end loss rate by approximately 300 1 RTT. If the observer is unable to estimate RTT of the flow, it 301 should accumulate loss measurements over time periods of at least 4 302 times the typical RTT for the observed flows. 304 If the calculated upstream loss rate exceeds the end-to-end loss rate 305 calculated in Section 4.1, then either the Q Period is too short for 306 the amount of packet reordering or there is observer loss, described 307 in Section 4.5. If this happens, the observer SHOULD adjust the 308 calculated upstream loss rate to match end-to-end loss rate. 310 4.4. Downstream Loss 312 Because downstream loss affects only those packets that did not 313 suffer upstream loss, the end-to-end loss rate ("e") relates to the 314 upstream loss rate ("u") and downstream loss rate ("d") as 315 "(1-u)(1-d)=1-e". Hence, "d=(e-u)/(1-u)". 317 4.5. Observer Loss 319 A typical deployment of a passive observation system includes a 320 network tap device that mirrors network packets of interest to a 321 device that performs analysis and measurement on the mirrored 322 packets. The observer loss is the loss that occurs on the mirror 323 path. 325 Observer loss affects upstream loss rate measurement since it causes 326 the observer to account for fewer packets in a block of identical Q 327 bit values (see {{upstreamloss)}). The end-to-end loss rate 328 measurement, however, is unaffected by the observer loss, since it is 329 a measurement of the fraction of packets with the set L bit value, 330 and the observer loss would affect all packets equally (see 331 Section 4.1). 333 The need to adjust the upstream loss rate down to match end-to-end 334 loss rate as described in Section 4.3 is a strong indication of the 335 observer loss, whose magnitude is between the amount of such 336 adjustment and the entirety of the upstream loss measured in 337 Section 4.2. Alternatively, a high apparent upstream loss rate could 338 be an indication of significant reordering, possibly due to packets 339 belonging to a single flow being multiplexed over several upstream 340 paths with different latency characteristics. 342 5. ECN-Echo Event Bit 344 While the primary focus of the draft is on exposing packet loss, 345 modern networks can report congestion before they are forced to drop 346 packets, as described in [ECN]. When transport protocols keep ECN- 347 Echo feedback under encryption, this signal cannot be observed by the 348 network operators. When tasked with diagnosing network performance 349 problems, knowledge of a congestion downstream of an observation 350 point can be instrumental. 352 If downstream congestion information is desired, this information can 353 be signaled with an additional bit. 355 - E: The "ECN-Echo Event" bit is set to 0 or 1 according to the 356 Unreported ECN Echo counter, as explained below in Section 5.1. 358 5.1. Setting the ECN-Echo Event Bit on Outgoing Packets 360 The Unreported ECN-Echo counter operates identicaly to Unreported 361 Loss counter (Section 3.2), except it counts packets delivered by the 362 network with CE markings, according to the ECN-Echo feedback from the 363 receiver. 365 This ECN-Echo signaling is similar to ECN signaling in [ConEx]. ECN- 366 Echo mechanism in QUIC provides the number of packets received with 367 CE marks. For protocols like TCP, the method described in 368 [ConEx-TCP] can be employed. As stated in [ConEx-TCP], such feedback 369 can be further improved using a method described in [ACCURATE]. 371 5.2. Using E Bit for Passive ECN-Reported Congestion Measurement 373 A network observer can count packets with CE codepoint and determine 374 the upstream CE-marking rate directly. 376 Observation points can also estimate ECN-reported end-to-end 377 congestion by counting packets in this direction with a E bit equal 378 to 1. 380 The upstream CE-marking rate and end-to-end ECN-reported congestion 381 can provide information about downstream CE-marking rate. Presence 382 of E bits along with L bits, however, can somewhat confound precise 383 estimates of upstream and downstream CE-markings in case the flow 384 contains packets that are not ECN-capable. 386 6. Protocol Ossification Considerations 388 Accurate loss information is not critical to the operation of any 389 protocol, though its presence for a sufficient number of flows is 390 important for the operation of networks. 392 The loss bits are amenable to "greasing" described in [RFC8701], if 393 the protocol designers are not ready to dedicate (and ossify) bits 394 used for loss reporting to this function. The greasing could be 395 accomplished similarly to the Latency Spin bit greasing in 396 [QUIC-TRANSPORT]. Namely, implementations could decide that a 397 fraction of flows should not encode loss information in the loss bits 398 and, instead, the bits would be set to arbitrary values. The 399 observers would need to be ready to ignore flows with loss 400 information more resembling noise than the expected signal. 402 7. Security Considerations 404 Passive loss observation has been a part of the network operations 405 for a long time, so exposing loss information to the network does not 406 add new security concerns for protocols that are currently 407 observable. 409 In the absence of upstream packet loss, the Q bit signal does not 410 provide any information that cannot be observed by simply counting 411 packets transiting a network path. In the presence of upstream 412 packet loss, the Q bit will disclose the loss, but this is 413 information about the environment and not the endpoint state. The L 414 bit signal discloses internal state of the protocol's loss detection 415 machinery, but this state can often be gleamed by timing packets and 416 observing congestion controller response. Hence, loss bits do not 417 provide a viable new mechanism to attack data integrity and secrecy. 419 7.1. Optimistic ACK Attack 421 A defense against an Optimistic ACK Attack, decribed in 422 [QUIC-TRANSPORT], involves a sender randomly skipping packet numbers 423 to detect a receiver acknowledging packet numbers that have never 424 been received. The Q bit signal may inform the attacker which packet 425 numbers were skipped on purpose and which had been actually lost (and 426 are, therefore, safe for the attacker to acknowledge). To use the Q 427 bit for this purpose, the attacker must first receive at least an 428 entire Q Run of packets, which renders the attack ineffective against 429 a delay-sensitive congestion controller. 431 A protocol that is more susceptible to an Optimistic ACK Attack with 432 the loss signal provided by Q bit and uses a loss-based congestion 433 controller, SHOULD shorten the current Q Run by the number of skipped 434 packets numbers. For example, skipping a single packet number will 435 invert the sQuare signal one outgoing packet sooner. 437 8. Privacy Considerations 439 To minimize unintentional exposure of information, loss bits provide 440 an explicit loss signal - a preferred way to share information per 441 [RFC8558]. 443 New protocols commonly have specific privacy goals, and loss 444 reporting must ensure that loss information does not compromise those 445 privacy goals. For example, [QUIC-TRANSPORT] allows changing 446 Connection IDs in the middle of a connection to reduce the likelihood 447 of a passive observer linking old and new subflows to the same 448 device. A QUIC implementation would need to reset all counters when 449 it changes the destination (IP address or UDP port) or the Connection 450 ID used for outgoing packets. It would also need to avoid 451 incrementing Unreported Loss counter for loss of packets sent to a 452 different destination or with a different Connection ID. 454 9. IANA Considerations 456 This document makes no request of IANA. 458 10. Change Log 460 10.1. Since version 02 462 - Minor improvement and clarifications 464 10.2. Since version 01 466 - Clarified Q Period selection 468 - Added an optional E (ECN-Echo Event) bit 470 - Clarified L bit calculation for protocols that allow partial data 471 loss due to a change in segmentation (such as TCP) 473 10.3. Since version 00 475 - Addressed review comments 477 - Improved guidelines for privacy protections for QIUC 479 11. Acknowledgments 481 The sQuare bit was originally suggested by Kazuho Oku in early 482 proposals for loss measurement and is an instance of the "alternate 483 marking" as defined in [RFC8321]. 485 12. References 487 12.1. Normative References 489 [ConEx] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 490 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 491 DOI 10.17487/RFC7713, December 2015, 492 . 494 [ConEx-TCP] 495 Kuehlewind, M., Ed. and R. Scheffenegger, "TCP 496 Modifications for Congestion Exposure (ConEx)", RFC 7786, 497 DOI 10.17487/RFC7786, May 2016, 498 . 500 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 501 of Explicit Congestion Notification (ECN) to IP", 502 RFC 3168, DOI 10.17487/RFC3168, September 2001, 503 . 505 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 506 DOI 10.17487/RFC0791, September 1981, 507 . 509 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 510 (IPv6) Specification", STD 86, RFC 8200, 511 DOI 10.17487/RFC8200, July 2017, 512 . 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 520 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 521 "Alternate-Marking Method for Passive and Hybrid 522 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 523 January 2018, . 525 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 526 RFC 8558, DOI 10.17487/RFC8558, April 2019, 527 . 529 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 530 RFC 793, DOI 10.17487/RFC0793, September 1981, 531 . 533 12.2. Informative References 535 [ACCURATE] 536 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 537 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 538 ecn-11 (work in progress), March 2020. 540 [IPv6AltMark] 541 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 542 Pang, "IPv6 Application of the Alternate Marking Method", 543 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 544 2020. 546 [QUIC-TRANSPORT] 547 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 548 and Secure Transport", draft-ietf-quic-transport-29 (work 549 in progress), June 2020. 551 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 552 Jacquenet, "An Inventory of Transport-Centric Functions 553 Provided by Middleboxes: An Operator Perspective", 554 RFC 8517, DOI 10.17487/RFC8517, February 2019, 555 . 557 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 558 Sustain Extensibility (GREASE) to TLS Extensibility", 559 RFC 8701, DOI 10.17487/RFC8701, January 2020, 560 . 562 [TRANSPORT-ENCRYPT] 563 Fairhurst, G. and C. Perkins, "Considerations around 564 Transport Header Confidentiality, Network Operations, and 565 the Evolution of Internet Transport Protocols", draft- 566 ietf-tsvwg-transport-encrypt-16 (work in progress), July 567 2020. 569 [UDP-OPTIONS] 570 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 571 udp-options-08 (work in progress), September 2019. 573 [UDP-SURPLUS] 574 Herbert, T., "UDP Surplus Header", draft-herbert-udp- 575 space-hdr-01 (work in progress), July 2019. 577 Authors' Addresses 579 Alexandre Ferrieux (editor) 580 Orange Labs 582 EMail: alexandre.ferrieux@orange.com 584 Isabelle Hamchaoui (editor) 585 Orange Labs 587 EMail: isabelle.hamchaoui@orange.com 589 Igor Lubashev (editor) 590 Akamai Technologies 592 EMail: ilubashe@akamai.com 594 Dmitri Tikhonov (editor) 595 LiteSpeed Technologies 597 EMail: dtikhonov@litespeedtech.com