Internet DRAFT - draft-lennox-avtcore-rtp-topo-offer-answer
draft-lennox-avtcore-rtp-topo-offer-answer
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]
