idnits 2.17.1 draft-rtpfolks-quic-rtp-over-quic-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 285: '...ation mechanisms MUST provide boundari...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2017) is 2427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-05 == Outdated reference: A later version (-16) exists of draft-ietf-avtext-framemarking-05 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-05 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-00 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-coupled-cc-06 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-nada-04 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-scream-cc-10 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-18 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Ott 3 Internet-Draft TUM 4 Intended status: Standards Track R. Even 5 Expires: March 5, 2018 Huawei 6 C. Perkins 7 University of Glasgow 8 V. Singh 9 callstats.io 10 September 1, 2017 12 RTP over QUIC 13 draft-rtpfolks-quic-rtp-over-quic-01 15 Abstract 17 QUIC is a UDP-based protocol for congestion controlled reliable data 18 transfer, while RTP serves carrying (conversational) real-time media 19 over UDP. This draft discusses design aspects and issues of carrying 20 RTP over QUIC. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 5, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Use Cases for RTP over QUIC . . . . . . . . . . . . . . . . . 3 58 3. RTP-to-Transport Interface . . . . . . . . . . . . . . . . . 4 59 4. RTP-to-QUIC Mapping . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Mapping Semantic Units . . . . . . . . . . . . . . . . . 6 61 4.2. Encapsulating Media Units . . . . . . . . . . . . . . . . 6 62 4.3. Mapping Media to Streams . . . . . . . . . . . . . . . . 7 63 4.4. Mapping RTCP packets . . . . . . . . . . . . . . . . . . 8 64 4.5. Mapping of RTP header extensions . . . . . . . . . . . . 9 65 5. Design considerations for QUIC . . . . . . . . . . . . . . . 9 66 5.1. Reliability (or restransmission) control for stream 67 frames . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Congestion control adaptation . . . . . . . . . . . . . . 10 69 5.3. RTCP mapping . . . . . . . . . . . . . . . . . . . . . . 10 70 5.4. API . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.5. Multiparty . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. SDP Extensions for Negotiating RTP-over-QUIC . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The Real-time Transport Protocol (RTP) [RFC3550] provides a framework 84 for delivery of audio and video data for telephony, teleconferencing, 85 video streaming, TV distribution, and other real-time applications. 86 Previous work has defined the RTP data transfer protocol, along with 87 numerous profiles, payload formats, and other extensions. 89 The QUIC transport protocol [I-D.ietf-quic-transport] 90 [I-D.ietf-quic-tls] [I-D.ietf-quic-recovery] 91 [I-D.ietf-quic-manageability] [I-D.ietf-quic-applicability] 92 [I-D.ietf-quic-http] is a UDP-based, stream-multiplexing, encrypted 93 transport protocol, primarily targeting web applications. When 94 compared to the combination of TCP and TLS, QUIC reduced connection 95 set-up times, improved congestion control, and stream multiplexing 96 without head-of-line blocking. 98 RTP has typically been run over UDP or DTLS [RFC5763] [RFC5764], to 99 leverage timely but unreliable data transfer as part of interactive 100 application frameworks such as SIP [RFC3261] and WebRTC 101 [I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-rtp-usage], or to build 102 on UDP/IP multicast support for large-scale managed TV distribution. 103 A mapping of RTP onto TCP [RFC4571] has been widely used for video on 104 demand applications using RTSP [RFC7826], although with relaxed delay 105 bounds [Delay-TCP]. There is also an experimental mapping of RTP 106 onto DCCP [RFC5762]. This memo explores how RTP can be run over 107 QUIC. It has four main purposes: 109 1. to document use cases for RTP over QUIC, and to help understand 110 when it's appropriate to use RTP and QUIC together (Section 2; 111 2. to understand and define a sensible mapping of RTP sessions onto 112 one (or more) QUIC connections (Section 4); 113 3. to derive a wish-list for additional QUIC functionality to be fed 114 into the QUIC WG (Section 5); and 115 4. to define the necessary signalling extensions to allow 116 negotiation of RTP over QUIC (Section 6). 118 Editor's note: Section 5 is intended to document requirements for now 119 and may disappear later if those are met or formally folded into a 120 separate document. Also Section 4 and Section 6 may ultimately 121 become separate drafts for consideration by different working groups 122 (e.g., AVTCORE and MMUSIC). 124 2. Use Cases for RTP over QUIC 126 We identify the following possible use cases for RTP over QUIC: 128 1. Interactive peer-to-peer applications, such as telephony or video 129 conferencing. Such applications operate in a trapezoid topology 130 using a client-server signalling channel running SIP or WebRTC, 131 and an associated peer-to-peer media path and/or data channel. 132 Mappings of SIP and WebRTC onto QUIC are possible, but outside 133 the scope of this memo. It might be desirable to transport the 134 peer-to-peer RTP media path and data channel using QUIC, to 135 leverage QUIC's security, stream demultiplexing, and congestion 136 control features running over a single UDP port. This would 137 simplify media demultiplexing, and potentially obviate the need 138 for the congestion control work being done in the RMCAT working 139 group. The design of QUIC makes it difficult however, since QUIC 140 does not support peer-to-peer NAT traversal using STUN and ICE 141 (and indeed uses a packet format that conflicts with STUN). 142 These applications require low latency congestion control, and 143 would benefit from unreliable delivery modes. 144 2. Interactive client-server applications. For example, a "click 145 here to speak to a representative" button on a website that 146 starts an interactive WebRTC call. Such applications avoid the 147 NAT traversal issues that complicate peer-to-peer use of QUIC, 148 and can benefit from stream demultiplexing and (if appropriate 149 algorithms are provided) congestion control. They would benefit 150 from unreliable delivery modes to reduce latency. 151 3. Client-server video on demand applications using WebRTC or RTSP. 152 These benefit from QUIC stream demultiplexing in the same way as 153 interactive client-server applications, but with relaxed latency 154 bounds that make them fit better with existing congestion control 155 algorithms and reliable delivery. 156 4. Live video streaming from a server can also benefit from stream 157 demultiplexing. If designed carefully, it should be easier to 158 gateway RTP over QUIC into multicast RTP for scalable delivery 159 than to gateway HTTP adaptive video over QUIC into multicast. 161 3. RTP-to-Transport Interface 163 The Real-time Transport Protocol defines the notion of RTP sessions 164 to describe an elementary communication relationship between two or 165 more parties. An RTP session comprises a uni-, bi-, or 166 multidirectional flow of RTP packets carrying media as well as flows 167 of RTCP packets providing feed forward from RTP senders to receivers 168 and feedback from RTP receivers to senders. 170 Each media source is identified by a 32-bit Synchronization Source 171 (SSRC) identifier, unique within an RTP session. An RTP session 172 comprise the set of media sources that have the same view of the SSRC 173 space. A single endpoint may use multiple SSRC identifiers (e.g., 174 one for audio and one for video). Multiple media streams of a single 175 endpoint are tied together by means of a common Canonical Name 176 (CNAME) carried as part of the RTCP Source Description (SDES) 177 packets. This allows receivers to, e.g., determine which media 178 streams to synchronize. 180 Originally, in an RTP session the RTP and RTCP streams each used 181 different port numbers, so that a single RTP session would use two 182 port numbers (historically, when used with multicast conferencing, 183 these were adjacent port numbers, RTP on the even and RTCP on the 184 next higher odd port number). However, the use of unicast RTP has, 185 (not just) due to the presence of NATs, motivated the multiplexing of 186 both RTP and RTCP on a single port number [RFC5761]. The payload 187 structure and number spaces used for RTP and RTCP packets were 188 designed to support this easily. 190 The bundle framework [I-D.ietf-mmusic-sdp-bundle-negotiation] allows 191 multiplexing of multiple RTP streams on a single address:port 192 combination. All the RTP streams in a bundled group are part of a 193 single RTP session sharing a single SSRC number space [RFC3550]. 195 These two efforts also reduce the number of ICE candidates to be 196 validated as part of a multimedia call or conference setup procedure. 197 They are particularly required in conjunction with WebRTC to reduce 198 the signaling and resource requirements, which would affect NATs as 199 well as STUN and TURN servers. We note, however, that ICE is not 200 currently usable with QUIC, since QUIC and STUN packets are not 201 readily distinguished on a single UDP port, due to poor choice of 202 packet formats. 204 WebRTC deserves particular consideration because its potential close 205 relationship to QUIC: WebRTC uses HTTP/1.1 (possibly using 206 WebSockets), or HTTP/2 to connect to web servers, and thus will 207 likely use QUIC in the future as a signaling transport. Moreover, 208 WebRTC supports peer-to-peer data channels, which currently target 209 using SCTP over UDP over DTLS: SCTP for stream multiplexing within a 210 connection and UDP for better NAT traversal properties. Since QUIC 211 would seem to support these two functions, it could be a natural 212 choice to be used for the data channel as well - although this would 213 require changes to the QUIC packet formats to allow demultiplexing 214 with STUN for NAT traversal. 216 For the actual media transmission, RTP use codec-specific payload 217 formats that define how a piece of encoded media is broken down into 218 data units that can fit into an MTU-sized packet for transmission. 219 One important goal of RTP payload format design is allowing decoding 220 packets as much as possible independent of each other as some may be 221 lost due to the best-effort nature of the underlying UDP [RFC2736]. 222 This implies, on the one hand, that RTP senders have to perform 223 codec-level fragmentation in a semantically meaningful manner and, on 224 the other hand, that are in control of packet boundaries and 225 transmission scheduling and timing as well as retransmission 226 decisions. 228 On the receiving side, RTP expects a detailed understanding of packet 229 reception timing, possible reordering, and losses, as this 230 information is used to ensure smooth media play-out, and is reported 231 in the RTCP feedback statistics. 233 4. RTP-to-QUIC Mapping 235 This section address the necessary considerations to realize _one_ 236 possible way of carrying RTP-over-QUIC. 238 Editor's note: At this point, this section is intended to explore the 239 design space and briefly describe a number of different options 240 without making specific recommendations about which option(s) to 241 choose. Future revisions of this document move towards taking 242 concrete decisions. 244 4.1. Mapping Semantic Units 246 RTP payload formats define a mapping of media data units (e.g., video 247 or audio frames, audio samples, etc.) to packets. Assuming that we 248 will preserve the structure of RTP header, optional header extension, 249 and payload, there are two obvious options: 251 o Preserve the previous RTP assumptions about semantic fragmentation 252 at MTU size boundaries; i.e., use the same packetization mechanism 253 as before, just then drop the resulting RTP packet into a QUIC 254 payload. Note that the MTU size may be smaller since QUIC packet 255 headers are larger than plain UDP headers. This approach is most 256 effective if the QUIC implementation allows the application to 257 provide hints on where to fragment the QUIC stream into UDP 258 packets at the sender side. 259 o Operate solely on semantic units such as video frames, and map 260 each semantic unit to a QUIC payload. This approach leaves the 261 final packetization decision to QUIC. In this case, our "MTU 262 size" would not be defined by the IP layer but by QUIC. It is 263 possible in this case for video frame composed of multiple RTP 264 packets to use one RTP header for the whole video frame; no need 265 to break the video frame to multiple RTP packet, put all payload 266 as one RTP packet whose size may be bigger than MTU and send it as 267 QUIC payload. 269 If we assume that semantic units are to be received and processed 270 (and released to the application) atomically for best performance 271 results, then option 2) would be preferred. If we consider that 272 subunits are meaningful (e.g., slices in case of video), then option 273 1) may be preferred. This is heavily dependent on how tightly 274 coupled are the application, RTP stack, and QUIC transport, and on 275 what visibility and control is provided into the QUIC stream 276 fragmentation, reception, and reception timing. In any case, 277 however, it would be up to the payload definition to determine what a 278 semantic unit. 280 4.2. Encapsulating Media Units 282 QUIC streams do not preserve packet boundaries, but rather offer a 283 stream abstraction similar to that of TCP. Therefore, if multiple 284 identifiable media units are to be transmitted on the same stream, 285 the encapsulation mechanisms MUST provide boundaries for media data 286 units, e.g., similar to the approach chosen for carrying RTP in TCP. 288 [Editor's note: QUIC requires a stream abstraction on the wire, but 289 does it require the API offered to the application to provide a 290 stream abstraction? Could a QUIC implementation that's tightly 291 integrated into the application provide more control without 292 violating the on-the-wire protocol?] 294 The exception would be if only a single frame is ever transmitted 295 across a single stream (see option 3 in section 3.3) so that stream 296 termination signifies the end of the respective packet. 298 4.3. Mapping Media to Streams 300 There are (at least) three basic distinct options for mapping media 301 to streams: 303 o Map an RTP session to a QUIC stream. In this case, all media 304 packets of the RTP session would be carried within a single QUIC 305 stream. 306 o Map an RTP stream to a QUIC stream. In case, as presently 307 discussed in the QUIC WG, the QUIC stream would be unidirectional 308 and we will have one QUIC stream per transmission direction. 310 Note that both options would map, e.g., FEC or retransmission 311 sessions to different QUIC streams. Note also that both 1 and 2 312 implicitly create the problem of head-of-line blocking since QUIC 313 streams are reliable and order preserving. This would thus not serve 314 the real-time nature of RTP packets well. [Editor's note: to what 315 extent are reliability and ordered required in the QUIC API? 316 Provided the retransmission is made on the wire, is there anything 317 stopping a QUIC implementation releasing data to the application out- 318 of-order?] 320 o Map each independently decodable groups of frames, video frame, or 321 even packet, depending on the encapsulation chosen to an 322 individual QUIC stream. This is independent of whether streams, 323 would be uni- or bi-directional. 325 Option 3 eliminates the head of line blocking problem of options 1. 326 and 2. because QUIC does not provide any ordering across different 327 streams. Using larger semantic units (e.g., GOPs) for stream 328 mapping, would provide for more efficient stream number usage. 329 However, all stream frames are still transmitted reliably. This 330 implies that QUIC will perform retransmissions even for packets that 331 would be too late already. 333 Mapping each video frame or packet to a different stream would raise 334 an issue with stream numbering unless all RTP sessions are 335 multiplexed on a single UDP socket anyway and then all RTP packets 336 would simply be mapped to different streams. 338 An open question here would be how to deal with additional data 339 channels that don't use RTP. Ideally, it should be possible that 340 those be within the same QUIC connection (if QUIC is used as 341 transport) to avoid consuming again more port numbers. Since, on the 342 one hand, data channels can be set up and torn down at any time and, 343 on the other hand, media packets are transmitted continuously, a need 344 arises to set aside streams for data channels. One option would be 345 "reserving" those streams in some form. But then, how many to 346 reserve? Moreover, this would be incompatible with the slides stream 347 number window being used by QUIC. Alternatively, one would need to 348 synchronize the use of QUIC streams in real-time between the 349 signaling and application channels and the media packet transmission. 350 This may be hard to achieve and also suffers from the problem of the 351 stream id window moving fast with frame transmissions. A third 352 option would be adding another demultiplexing structure (e.g., to 353 different RTP headers from data packets) and use a similar scheme of 354 one application data unit (ADU) per stream for other applications. 355 While feasible, this appears somewhat cumbersome in the mapping. 357 We finally need to consider inter RTP stream synchronisation and how/ 358 if this would be affected by use of multiple QUIC streams. 360 None of the above schemes appear truly satisfactory from a system 361 design perspective. This may call for some refined design 362 considerations for QUIC, which we will begin discussing in section 4. 364 4.4. Mapping RTCP packets 366 RTCP is a bi-directional stream unlike RTP streams which are 367 unidirectional. There can be for example a video stream receiver 368 that only receives video content but will send and receive RTCP 369 messages. 371 The current discussion on uni-directional streams direction will 372 allow both uni- and bi-directional QUIC streams in the same QUIC 373 connection. Such a solution will allow multiplexing of RTP and RTCP 374 streams in the same QUIC connection. 376 An issue to consider is the encryption of RTCP messages. The RTP 377 secure profiles RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124] allow NULL 378 cipher for RTCP with message integrity. Using a NULL cipher allow 379 RTP middleboxes to monitor the RTP delivery quality (the QUIC 380 connection is encrypted as normal, this relates to whether the data 381 within the QUIC connection is itself encrypted; c.f. the PERC working 382 group). 384 Whether to use a single stream for forward RTCP and another for 385 reverse could be a function of the streams being uni- or 386 bidirectional in the end. Another question to answer is if there 387 should be one stream per SSRC per direction for RTCP. Finally, RTCP 388 packets may also be lost and they contain timing information. 389 Avoiding HoL blocking may thus also be important. 391 4.5. Mapping of RTP header extensions 393 QUIC provides a reliable protocol which addresses the requirement in 394 [I-D.ietf-avtcore-rfc5285-bis] to transmit the RTP header extension 395 in a couple of RTP packets to provide better reliability. Still if 396 we will adopt mapping option 3 each RTP packet or media frame will 397 use a separate QUIC stream. If a packet with RTP header extension is 398 blocked the consecutive RTP packet will continue to arrive; in this 399 case it will be beneficial to transmit the RTP header extensions more 400 than once to allow for its arrival by the receiver. Using QUIC as a 401 transport for RTP will have all RTP header extensions encrypted 402 allowing only entities that terminate a QUIC connection to decode 403 them. RTP header extension as defined in 404 [I-D.ietf-avtcore-rfc5285-bis] can be sent in the clear and provide 405 information to RTP middleboxes enabling them to route encrypted RTP 406 packets. Currently the following header extensions are used for 407 routing of encrypted RTP streams. Client to mixer audio level 408 [RFC6464]. Frame marking [I-D.ietf-avtext-framemarking] and splicing 409 interval [I-D.ietf-avtext-splicing-notification]. 411 Editor's note: need to be clearer about the role of RTP middleboxes 412 as specified in RTP topologies [RFC7667] connected by QUIC 413 connections, and what is encrypted/authenticated end-to-end across 414 the mesh of QUIC connections in that topology, and what is only 415 protected hop-by-hop by QUIC. 417 5. Design considerations for QUIC 419 This section will address design implications for QUIC and the 420 interaction with QUIC of both RTP and RTCP. In this version, this 421 section is still very rudimentary and only identifies some of the 422 aspects we expect to discuss in the future: 424 5.1. Reliability (or restransmission) control for stream frames 426 RTP packets are usually transmitted over unreliable UDP transport, 427 with RTP being in full control of timing and, as applicable, of error 428 resilience mechanisms. 430 QUIC supports only full reliability at this point and would 431 retransmit lost packets even if they are no longer needed. While 432 using indepdent streams for different media units could prevent head- 433 of-line blocking, retrasmissions would appear to still happen. To 434 deal with this "issue", it may be worthwhile considering ways to 435 control (re)transmission in a fine-grained fashion, e.g., by means of 436 supporting partial realibility or by providing access to QUIC buffers 437 for (re)transmission control. 439 5.2. Congestion control adaptation 441 QUIC defines a congestion control mechanism the feasibility of which 442 for real-time media streams is yet to be understood. Media codecs 443 have their own constraints for adapting the media transmission rate 444 (in terms of reactivity and granularity) and the RMCAT working group 445 is currently considering a number of options for real-time media 446 congestion control (e.g., [I-D.ietf-rmcat-scream-cc] 447 [I-D.ietf-rmcat-gcc] [I-D.ietf-rmcat-nada] 448 [I-D.ietf-rmcat-coupled-cc] [I-D.singh-rmcat-adaptive-fec]), in 449 addition to the basic circuit breaker mechanism [RFC8083]). It is an 450 open question the extent to which these congestion control 451 algorithms, or approaches inspired by them, ought to be incorporated 452 into QUIC. 454 5.3. RTCP mapping 456 RTCP provides feed forward and feedback about the media channel, with 457 extensions supporting very detailed per packet reporting. The 458 reception statistics partly overlap with what QUIC ACKs provide 459 (especially ACK/NACK ranges and per-packet timestamps). RTCP 460 algorithms could benefit from obtaining access to these statistics 461 via a local API to avoid redundancy. 463 RTCP packets must also be mapped to QUIC frames (and streams). Since 464 RTP and RTCP can be multiplexed on the same transport address, as 465 long as payload boundaries are preserved, RTCP packets could go onto 466 any stream. However, since RTCP packets are used for RTT 467 measurements, they should be transmitted independent of the RTP 468 packets and ideally without blocking, so that head-of-line blocking 469 by other packets should be avoided. If RTT measurements can be 470 imported from QUIC (see above), exact timing control of RTCP packets 471 won't be necessary; yet RTCP packets contain other information that 472 require timely delivery. Similar to RTP, RTCP does not require 473 reliable delivery. 475 5.4. API 477 We will need to understand how (if at all) a QUIC API could (and if 478 it should) provide the necessary support for RTP/RTCP transmission 479 and reception. This could include transmission timing control; 480 providing transmission and reception timestamps; supporting 481 retransmission control and/or buffer managements, among others. The 482 extent to which the principle of application level framing [ALF] 483 should be incorporated into QUIC implementations, and how tightly 484 coupled those implementations can be to the RTP stack and 485 application, is unclear. How example, can a QUIC implementation 486 deliver data out-of-order or allow control over stream fragmentation, 487 both of which would improve performance for real-time media over RTP, 488 provided it keeps the wire format unchanged? The service model needs 489 to become clearer. 491 5.5. Multiparty 493 RTP is explicitly a group communication protocol, even when unicast. 494 If we assume multicast QUIC is undesirable, there needs to be a 495 scoping discussion around topologies. 497 Usual web-based conferencing services use one or more central 498 system(s) for mixing or forwarding. Whenever the media streams do 499 not require processing at such an entity but are merely forwarded, 500 SRTP can provide the necessary end-to-end encryption. In contrast, 501 QUIC "just" provides a secure channel between the endpoints and the 502 central entities. To this end, SRTP could be applied inside QUIC for 503 certain scenarios. 505 6. SDP Extensions for Negotiating RTP-over-QUIC 507 TBD 509 7. Security Considerations 511 RTP is used as a plain payload for QUIC, exploiting its multiplexing 512 capabilities. To this end, the RTP packets are protected 513 (confidentiality) by the QUIC security mechanisms. Hence, the 514 security considerations pertinent to QUIC apply. 516 QUIC is by its very nature a transport layer security mechanisms. 517 RTP traffic will thus be protected on a single transport hop only. 518 As soon RTP topologies more complex than a point-to-point connection 519 are used (e.g., [RFC7667]), RTP traffic will lose its end-to-end 520 protection as transport connections are terminated at the 521 intermediary, even if this acts just as a relay. 523 8. IANA Considerations 525 There are no IANA considerations at this point. 527 9. Acknowledgments 529 10. References 531 10.1. Normative References 533 [I-D.ietf-quic-recovery] 534 Iyengar, J. and I. Swett, "QUIC Loss Detection and 535 Congestion Control", draft-ietf-quic-recovery-05 (work in 536 progress), August 2017. 538 [I-D.ietf-quic-tls] 539 Thomson, M. and S. Turner, "Using Transport Layer Security 540 (TLS) to Secure QUIC", draft-ietf-quic-tls-05 (work in 541 progress), August 2017. 543 [I-D.ietf-quic-transport] 544 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 545 and Secure Transport", draft-ietf-quic-transport-05 (work 546 in progress), August 2017. 548 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 549 Jacobson, "RTP: A Transport Protocol for Real-Time 550 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 551 July 2003, . 553 10.2. Informative References 555 [ALF] Clark, D. and D. Tennenhouse, "Architectural 556 Considerations for a New Generation of Network Protocols", 557 Proceedings of ACM SIGCOMM, 1990. 559 [Delay-TCP] 560 Brosh, E., Baset, S., Rubinstein, D., and H. Schulzrinne, 561 "The Delay-Friendliness of TCP", Proceedings of ACM 562 SIGMETRICS, 2008. 564 [I-D.ietf-avtcore-rfc5285-bis] 565 Singer, D., Desineni, H., and R. Even, "A General 566 Mechanism for RTP Header Extensions", draft-ietf-avtcore- 567 rfc5285-bis-14 (work in progress), August 2017. 569 [I-D.ietf-avtext-framemarking] 570 Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking 571 RTP Header Extension", draft-ietf-avtext-framemarking-05 572 (work in progress), July 2017. 574 [I-D.ietf-avtext-splicing-notification] 575 Xia, J., Even, R., Huang, R., and D. Lingli, "RTP/RTCP 576 extension for RTP Splicing Notification", draft-ietf- 577 avtext-splicing-notification-09 (work in progress), August 578 2016. 580 [I-D.ietf-mmusic-sdp-bundle-negotiation] 581 Holmberg, C., Alvestrand, H., and C. Jennings, 582 "Negotiating Media Multiplexing Using the Session 583 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 584 negotiation-38 (work in progress), April 2017. 586 [I-D.ietf-quic-applicability] 587 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 588 Transport Protocol", draft-ietf-quic-applicability-00 589 (work in progress), July 2017. 591 [I-D.ietf-quic-http] 592 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 593 QUIC", draft-ietf-quic-http-05 (work in progress), August 594 2017. 596 [I-D.ietf-quic-manageability] 597 Kuehlewind, M., Trammell, B., and D. Druta, "Manageability 598 of the QUIC Transport Protocol", draft-ietf-quic- 599 manageability-00 (work in progress), July 2017. 601 [I-D.ietf-rmcat-coupled-cc] 602 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 603 control for RTP media", draft-ietf-rmcat-coupled-cc-06 604 (work in progress), March 2017. 606 [I-D.ietf-rmcat-gcc] 607 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 608 Mascolo, "A Google Congestion Control Algorithm for Real- 609 Time Communication", draft-ietf-rmcat-gcc-02 (work in 610 progress), July 2016. 612 [I-D.ietf-rmcat-nada] 613 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 614 J., and S. D'Aronco, "NADA: A Unified Congestion Control 615 Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 616 (work in progress), March 2017. 618 [I-D.ietf-rmcat-scream-cc] 619 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 620 for Multimedia", draft-ietf-rmcat-scream-cc-10 (work in 621 progress), July 2017. 623 [I-D.ietf-rtcweb-overview] 624 Alvestrand, H., "Overview: Real Time Protocols for 625 Browser-based Applications", draft-ietf-rtcweb-overview-18 626 (work in progress), March 2017. 628 [I-D.ietf-rtcweb-rtp-usage] 629 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 630 Communication (WebRTC): Media Transport and Use of RTP", 631 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 632 2016. 634 [I-D.singh-rmcat-adaptive-fec] 635 Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion 636 Control Using FEC for Conversational Media", draft-singh- 637 rmcat-adaptive-fec-03 (work in progress), March 2016. 639 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 640 Payload Format Specifications", BCP 36, RFC 2736, 641 DOI 10.17487/RFC2736, December 1999, . 644 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 645 A., Peterson, J., Sparks, R., Handley, M., and E. 646 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 647 DOI 10.17487/RFC3261, June 2002, . 650 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 651 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 652 RFC 3711, DOI 10.17487/RFC3711, March 2004, 653 . 655 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 656 and RTP Control Protocol (RTCP) Packets over Connection- 657 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 658 2006, . 660 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 661 Real-time Transport Control Protocol (RTCP)-Based Feedback 662 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 663 2008, . 665 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 666 Control Packets on a Single Port", RFC 5761, 667 DOI 10.17487/RFC5761, April 2010, . 670 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 671 Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 672 2010, . 674 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 675 for Establishing a Secure Real-time Transport Protocol 676 (SRTP) Security Context Using Datagram Transport Layer 677 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 678 2010, . 680 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 681 Security (DTLS) Extension to Establish Keys for the Secure 682 Real-time Transport Protocol (SRTP)", RFC 5764, 683 DOI 10.17487/RFC5764, May 2010, . 686 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 687 Transport Protocol (RTP) Header Extension for Client-to- 688 Mixer Audio Level Indication", RFC 6464, 689 DOI 10.17487/RFC6464, December 2011, . 692 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 693 DOI 10.17487/RFC7667, November 2015, . 696 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 697 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 698 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 699 2016, . 701 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 702 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 703 DOI 10.17487/RFC8083, March 2017, . 706 Authors' Addresses 708 Joerg Ott 709 Technische Universitaet Muenchen 710 Boltzmannstrasse 3 711 Garching bei Muenchen 712 Germany 714 Email: ott@in.tum.de 715 Roni Even 716 Huawei 717 Israel 719 Email: roni.even@huawei.com 721 Colin Perkins 722 University of Glasgow 723 School of Computing Science 724 Glasgow G12 8QQ 725 UK 727 Email: csp@csperkins.org 728 URI: https://csperkins.org/ 730 Varun Singh 731 CALLSTATS I/O Oy 732 Annankatu 31-33 C 42 733 Helsinki 00100 734 Finland 736 Email: varun@callstats.io 737 URI: https://www.callstats.io/about