AVTCORE J. Lennox Internet-Draft Vidyo Intended status: Informational March 5, 2012 Expires: September 6, 2012 Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ Answer-Initiated Sessions. draft-lennox-avtcore-rtp-topo-offer-answer-00 Abstract This document discusses a number of considerations related to the topologies of Real-Time Transport Protocol (RTP) sessions initated using the Session Description (SDP) unicast Offer/Answer Model, especially as applied to source-multiplexed sessions. The primary observation is that certain topologies cannot be created by unicast SDP Offer/Answer. Notably, the it is not possible to negotiate the topology that RFC 5117 calls Topo-Transport-Translator (or "relay"). As a consequence of this limitation, certain topological assumptions can safely be made for RTP sessions initiated using unicast SDP Offer/Answer; and therefore, certain optimizations to RTP are possible in such sessions. This document also describes the optimizations that these assumptions make possible. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Lennox Expires September 6, 2012 [Page 1] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 3 4. RTP Topologies and SDP Offer/Answer . . . . . . . . . . . . . 5 5. Advantages for Assuming RTCP rewriting . . . . . . . . . . . . 6 5.1. Independent RTCP bandwidth . . . . . . . . . . . . . . . . 6 5.2. Optimization of receiver reports . . . . . . . . . . . . . 7 6. Normative recommendations . . . . . . . . . . . . . . . . . . 8 7. Limitations of media and RTCP modifying middleboxes . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Lennox Expires September 6, 2012 [Page 2] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 1. Introduction For interactive conferencing, by the far most common method of negotiating Real-Time Tranport Protocol (RTP) [RFC3550] sessions is to use the Session Description Protocol [RFC4566] Offer/Answer Model [RFC3264]. In particular, conferences are typically negotated using offer/answer unicast streams. As discussed in [RFC5117], however, RTP sessions can be arranged in a fairly large number of topologies, more complexly than the simple dichotomy of "unicast" or "multicast" used by the Offer/Answer model. Most of the unicast-based topologies in RFC 5117 can be negotiated as SDP Offer/Answer unicast streams. However, for reasons that are explained in Section 3, one topology in particular cannot be negotiated using SDP Offer/Answer: Topo-Transport-Translator. While this might initially seem to be a limitation of SDP Offer/ Answer, it actually turns out that if an endpoint can assume that its RTP topologies are limited to those that can be negotated using offer/answer, a number of RTP optimizations become possible. These are discussed in Section 5, with specific recommendations in Section 6. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. RTP Topologies [RFC5117] discusses multi-endpoint topologies of RTP sessions in detail. For the purposes of this document, a few topologies in particular are of interest, and will be described in detail. +---+ +---+ | A |<------->| B | +---+ +---+ Figure 1: Point to Point The simplest topology, shown in Figure 1, is Point to Point (Topo- Lennox Expires September 6, 2012 [Page 3] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 Point-to-Point). A sends to B, and only B, while B sends to A, and only A. An endpoint can still use multiple synchronization sources (SSRCs) in a session. This is topology is straightforwardly negotated by SDP Offer-Answer unicast streams. +-----+ +---+ / \ +---+ | A |----/ \---| B | +---+ / Multi- \ +---+ + Cast + +---+ \ Network / +---+ | C |----\ /---| D | +---+ \ / +---+ +-----+ Figure 2: Point to Multipoint Using Multicast Secondly, in the Topo-Multicast topology, shown in Figure 2, traffic from each endpoint in an RTP session is received by all other session participants, transported by the network level by sending to a special IP address. These sessions can negotiated by the Offer/ Answer model as multicast streams. Multicast sessions are often supported within individual domains, but are not typically supported accross the public Internet. +---+ +------------+ +---+ | A |<---->| |<---->| B | +---+ | | +---+ | Translator | +---+ | | +---+ | C |<---->| |<---->| D | +---+ +------------+ +---+ Figure 3: RTP Translator (Relay) with Only Unicast Paths Finally, for the purposes of this discussion, one other topology described in [RFC5117] is specifically relevant; the others can all be generalized. The specific topology is the topology Topo- Transport-Translator, illustrated in Figure 3, which simply forwards unicast traffic (both media and Real-Time Transport Control Protocol (RTCP) traffic) among all the unicast connections to a central Lennox Expires September 6, 2012 [Page 4] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 translator. +---+ +------------+ +---+ | A |<---->| Media & |<---->| B | +---+ | RTCP | +---+ | Modifier | +---+ | or | +---+ | C |<---->| Terminator|<---->| D | +---+ +------------+ +---+ Figure 4: RTCP-Modifying Central Box By contrast, the topologies Topo-Media-Translator, Topo-Mixer, Topo- Video-Switch-Mixer, and Topo-RTCP-Terminating-MCU can all be summarized by the diagram shown in Figure 4. These topologies all have the common property that they have a central box (a media translator, mixer, or MCU) which terminates media and RTCP traffic, and forwards it, modified to a greater or lesser extent, to the topology's other endpoints. 4. RTP Topologies and SDP Offer/Answer The SDP Offer/Answer Model [RFC3264] specifies different behavior depending on whether the address of the transport connection being negotiated is a unicast and multicast address. Effectively, offer/ answer assumes that the stream being negotated corresponds either to Topo-Point-to-Point or Topo-Multicast. Most of the RFC 5117 unicast topologies described in Section 3 can be negotiated by the centralized point negotating with each endpoint using the Offer/Answer unicast mode. However, the Topo-Transport- Translator cannot be. The difficulty is that SDP Offer/Answer unicast exchange is designed to negotate each end of the excahnge's separate view of the session, and each endpoint has a fair bit of control over what its view of the session should look like. However, because the translator at the center of the Topo-Transport-Translator topology forwards media and RTCP unmodified, it is necessary that all participants have a common view of all non-transport aspects of the session. Thus, the freedom that the Offer/Answer model gives each endpoint to control its view of the session prevents the central box from enforcing a single, uniform view of it. Among the session aspects that can be different among the session participants are: Lennox Expires September 6, 2012 [Page 5] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 Media Types: Unicast Offer/Answer participants have the freedom to remove media types from the session description (in an answer or an updated offer). They also have the freedom to change some fmtp media type parameters. Moreover, though RFC 3264 indicates that it is NOT RECOMMENDED, they have the freedom to change the mapping between media typees and RTP payload type numbers. Bandwidth: An answerer can specify a bandwidth attribute (SDP b= value) for any media stream, indicating the bandwidth that the answerer would like the offerer to use when sending media. This does bear any relationship to bandwidth values in use in the other direction. (This is somewhat problematic as SDP bandwidth parameters are used to calculate RTCP bandwidth, and thus RTP session membership timeout intervals.) Packetization Time: An SDP offer or answer can specify the ptime attribute (packetization time interval) with which it wants to receive media. This value is independent in offers and answers. In addition to these mismatches for the attributes specified by the core SDP Offer/Answer specification, there are of course many extensions to SDP which specify Offer/Answer behavior. These are not discussed here, but many of them would have similar issues with the Topo-Transport-Translator topology. Any of the media and RTCP terminating topologies described in Section 3 as modifying media and RTCP will be able to repair these mismatches, or else reject an endpoint that asks for a configuration beyond its capacity to repair. The mismatch difficulties arise only for the Topo-Transport-Translator. 5. Advantages for Assuming RTCP rewriting If we assume that we always have a central box that can rewrite, or generates its own, media and RTCP, a number of optimizations and protocol clarifications become possible. 5.1. Independent RTCP bandwidth SDP Unicast Offer/answer allows RTP session bandwidth to be specified independently in each direction of the offer/answer exchange. The assumption is that bandwidth in each direction is (over the relevant bottleneck links) non-rival, and that the available bitrates can in some circumstances be dramatically asymmetric. It has always been somewhat unclear how offer/answer assymetric bandwidths interact with the RTCP bandwidth fraction (5%, or the SDP bandwidth modifiers). Lennox Expires September 6, 2012 [Page 6] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 If we assume that RTCP is never passively relayed, but rather will always either be consumed locally or will actively be rewritten before being forwarded, this problem largely goes away. Each side of the unicast RTP session domain gets the appropriate fraction of its (sending) RTP bandwidth to send RTCP. It can divide this fraction among its sources as it wishes, subject ot the constraint that a regular report is sent for each source with appropriate frequency to prevent timeouts. Group size estimation is only needed for timeout calculation. It can be done independently for sending and receiving media. Since RTCP bandwidth can be shared among all the sources, a sender can then also send feedback from multiple of its sources in a single compound RTCP packet, up to transport MTU issues, reducing transport overhead. 5.2. Optimization of receiver reports For the benefit of Topo-Multicast and Topo-Transport-Translator, in an RTCP session, all session participants send RTCP reception reports (in SR or RR RTCP packets) for every active RTP source from which they have received packets in the previous reporting interval. This means that the number of reception reports is quadratic in the number of sources in a conference. (Specifically, the number equals the number of conference participants, times the number of active senders whos sent during a report interval. However, because the report interval itself scales with the number of sources, this will in a many-to-many conference converge to being quadratic in the number of sources.) In cases where there is an media-and-RTCP-modifying middlebox, this quadratic behavior is useless. The relevant reception report information is that between and endpoint and the middlebox, since the middlebox can often perform reliability and repair mechanisms on its own. These excess reception reports then increase the size of RTCP packets, which by the formulas for calculating RTCP packet transmission schedules reduces the RTCP timing interval. Thus, these excess reception reports consume bandwidth which could instead be used for timely RTCP feedback of relevant data. These quadratic reception reports are particularly useless in scenarios where a given session participant is sending multiple sources of its own (rather than forwarding multiple remote sources) in the same RTP session. Examples of such use cases are the CLUE Telepresence model [I-D.lennox-clue-rtp-usage], bundling of multiple media types onto a single RTP session [I-D.ietf-mmusic-sdp-bundle-negotiation], and single-session RTP Lennox Expires September 6, 2012 [Page 7] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 retransmission [RFC4588]; in general, this will apply to most scenarios in which SDP source descriptions [RFC5576] are used. The most useless data is reception reports by one local source about another, since these will always (by definition) be "received" perfectly (with zero loss and jitter) by their sender. Nearly as useless redundant feedback from multiple co-located sources about the same remote source. Since RTP traffic is in fact received by an endpoint, not a source, this information will either be identical (if an endpoint choses to synchronize its RTCP feedback messages) or multiple, non-commensurate transmissions of the same information (if it does not). Also often useless is feedback by one remote source about another one -- while there are some conceivable use cases where this could be relevant information (for instance, a monitoring application), in most conferencing models, this is uninteresting and unimportant. 6. Normative recommendations Based on the analysis in Section 5, this section makes some normative recommendations for the behavior of RTP endpoints in sessions negotiated using unicast SDP Offer/Answer. (Open issue: it is possible that these recommendations might need to be a normative update to [RFC3550]; alternatively, they may just be implementation guidance.) When an RTP [RFC3550] session is negotiated using unicast SDP offer/ answer [RFC3264], RTCP bandwidth, and thus RTCP packet intervals and RTP group membership timeout rules, MUST be calculated separately for the receiving and sending direction, using the rules specified in [RFC3550] as modified by any SDP attributes or the RTP profile in use. An endpoint MAY send RTCP up to its available bandwidth, independent of the bandwidth consumed in the reverse direction, again subject to the SDP modifiers and profiles in use. An endpoint MAY choose to send multiple sources' RTCP messages in a single compound RTCP packet (though such compound packets SHOULD NOT exceed the path MTU, if avoidable and if it is known). This will reduce the average compound RTCP packet size, and thus increase the frequency with which RTCP messages can be sent. Regular (non- feedback) RTCP compound packets MUST still begin with an SR or RR packet, but otherwise MAY contain RTCP packets in any order. Receivers MUST be prepared to receive such compound packets. Lennox Expires September 6, 2012 [Page 8] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 An endpoint SHOULD NOT send reception reports from one of its own sources about another one ("cross-reports"). Endpoints receiving reception reports MUST be prepared that their peers might not be sending reception reports about their own sources. Similarly, an endpoint sending multiple sources SHOULD NOT send reception reports about a remote source from more than one of its local sources. Instead, it SHOULD create or pick one local source as the "reporting" source for each remote source, which sends full report blocks; all its other sources SHOULD be treated as if they were disconnected, and never saw that remote source. This reporting source MAY be one of the sending sources in the session, or MAY be a receive-only source created simply for the purpose of sending feedback. An endpoint MAY choose different local sources as the reporting source for different remote sources (for example, if it is using bundle [I-D.ietf-mmusic-sdp-bundle-negotiation], it could choose to send reports about remote audio sources from its local audio source, and reports about remote video sources from its local video source), or it MAY choose a single local source for all its reports. If the reporting source leaves the session (sends BYE), another reporting source MUST be chosen. If the AVPF [RFC4585] RTP profile, or one if its secure equivalents, is in use, this "reporting" source SHOULD also be the source for any AVPF feedback messages about its remote sources, as well. Endpoints interpreting reception reports MUST be prepared to receive RTCP SR or RR messages where only one remote source is reporting about its sources. 7. Limitations of media and RTCP modifying middleboxes There are a few limitations of media and RTCP modifying middleboxes, compared to what can be done by the Topo-Transport-Translator topology. A media and RTCP modifying middlebox will, necessarily, be more complex (and thus be more expensive, or have lower capacity), than a pure transport forwarder. It is not possible to deploy new RTCP extensions across an unmofidified RTCP-modifying central box, as that box will not know how to re-write these extensions so they are correctly forwarded. If SRTP is in use, these central middleboxes must be trusted with the SRTP keying material. (Since SRTP keying material is usually negotiated hop-by-hop, they may be doing a complete SRTP decryption and re-encryption, with unrelated keys, and possibly even translating between different ciphers or cipher strengths.) Lennox Expires September 6, 2012 [Page 9] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 It is possible, if the recommendations of Section 6 are in use, that a naive RTCP monitor might think that an RTP flow should actually be interpreted as Topo-Transport-Translator. In this case, it might think that there is a network disconnection between the non-reporting sources and the sources on which they are not reporting. However, architecturally it is very unclear if such monitors actually exist, for conferencing applications, or would care about a disconnection of this sort. 8. Security Considerations See the security considerations of [RFC5117]. Notably, as discussed in Section 7, a centralized media and RTCP modifying box will need to terminate SRTP and SRTCP, and so must be a trusted entity. 9. IANA Considerations This document makes no requests of IANA. Note to the RFC Editor: please remove this section before publication. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. Lennox Expires September 6, 2012 [Page 10] Internet-Draft RTP Offer/Answer Topology Considerations March 2012 10.2. Informative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in progress), February 2012. [I-D.lennox-clue-rtp-usage] Romanow, A., Lennox, J., and P. Witty, "Real-Time Transport Protocol (RTP) Usage for Telepresence Sessions", draft-lennox-clue-rtp-usage-02 (work in progress), February 2012. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. Author's Address Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Lennox Expires September 6, 2012 [Page 11]