idnits 2.17.1 draft-lennox-avtcore-rtp-topo-offer-answer-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 : ---------------------------------------------------------------------------- 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 (March 5, 2012) is 4429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-00 == Outdated reference: A later version (-04) exists of draft-lennox-clue-rtp-usage-02 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Informational March 5, 2012 5 Expires: September 6, 2012 7 Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ 8 Answer-Initiated Sessions. 9 draft-lennox-avtcore-rtp-topo-offer-answer-00 11 Abstract 13 This document discusses a number of considerations related to the 14 topologies of Real-Time Transport Protocol (RTP) sessions initated 15 using the Session Description (SDP) unicast Offer/Answer Model, 16 especially as applied to source-multiplexed sessions. 18 The primary observation is that certain topologies cannot be created 19 by unicast SDP Offer/Answer. Notably, the it is not possible to 20 negotiate the topology that RFC 5117 calls Topo-Transport-Translator 21 (or "relay"). 23 As a consequence of this limitation, certain topological assumptions 24 can safely be made for RTP sessions initiated using unicast SDP 25 Offer/Answer; and therefore, certain optimizations to RTP are 26 possible in such sessions. This document also describes the 27 optimizations that these assumptions make possible. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. RTP Topologies and SDP Offer/Answer . . . . . . . . . . . . . 5 67 5. Advantages for Assuming RTCP rewriting . . . . . . . . . . . . 6 68 5.1. Independent RTCP bandwidth . . . . . . . . . . . . . . . . 6 69 5.2. Optimization of receiver reports . . . . . . . . . . . . . 7 70 6. Normative recommendations . . . . . . . . . . . . . . . . . . 8 71 7. Limitations of media and RTCP modifying middleboxes . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 For interactive conferencing, by the far most common method of 82 negotiating Real-Time Tranport Protocol (RTP) [RFC3550] sessions is 83 to use the Session Description Protocol [RFC4566] Offer/Answer Model 84 [RFC3264]. In particular, conferences are typically negotated using 85 offer/answer unicast streams. 87 As discussed in [RFC5117], however, RTP sessions can be arranged in a 88 fairly large number of topologies, more complexly than the simple 89 dichotomy of "unicast" or "multicast" used by the Offer/Answer model. 90 Most of the unicast-based topologies in RFC 5117 can be negotiated as 91 SDP Offer/Answer unicast streams. However, for reasons that are 92 explained in Section 3, one topology in particular cannot be 93 negotiated using SDP Offer/Answer: Topo-Transport-Translator. 95 While this might initially seem to be a limitation of SDP Offer/ 96 Answer, it actually turns out that if an endpoint can assume that its 97 RTP topologies are limited to those that can be negotated using 98 offer/answer, a number of RTP optimizations become possible. These 99 are discussed in Section 5, with specific recommendations in 100 Section 6. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in RFC 107 2119 [RFC2119] and indicate requirement levels for compliant 108 implementations. 110 3. RTP Topologies 112 [RFC5117] discusses multi-endpoint topologies of RTP sessions in 113 detail. For the purposes of this document, a few topologies in 114 particular are of interest, and will be described in detail. 116 +---+ +---+ 117 | A |<------->| B | 118 +---+ +---+ 120 Figure 1: Point to Point 122 The simplest topology, shown in Figure 1, is Point to Point (Topo- 123 Point-to-Point). A sends to B, and only B, while B sends to A, and 124 only A. An endpoint can still use multiple synchronization sources 125 (SSRCs) in a session. 127 This is topology is straightforwardly negotated by SDP Offer-Answer 128 unicast streams. 130 +-----+ 131 +---+ / \ +---+ 132 | A |----/ \---| B | 133 +---+ / Multi- \ +---+ 134 + Cast + 135 +---+ \ Network / +---+ 136 | C |----\ /---| D | 137 +---+ \ / +---+ 138 +-----+ 140 Figure 2: Point to Multipoint Using Multicast 142 Secondly, in the Topo-Multicast topology, shown in Figure 2, traffic 143 from each endpoint in an RTP session is received by all other session 144 participants, transported by the network level by sending to a 145 special IP address. These sessions can negotiated by the Offer/ 146 Answer model as multicast streams. 148 Multicast sessions are often supported within individual domains, but 149 are not typically supported accross the public Internet. 151 +---+ +------------+ +---+ 152 | A |<---->| |<---->| B | 153 +---+ | | +---+ 154 | Translator | 155 +---+ | | +---+ 156 | C |<---->| |<---->| D | 157 +---+ +------------+ +---+ 159 Figure 3: RTP Translator (Relay) with Only Unicast Paths 161 Finally, for the purposes of this discussion, one other topology 162 described in [RFC5117] is specifically relevant; the others can all 163 be generalized. The specific topology is the topology Topo- 164 Transport-Translator, illustrated in Figure 3, which simply forwards 165 unicast traffic (both media and Real-Time Transport Control Protocol 166 (RTCP) traffic) among all the unicast connections to a central 167 translator. 169 +---+ +------------+ +---+ 170 | A |<---->| Media & |<---->| B | 171 +---+ | RTCP | +---+ 172 | Modifier | 173 +---+ | or | +---+ 174 | C |<---->| Terminator|<---->| D | 175 +---+ +------------+ +---+ 177 Figure 4: RTCP-Modifying Central Box 179 By contrast, the topologies Topo-Media-Translator, Topo-Mixer, Topo- 180 Video-Switch-Mixer, and Topo-RTCP-Terminating-MCU can all be 181 summarized by the diagram shown in Figure 4. These topologies all 182 have the common property that they have a central box (a media 183 translator, mixer, or MCU) which terminates media and RTCP traffic, 184 and forwards it, modified to a greater or lesser extent, to the 185 topology's other endpoints. 187 4. RTP Topologies and SDP Offer/Answer 189 The SDP Offer/Answer Model [RFC3264] specifies different behavior 190 depending on whether the address of the transport connection being 191 negotiated is a unicast and multicast address. Effectively, offer/ 192 answer assumes that the stream being negotated corresponds either to 193 Topo-Point-to-Point or Topo-Multicast. 195 Most of the RFC 5117 unicast topologies described in Section 3 can be 196 negotiated by the centralized point negotating with each endpoint 197 using the Offer/Answer unicast mode. However, the Topo-Transport- 198 Translator cannot be. 200 The difficulty is that SDP Offer/Answer unicast exchange is designed 201 to negotate each end of the excahnge's separate view of the session, 202 and each endpoint has a fair bit of control over what its view of the 203 session should look like. However, because the translator at the 204 center of the Topo-Transport-Translator topology forwards media and 205 RTCP unmodified, it is necessary that all participants have a common 206 view of all non-transport aspects of the session. 208 Thus, the freedom that the Offer/Answer model gives each endpoint to 209 control its view of the session prevents the central box from 210 enforcing a single, uniform view of it. Among the session aspects 211 that can be different among the session participants are: 213 Media Types: Unicast Offer/Answer participants have the freedom to 214 remove media types from the session description (in an answer or 215 an updated offer). They also have the freedom to change some fmtp 216 media type parameters. Moreover, though RFC 3264 indicates that 217 it is NOT RECOMMENDED, they have the freedom to change the mapping 218 between media typees and RTP payload type numbers. 219 Bandwidth: An answerer can specify a bandwidth attribute (SDP b= 220 value) for any media stream, indicating the bandwidth that the 221 answerer would like the offerer to use when sending media. This 222 does bear any relationship to bandwidth values in use in the other 223 direction. (This is somewhat problematic as SDP bandwidth 224 parameters are used to calculate RTCP bandwidth, and thus RTP 225 session membership timeout intervals.) 226 Packetization Time: An SDP offer or answer can specify the ptime 227 attribute (packetization time interval) with which it wants to 228 receive media. This value is independent in offers and answers. 230 In addition to these mismatches for the attributes specified by the 231 core SDP Offer/Answer specification, there are of course many 232 extensions to SDP which specify Offer/Answer behavior. These are not 233 discussed here, but many of them would have similar issues with the 234 Topo-Transport-Translator topology. 236 Any of the media and RTCP terminating topologies described in 237 Section 3 as modifying media and RTCP will be able to repair these 238 mismatches, or else reject an endpoint that asks for a configuration 239 beyond its capacity to repair. The mismatch difficulties arise only 240 for the Topo-Transport-Translator. 242 5. Advantages for Assuming RTCP rewriting 244 If we assume that we always have a central box that can rewrite, or 245 generates its own, media and RTCP, a number of optimizations and 246 protocol clarifications become possible. 248 5.1. Independent RTCP bandwidth 250 SDP Unicast Offer/answer allows RTP session bandwidth to be specified 251 independently in each direction of the offer/answer exchange. The 252 assumption is that bandwidth in each direction is (over the relevant 253 bottleneck links) non-rival, and that the available bitrates can in 254 some circumstances be dramatically asymmetric. 256 It has always been somewhat unclear how offer/answer assymetric 257 bandwidths interact with the RTCP bandwidth fraction (5%, or the SDP 258 bandwidth modifiers). 260 If we assume that RTCP is never passively relayed, but rather will 261 always either be consumed locally or will actively be rewritten 262 before being forwarded, this problem largely goes away. Each side of 263 the unicast RTP session domain gets the appropriate fraction of its 264 (sending) RTP bandwidth to send RTCP. It can divide this fraction 265 among its sources as it wishes, subject ot the constraint that a 266 regular report is sent for each source with appropriate frequency to 267 prevent timeouts. Group size estimation is only needed for timeout 268 calculation. It can be done independently for sending and receiving 269 media. 271 Since RTCP bandwidth can be shared among all the sources, a sender 272 can then also send feedback from multiple of its sources in a single 273 compound RTCP packet, up to transport MTU issues, reducing transport 274 overhead. 276 5.2. Optimization of receiver reports 278 For the benefit of Topo-Multicast and Topo-Transport-Translator, in 279 an RTCP session, all session participants send RTCP reception reports 280 (in SR or RR RTCP packets) for every active RTP source from which 281 they have received packets in the previous reporting interval. 283 This means that the number of reception reports is quadratic in the 284 number of sources in a conference. (Specifically, the number equals 285 the number of conference participants, times the number of active 286 senders whos sent during a report interval. However, because the 287 report interval itself scales with the number of sources, this will 288 in a many-to-many conference converge to being quadratic in the 289 number of sources.) 291 In cases where there is an media-and-RTCP-modifying middlebox, this 292 quadratic behavior is useless. The relevant reception report 293 information is that between and endpoint and the middlebox, since the 294 middlebox can often perform reliability and repair mechanisms on its 295 own. These excess reception reports then increase the size of RTCP 296 packets, which by the formulas for calculating RTCP packet 297 transmission schedules reduces the RTCP timing interval. Thus, these 298 excess reception reports consume bandwidth which could instead be 299 used for timely RTCP feedback of relevant data. 301 These quadratic reception reports are particularly useless in 302 scenarios where a given session participant is sending multiple 303 sources of its own (rather than forwarding multiple remote sources) 304 in the same RTP session. Examples of such use cases are the CLUE 305 Telepresence model [I-D.lennox-clue-rtp-usage], bundling of multiple 306 media types onto a single RTP session 307 [I-D.ietf-mmusic-sdp-bundle-negotiation], and single-session RTP 308 retransmission [RFC4588]; in general, this will apply to most 309 scenarios in which SDP source descriptions [RFC5576] are used. 311 The most useless data is reception reports by one local source about 312 another, since these will always (by definition) be "received" 313 perfectly (with zero loss and jitter) by their sender. 315 Nearly as useless redundant feedback from multiple co-located sources 316 about the same remote source. Since RTP traffic is in fact received 317 by an endpoint, not a source, this information will either be 318 identical (if an endpoint choses to synchronize its RTCP feedback 319 messages) or multiple, non-commensurate transmissions of the same 320 information (if it does not). 322 Also often useless is feedback by one remote source about another one 323 -- while there are some conceivable use cases where this could be 324 relevant information (for instance, a monitoring application), in 325 most conferencing models, this is uninteresting and unimportant. 327 6. Normative recommendations 329 Based on the analysis in Section 5, this section makes some normative 330 recommendations for the behavior of RTP endpoints in sessions 331 negotiated using unicast SDP Offer/Answer. 333 (Open issue: it is possible that these recommendations might need to 334 be a normative update to [RFC3550]; alternatively, they may just be 335 implementation guidance.) 337 When an RTP [RFC3550] session is negotiated using unicast SDP offer/ 338 answer [RFC3264], RTCP bandwidth, and thus RTCP packet intervals and 339 RTP group membership timeout rules, MUST be calculated separately for 340 the receiving and sending direction, using the rules specified in 341 [RFC3550] as modified by any SDP attributes or the RTP profile in 342 use. An endpoint MAY send RTCP up to its available bandwidth, 343 independent of the bandwidth consumed in the reverse direction, again 344 subject to the SDP modifiers and profiles in use. 346 An endpoint MAY choose to send multiple sources' RTCP messages in a 347 single compound RTCP packet (though such compound packets SHOULD NOT 348 exceed the path MTU, if avoidable and if it is known). This will 349 reduce the average compound RTCP packet size, and thus increase the 350 frequency with which RTCP messages can be sent. Regular (non- 351 feedback) RTCP compound packets MUST still begin with an SR or RR 352 packet, but otherwise MAY contain RTCP packets in any order. 353 Receivers MUST be prepared to receive such compound packets. 355 An endpoint SHOULD NOT send reception reports from one of its own 356 sources about another one ("cross-reports"). Endpoints receiving 357 reception reports MUST be prepared that their peers might not be 358 sending reception reports about their own sources. 360 Similarly, an endpoint sending multiple sources SHOULD NOT send 361 reception reports about a remote source from more than one of its 362 local sources. Instead, it SHOULD create or pick one local source as 363 the "reporting" source for each remote source, which sends full 364 report blocks; all its other sources SHOULD be treated as if they 365 were disconnected, and never saw that remote source. This reporting 366 source MAY be one of the sending sources in the session, or MAY be a 367 receive-only source created simply for the purpose of sending 368 feedback. An endpoint MAY choose different local sources as the 369 reporting source for different remote sources (for example, if it is 370 using bundle [I-D.ietf-mmusic-sdp-bundle-negotiation], it could 371 choose to send reports about remote audio sources from its local 372 audio source, and reports about remote video sources from its local 373 video source), or it MAY choose a single local source for all its 374 reports. If the reporting source leaves the session (sends BYE), 375 another reporting source MUST be chosen. If the AVPF [RFC4585] RTP 376 profile, or one if its secure equivalents, is in use, this 377 "reporting" source SHOULD also be the source for any AVPF feedback 378 messages about its remote sources, as well. Endpoints interpreting 379 reception reports MUST be prepared to receive RTCP SR or RR messages 380 where only one remote source is reporting about its sources. 382 7. Limitations of media and RTCP modifying middleboxes 384 There are a few limitations of media and RTCP modifying middleboxes, 385 compared to what can be done by the Topo-Transport-Translator 386 topology. 388 A media and RTCP modifying middlebox will, necessarily, be more 389 complex (and thus be more expensive, or have lower capacity), than a 390 pure transport forwarder. 392 It is not possible to deploy new RTCP extensions across an 393 unmofidified RTCP-modifying central box, as that box will not know 394 how to re-write these extensions so they are correctly forwarded. 396 If SRTP is in use, these central middleboxes must be trusted with the 397 SRTP keying material. (Since SRTP keying material is usually 398 negotiated hop-by-hop, they may be doing a complete SRTP decryption 399 and re-encryption, with unrelated keys, and possibly even translating 400 between different ciphers or cipher strengths.) 401 It is possible, if the recommendations of Section 6 are in use, that 402 a naive RTCP monitor might think that an RTP flow should actually be 403 interpreted as Topo-Transport-Translator. In this case, it might 404 think that there is a network disconnection between the non-reporting 405 sources and the sources on which they are not reporting. However, 406 architecturally it is very unclear if such monitors actually exist, 407 for conferencing applications, or would care about a disconnection of 408 this sort. 410 8. Security Considerations 412 See the security considerations of [RFC5117]. Notably, as discussed 413 in Section 7, a centralized media and RTCP modifying box will need to 414 terminate SRTP and SRTCP, and so must be a trusted entity. 416 9. IANA Considerations 418 This document makes no requests of IANA. 420 Note to the RFC Editor: please remove this section before 421 publication. 423 10. References 425 10.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 431 with Session Description Protocol (SDP)", RFC 3264, 432 June 2002. 434 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 435 Jacobson, "RTP: A Transport Protocol for Real-Time 436 Applications", STD 64, RFC 3550, July 2003. 438 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 439 Description Protocol", RFC 4566, July 2006. 441 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 442 "Extended RTP Profile for Real-time Transport Control 443 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 444 July 2006. 446 10.2. Informative References 448 [I-D.ietf-mmusic-sdp-bundle-negotiation] 449 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 450 Using Session Description Protocol (SDP) Port Numbers", 451 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 452 progress), February 2012. 454 [I-D.lennox-clue-rtp-usage] 455 Romanow, A., Lennox, J., and P. Witty, "Real-Time 456 Transport Protocol (RTP) Usage for Telepresence Sessions", 457 draft-lennox-clue-rtp-usage-02 (work in progress), 458 February 2012. 460 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 461 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 462 July 2006. 464 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 465 January 2008. 467 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 468 Media Attributes in the Session Description Protocol 469 (SDP)", RFC 5576, June 2009. 471 Author's Address 473 Jonathan Lennox 474 Vidyo, Inc. 475 433 Hackensack Avenue 476 Seventh Floor 477 Hackensack, NJ 07601 478 US 480 Email: jonathan@vidyo.com