idnits 2.17.1 draft-sharabayko-srt-over-quic-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7323], [QUIC-DATAGRAM], [SRTRFC], [RFC9000]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 July 2021) is 1003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group M.P. Sharabayko 3 Internet-Draft M.A. Sharabayko 4 Intended status: Informational Haivision Network Video, GmbH 5 Expires: 29 January 2022 28 July 2021 7 Tunnelling SRT over QUIC 8 draft-sharabayko-srt-over-quic-00 10 Abstract 12 This document presents an approach to tunnelling SRT live streams 13 over QUIC datagrams. 15 QUIC [RFC9000] is a UDP-based transport protocol providing TLS 16 encryption, stream multiplexing, and connection migration. It was 17 designed to become a faster alternative to the TCP protocol 18 [RFC7323]. 20 An Unreliable Datagram Extension to QUIC [QUIC-DATAGRAM] adds support 21 for sending and receiving unreliable datagrams over a QUIC 22 connection, but transfers the responsibility for multiplexing 23 different kinds of datagrams, or flows of datagrams, to an 24 application protocol. 26 SRT [SRTRFC] is a UDP-based transport protocol. Essentially, it can 27 operate over any unreliable datagram transport. SRT provides loss 28 recovery and stream multiplexing mechanisms. In its live streaming 29 configuration SRT provides an end-to-end latency-aware mechanism for 30 packet loss recovery. If SRT fails to recover a packet loss within a 31 specified latency, then the packet is dropped to avoid blocking 32 playback of further packets. 34 The Datagram Extension to QUIC could be used as an underlying 35 transport instead of UDP. This way QUIC would provide TLS-level 36 security, connection migration, and potentially multi-path support. 37 It would be easier for existing network facilities to process, route, 38 and load balance the unified QUIC traffic. SRT on its side would 39 provide end-to-end latency tracking and latency-aware loss recovery. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 29 January 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. SRT for Low Latency . . . . . . . . . . . . . . . . . . . 3 76 1.2. QUIC for Universal Transport . . . . . . . . . . . . . . 3 77 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 78 3. Use Cases for SRT over QUIC . . . . . . . . . . . . . . . . . 4 79 4. Tunnelling SRT over QUIC . . . . . . . . . . . . . . . . . . 4 80 4.1. Overhead . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.2. Packet Integrity . . . . . . . . . . . . . . . . . . . . 6 82 4.3. Connection Establishment . . . . . . . . . . . . . . . . 6 83 4.4. Bidirectional Transmission . . . . . . . . . . . . . . . 7 84 4.5. Congestion Control . . . . . . . . . . . . . . . . . . . 7 85 4.6. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.7. Connection Mitigation . . . . . . . . . . . . . . . . . . 8 87 4.8. Datagram vs H3 Datagram . . . . . . . . . . . . . . . . . 8 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 Normative References . . . . . . . . . . . . . . . . . . . . . 8 93 Informative References . . . . . . . . . . . . . . . . . . . . 9 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 97 1. Introduction 99 1.1. SRT for Low Latency 101 The Secure Reliable Transport (SRT) protocol [SRTRFC] is a 102 connection-based transport protocol that enables the secure, reliable 103 transport of data across unpredictable networks, such as the 104 Internet. While any data type can be transferred via SRT, it is 105 ideal for low latency (sub-second) video streaming. SRT enables high 106 contribution bitrates over long distance connections. 108 To achieve low latency streaming, SRT addresses timing issues. The 109 characteristics of a stream from a source network can be notably 110 changed by transmission over the public Internet, introducing delays, 111 jitter, and packet loss. This, in turn, leads to problems with 112 decoding, as audio and video decoders do not receive packets at the 113 expected pace. The use of large buffers helps, but latency is 114 increased. SRT includes a mechanism to keep a constant end-to-end 115 latency, thus recreating the signal characteristics on the receiver 116 side, and reducing the need for buffering. 118 SRT employs a listener (server) / caller (client) model. The data 119 flow is bi-directional and independent of the connection initiation - 120 either the sender or receiver can operate as listener or caller to 121 initiate a connection. 123 The SRT protocol provides an internal multiplexing mechanism, 124 allowing multiple SRT connections to share the same UDP port, 125 providing access control functionality to identify the caller on the 126 listener side. This mechanism is exactly what QUIC DATAGRAM 127 describes as a responsibility of the application protocol. 129 Supporting forward error correction (FEC) and selective packet 130 retransmission (ARQ), SRT provides the flexibility to use either of 131 the two mechanisms or both combined, allowing for use cases ranging 132 from the lowest possible latency to the highest possible reliability. 134 SRT also allows fast file transfers, and adds support for AES 135 encryption. 137 1.2. QUIC for Universal Transport 139 The QUIC transport protocol [RFC9000] is a connection-based transport 140 protocol built on top of UDP. It provides a workflow similar to that 141 of TCP, but for modern fast networks. 143 TODO: Add more details to the current section. Write about lower 144 connection times, faster delivery, ARQ, CC, etc. 146 2. Terms and Definitions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 SRT: The Secure Reliable Transport protocol. 156 3. Use Cases for SRT over QUIC 158 SRT itself is very close to QUIC, and provides similar transport 159 mechanisms. However, the main focus of SRT is on low-latency live 160 contribution and distribution. SRT is widely used by various 161 broadcasters to enable low-latency streaming of live events. It is 162 also used in various mobile and IoT devices to get low-latency 163 feedback and live feeds. 165 QUIC is supported by CDN companies. Many facilities know how to 166 handle and route QUIC traffic. QUIC provides certain security 167 advantages (TLS, encrypting headers so that traffic is not 168 distinguishable). 170 SRT tunnelled over QUIC allows managing live delivery mechanisms 171 (preserving end-to-end latency and dropping "too late" data). 173 4. Tunnelling SRT over QUIC 175 The QUIC DATAGRAM frame is structured as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | [Length (i)] ... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Datagram Data (*) ... 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: QUIC DATAGRAM Frame Format 187 Length. A variable-length integer specifying the length of the 188 datagram in bytes. 190 Datagram Data. The bytes of the datagram to be delivered. 192 The structure of the SRT packet is shown in Figure 2. For SRT over 193 QUIC tunnelling the full SRT packet is placed inside the Datagram 194 Data field. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |F| (Field meaning depends on the packet type) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | (Field meaning depends on the packet type) | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Timestamp | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Destination Socket ID | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 + Packet Contents | 209 | (depends on the packet type) + 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: SRT Packet Structure 215 F: 1 bit. Packet Type Flag. A control packet has this flag set to 216 "1". A data packet has this flag set to "0". 218 Timestamp: 32 bits. The timestamp of the packet, in microseconds. 219 The value is relative to the time the SRT connection was 220 established. Depending on the transmission mode, the field stores 221 the packet send time or the packet origin time. 223 Destination Socket ID: 32 bits. A fixed-width field providing the 224 SRT socket ID to which a packet should be dispatched. The field 225 may have the special value "0" when the packet is a connection 226 request. 228 Packet Contents. Packet Contents as per packet type. 230 4.1. Overhead 232 An SRT data packet has a 16-byte header, which adds to the payload of 233 a QUIC packet. 235 For example, let us consider a payload size of 1128 bytes (six 236 188-byte MPEG-TS packets). For a 20 Mbps stream, knowing that each 237 data packet gets an additional 16 bytes of overhead, SRT would 238 provide an overhead of only ~280 kbits/s (or 1.4%). 240 Increasing the size of the payload, e.g., to 1316 bytes (seven 241 188-byte MPEG-TS packets), SRT overhead at 20 Mbps would be ~240 242 kbits/s (or 1.2%). 244 An SRT receiver also sends a full ACK packet every 10 ms. The size 245 of the ACK packet is 44 bytes. This traffic goes in the opposite 246 direction: from the payload receiver to the payload sender. The 247 payload sender responds to every ACK packet with a corresponding 248 16-byte ACKACK packet. This gives an additional 1600 bytes per 249 second, which may be considered negligible. 251 4.2. Packet Integrity 253 SRT does not provide mechanisms to verify the integrity of packets, 254 nor to distinguish a packet from a continuous data stream. SRT 255 assumes that the underlying transport protocol delivers a single and 256 undamaged packet to SRT. Therefore, the underlying transport MUST 257 provide a mechanism for SRT to send and receive exactly one packet. 259 One SRT packet MUST be sent over exactly one QUIC Datagram frame. 261 4.3. Connection Establishment 263 QUIC has a fast and secure crypto handshake based on TLS. A client 264 connects to a server, and it can verify the server based on its 265 certificate. A new client connection takes two times the RTT to be 266 established. If a client connects to a known server, then it can try 267 to establish a faster 0-RTT connection. 269 Once a QUIC connection is established, QUIC datagrams can be sent in 270 both directions. SRT can use this QUIC datagram tunnelling to 271 establish one or many connections on its own. Each SRT connection 272 would take two times the RTT for handshaking. 274 The first handshake round of SRT is intended to get an initial 275 response from the server, identifying handshake procedure version and 276 getting a cookie from the server (listener) to mitigate potential DoS 277 attacks. Apart from that, no viable data is exchanged during this 278 first "induction" handshake phase. 280 If an SRT connection is established over an established and verified 281 QUIC connection, the SRT connection time could be reduced to a single 282 RTT interval if only the "conclusion" handshaking phase is performed. 283 However SRT does not currently provide this functionality, thus 284 appropriate modifications are required. 286 4.4. Bidirectional Transmission 288 Both QUIC and SRT allow bidirectional transmission of a payload over 289 a single SRT connection. Even with a payload sent in one direction, 290 some control packets are still sent in the opposite direction over 291 the same connection. 293 4.5. Congestion Control 295 QUIC as a transport mechanism can apply congestion control. It is 296 worth noting, however, the specifics of live streaming compared to 297 file-based transmissions. The payload is not available right away, 298 therefore using regular bandwidth probing mechanisms to increase or 299 decrease the sending rate would not work. 301 The current sending rate is provided by SRT, which in turn receives 302 the payload from a live source and can add some overhead when 303 retransmission of lost packets is performed. 305 However, QUIC can use congestion control to detect congestion and 306 throughput bottlenecks, and prevent sending above a certain limit. 307 SRT MUST handle such cases by eventually dropping packets, which can 308 no longer be recovered. 310 It would make sense for a QUIC connection to provide this throughput 311 limitation value back to SRT. In that case SRT could use the number 312 to make clever and transport-aware retransmission decisions. 314 It is also possible for QUIC to not apply any congestion control, 315 relying on SRT. However, SRT does not reduce the sending rate below 316 the input rate. If the bitrate of the original stream already 317 exceeds network throughput, SRT would still try to deliver it, 318 maintaining congestion and eventually breaking the SRT connection. 320 It is worth mentioning that in a live streaming scenario it may be 321 beneficial to move congestion control mechanisms outside of the 322 protocol towards the encoder (payload producer), implementing a 323 network adaptive encoding based on the telemetry provided by the SRT 324 and QUIC protocols. 326 4.6. Pacing 328 SRT uses ACK/ACKACK packet pairs to measure RTT on a link, and to 329 track latency and clock drift. It also uses packet pair probing to 330 estimate connection bandwidth, although in live configurations such 331 estimates are informative only. 333 Buffering and pacing of SRT packets by QUIC SHOULD be done with the 334 understanding that this would interfere with the corresponding SRT 335 mechanisms. Alternatively, SRT may implement a pacer on top of 336 QUIC's congestion control and probing mechanisms to abstract the 337 complexity associated with live streaming use cases. 339 4.7. Connection Mitigation 341 QUIC utilizes Connection UUID to distinguish between connections 342 (compared to the IP:Port scheme used by UDP and TCP). This enables 343 already established connections to be handed over seamlessly across 344 network interfaces without requiring a new handshake/negotiation. 345 SRT may expand on this to enable network bonded delivery workflows to 346 switch between optimal transports without a latency hit. 348 4.8. Datagram vs H3 Datagram 350 As an alternative to using the QUIC Datagram extension, it might be 351 possible to consider the H3 Datagram version in order to be 352 compatible with more existing load balancers. 354 5. Security Considerations 356 TODO 358 6. IANA Considerations 360 TODO 362 Acknowledgments 364 It is worth acknowledging the participation of the following people 365 in the project discussions: Ying Yin (Google), Ian Swett (Google), 366 Victor Vasiliev (Google), Kazuko Oku (Fastly), Marc Cymontkowski 367 (Haivision), Nikos Kyriopoulos (Haivision), Jake Weissman (Facebook), 368 Jordi Cenzano (Facebook), Alan Frindell (Facebook), Jeongseok Kim (SK 369 Telecom), Joonwoong Kim (SK Telecom). 371 Quicly library [QUICLY] from Fastly was chosen to provide a QUIC 372 datagram transport layer for SRT over QUIC PoC. We would like to 373 thank Kazuho Oku (Fastly) for his help. 375 References 377 Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 385 Scheffenegger, Ed., "TCP Extensions for High Performance", 386 RFC 7323, DOI 10.17487/RFC7323, September 2014, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 394 Multiplexed and Secure Transport", RFC 9000, 395 DOI 10.17487/RFC9000, May 2021, 396 . 398 Informative References 400 [QUIC-DATAGRAM] 401 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 402 Datagram Extension to QUIC", n.d., 403 . 406 [QUICLY] "QUIC protocol implementation quicly for H2O server", July 407 2021, . 409 [SRTRFC] Sharabayko, M., Sharabayko, M., Dube, J., Kim, J., and J. 410 Kim, "The SRT Protocol", December 2019, 411 . 413 Authors' Addresses 415 Maxim Sharabayko 416 Haivision Network Video, GmbH 418 Email: maxsharabayko@haivision.com 420 Maria Sharabayko 421 Haivision Network Video, GmbH 423 Email: msharabayko@haivision.com