<?xml version='1.0'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 SYSTEM
      'reference.RFC.2119.xml'>
    <!ENTITY rtp SYSTEM
      'reference.RFC.3550.xml'>
    <!ENTITY rtptopo SYSTEM
      'reference.RFC.5117.xml'>
    <!ENTITY sip SYSTEM
      'reference.RFC.3261.xml'>
    <!ENTITY sdp SYSTEM
      'reference.RFC.4566.xml'>
    <!ENTITY rtprtx SYSTEM 
      'reference.RFC.4588.xml'>
    <!ENTITY avpf SYSTEM
      'reference.RFC.4585.xml'>
    <!ENTITY offeranswer SYSTEM
      'reference.RFC.3264.xml'>
    <!ENTITY bundle SYSTEM 
      'reference.I-D.ietf-mmusic-sdp-bundle-negotiation.xml'>
    <!ENTITY sourcedesc SYSTEM 
      'reference.RFC.5576.xml'>
    <!ENTITY cluertp SYSTEM 
      'reference.I-D.lennox-clue-rtp-usage.xml'>
]>

<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>

<rfc category='info' ipr='trust200902' docName='draft-lennox-avtcore-rtp-topo-offer-answer-00'>
    <front>
        <title abbrev='RTP Offer/Answer Topology Considerations'>
		Real-Time Transport Protocol (RTP) Topology Considerations for Offer/Answer-Initiated Sessions.
        </title>

        <author initials='J.' surname='Lennox'
                fullname='Jonathan Lennox'>
            <organization abbrev='Vidyo'>
               Vidyo, Inc.
            </organization>
            <address>
               <postal>
                   <street>433 Hackensack Avenue</street>
                   <street>Seventh Floor</street>
                   <city>Hackensack</city> <region>NJ</region>
                   <code>07601</code>
                   <country>US</country>
               </postal>
               <email>jonathan@vidyo.com</email>
            </address>
        </author>

        <date />
        <area>RAI</area>
        <workgroup>AVTCORE</workgroup>

        <keyword>I-D</keyword>
        <keyword>Internet-Draft</keyword>
		<!-- TODO: more keywords -->

        <abstract>
		<t>
		  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.
		</t>
		<t>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").
		</t>
		<t>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.
		</t>
        </abstract>

    </front>

<middle>

<section title='Introduction' anchor='introduction'>

<t>For interactive conferencing, by the far most common method of
  negotiating <xref target='RFC3550'>Real-Time Tranport Protocol
  (RTP)</xref> sessions is to use the <xref target='RFC4566'>Session
  Description Protocol</xref> <xref target='RFC3264'>Offer/Answer
  Model</xref>.  In particular, conferences are typically negotated
  using offer/answer unicast streams.</t>

<t>As discussed in <xref target='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 <xref target='topos' />,
  one topology in particular cannot be negotiated using SDP
  Offer/Answer: Topo-Transport-Translator.</t>

<t>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 <xref target='optimizations' />, with
  specific recommendations in <xref target='normative' />.</t>

</section>
<section title='Terminology'>

<t>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 <xref
target='RFC2119'>RFC 2119</xref> and indicate requirement levels for
compliant implementations.</t>

</section>

<section title='RTP Topologies' anchor='topos'>

<t><xref target='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.</t>

<figure anchor="point-to-point" title="Point to Point">
<artwork>
<![CDATA[
            +---+         +---+
            | A |<------->| B |
            +---+         +---+
]]>
</artwork>
</figure>

<t>The simplest topology, shown in <xref target='point-to-point' />,
  is Point to Point (Topo-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.</t>

<t>This is topology is straightforwardly negotated by SDP
  Offer-Answer unicast streams.</t>


<figure anchor="multicast" title="Point to Multipoint Using Multicast">
<artwork>
<![CDATA[
                       +-----+
            +---+     /      \    +---+
            | A |----/         \---| B |
            +---+   /   Multi-  \  +---+
                   +    Cast     +
            +---+   \  Network  /  +---+
            | C |----\         /---| D |
            +---+     \       /    +---+
                       +-----+
]]>
</artwork>
</figure>

<t>Secondly, in the Topo-Multicast topology, shown in
  <xref target='multicast' />, 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.</t>

<t>Multicast sessions are often supported within individual domains,
  but are not typically supported accross the public Internet.</t>


<figure anchor="translator" title="RTP Translator (Relay) with Only Unicast Paths">
<artwork>
<![CDATA[
         +---+      +------------+      +---+
         | A |<---->|            |<---->| B |
         +---+      |            |      +---+
                    | Translator |
         +---+      |            |      +---+
         | C |<---->|            |<---->| D |
         +---+      +------------+      +---+
]]>
</artwork>
</figure>

<t>Finally, for the purposes of this discussion, one other topology
  described in <xref target='RFC5117' /> is specifically relevant; the
  others can all be generalized.
  The specific topology is the topology Topo-Transport-Translator,
  illustrated in <xref target='translator' />, which simply forwards
  unicast traffic (both media and Real-Time Transport Control Protocol
  (RTCP) traffic) among all the unicast connections to a central
  translator.</t>

<figure anchor="rtcp-modifier" title="RTCP-Modifying Central Box">
<artwork>
<![CDATA[
         +---+      +------------+      +---+
         | A |<---->|  Media &   |<---->| B |
         +---+      |  RTCP      |      +---+
                    |  Modifier  |
         +---+      |  or        |      +---+
         | C |<---->|  Terminator|<---->| D |
         +---+      +------------+      +---+
]]>
</artwork>
</figure>

<t>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 <xref target='rtcp-modifier' />.  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.</t>

</section>

<section title='RTP Topologies and SDP Offer/Answer'>

<t><xref target='RFC3264'>The SDP Offer/Answer Model</xref> 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.</t>

<t>Most of the RFC 5117 unicast topologies described in
  <xref target='topos' /> can be negotiated by the
  centralized point negotating with each endpoint using the
  Offer/Answer unicast mode.  However, the Topo-Transport-Translator
  cannot be.</t>

<t>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.</t>

<t>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:</t>

<t><list style="hanging">

<t hangText='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.</t>

<t hangText='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.)</t>

<t hangText='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.</t>

</list></t>

<t>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.</t>

<t>Any of the media and RTCP terminating topologies described in
  <xref target='topos' /> 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.</t>

</section>

<section title='Advantages for Assuming RTCP rewriting' anchor='optimizations'>

<t>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.</t>

<section title='Independent RTCP bandwidth'>

<t>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.</t>

<t>It has always been somewhat unclear how offer/answer assymetric
  bandwidths interact with the RTCP bandwidth fraction (5%, or the
  SDP bandwidth modifiers).</t>

<t>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.</t>

<t>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.</t>

</section>

<section title='Optimization of receiver reports'>

<t>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.</t>

<t>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.)</t>

<t>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.</t>

<t>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
  <xref target='I-D.lennox-clue-rtp-usage'>CLUE Telepresence
  model</xref>, <xref target='I-D.ietf-mmusic-sdp-bundle-negotiation'>bundling of
  multiple media types onto a single RTP session</xref>,
  and <xref target='RFC4588'>single-session RTP retransmission</xref>;
  in general, this will apply to most scenarios in
  which <xref target='RFC5576'>SDP source descriptions</xref> are used.</t>

<t>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.</t>

<t>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).</t>

<t>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.</t>

</section>

</section>

<section title='Normative recommendations' anchor='normative'>

<t>Based on the analysis in <xref target='optimizations' />, this
  section makes some normative recommendations for the behavior of RTP
  endpoints in sessions negotiated using unicast SDP Offer/Answer.</t>

<t>(Open issue: it is possible that these recommendations might need to be a
  normative update to <xref target='RFC3550' />; alternatively, they
  may just be implementation guidance.)</t>

<t>When an <xref target='RFC3550'>RTP</xref> session is negotiated
  using unicast <xref target='RFC3264'>SDP offer/answer</xref>,
  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
  <xref target='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.</t>

<t>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.</t>

<t>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.</t>

<t>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 <xref target='I-D.ietf-mmusic-sdp-bundle-negotiation'>bundle</xref>,
  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 <xref target='RFC4585'>AVPF</xref> 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.</t>

</section>

<section title='Limitations of media and RTCP modifying middleboxes' anchor='limitations'>

<t>There are a few limitations of media and RTCP modifying
  middleboxes, compared to what can be done by the
  Topo-Transport-Translator topology.</t>

<t>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.</t>

<t>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.</t>

<t>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.)</t>

<t>It is possible, if the recommendations of
  <xref target='normative'/> 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.</t>

</section>

<section title='Security Considerations' anchor='security'>

<t>See the security considerations of <xref target='RFC5117' />.
  Notably, as discussed in <xref target='limitations' />, a centralized
  media and RTCP modifying box will need to terminate SRTP and SRTCP,
  and so must be a trusted entity.</t>

</section>

<section title='IANA Considerations' anchor='iana'>

<t>This document makes no requests of IANA.</t>

<t>Note to the RFC Editor: please remove this section before publication.</t>

</section>

</middle>

<back>

<references title='Normative References'>

&rfc2119;

&rtp;

&sdp;

&offeranswer;

&avpf;

</references>

<references title='Informative References'>

&rtptopo;

&rtprtx;

&bundle;

&sourcedesc;

&cluertp;

</references>

<!--
<section title='Open issues'>

<t><list style='symbols'>

<t></t>

</list></t>

</section>
-->

<!-- 
<section title='Changes From Earlier Versions'>

<t>Note to the RFC-Editor: please remove this section prior to publication
as an RFC.</t>

<section title='Changes From Draft -00'>

<t><list style='symbols'>

<t></t>


</list></t>

</section>

</section>

-->

</back>

</rfc>

