Network Working Group                                       I. Johansson
Internet-Draft                                             M. Westerlund
Intended status: Standards Track                             Ericsson AB
Expires: May 22, 2008                                       Nov 19, 2007

     Support for non-compound RTCP, opportunities and consequences

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This memo discusses benefits and issues that arise when allowing RTCP
   packets to be transmitted as non-compound packets, i.e not follow the
   rules of RFC 3550.  Based on that analysis this memo proposes changes
   to the rules to allow feedback messages to be sent as non-compound
   RTCP packets when using the RTP AVPF profile (RFC 4585) under certain

Johansson & Westerlund    Expires May 22, 2008                  [Page 1]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RTCP Compound Packets  . . . . . . . . . . . . . . . . . . . .  3
   3.  Benefits with non-compound packets . . . . . . . . . . . . . .  4
   4.  Issues with non-compound RTCP packets  . . . . . . . . . . . .  6
     4.1.  Middle boxes . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Packet Validation  . . . . . . . . . . . . . . . . . . . .  6
       4.2.1.  Old RTCP Receivers . . . . . . . . . . . . . . . . . .  6
       4.2.2.  Weakened Packet Validation . . . . . . . . . . . . . .  7
       4.2.3.  Bandwidth consideration  . . . . . . . . . . . . . . .  7
       4.2.4.  Computation of avg_rtcp_size . . . . . . . . . . . . .  7
     4.3.  Header compression . . . . . . . . . . . . . . . . . . . .  7
     4.4.  RTP and RTCP multiplex on the same port  . . . . . . . . .  7
   5.  Use cases for non-compound RTCP  . . . . . . . . . . . . . . .  8
     5.1.  Control plane signaling  . . . . . . . . . . . . . . . . .  8
     5.2.  Codec control signaling  . . . . . . . . . . . . . . . . .  8
     5.3.  Feedback . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Status reports . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Rules and guidelines for non-compound packets in AVPF  . . . .  9
     6.1.  Verifying the delivery of non-compound packets . . . . . . 10
     6.2.  Modified bandwidth computation . . . . . . . . . . . . . . 10
       6.2.1.  Bandwidth allocation . . . . . . . . . . . . . . . . . 11
       6.2.2.  Temporary immediate mode . . . . . . . . . . . . . . . 12
       6.2.3.  Open issues  . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  SDP Signalling Attribute . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Johansson & Westerlund    Expires May 22, 2008                  [Page 2]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

1.  Introduction

   In RTP [RFC3550] it is currently mandatory to always use RTCP
   compound packets containing at least Sender Reports or Receiver
   reports, and a SDES packet containing at least the CNAME item.  There
   are good reasons for this as discussed below (see Section 2).
   However this do result in that the minimal RTCP packets are quite
   large.  The RTP profile AVPF [RFC4585] specifies new RTCP packet
   types for feedback messages.  Some of these feedback messages would
   benefit from being transmitted with minimal delay and AVPF do provide
   some mechanism to enable this.  However for environments with low-
   bitrate links this still consumes quite large amount of resources and
   introduce extra delay in the time it takes to completely send the
   compound packet in the network.  There are also other benefits as
   discussed in Section 3.

   The use of non-compound packets is not without issues.  This is
   discussed in Section 4.  These issues needs to be considered and is
   one motivation for this document.

   In addition this document proposes how AVPF could be updated to allow
   the transmission of non-compound packets in a way that would not
   substantially affect the mechanisms that compound packets provide.
   The connection to AVPF is motivated by the fact that non-compound
   RTCP is mainly intended for event driven feedback purposes and that
   the AVPF early and immediate modes makes this possible.

2.  RTCP Compound Packets

   Section 6.1 in RFC3550 [RFC3550] specifies that an RTCP packet must
   be sent in a compound packet consisting of at least two individual
   packets, first an Sender Report (SR) or Receiver Report (RR),
   followed by an SDES packet containing at least a CNAME Item for the
   transmitting source identifier (SSRC).  Lets examine what these RTCP
   packet types are used for.

   1.  The sender and receiver reports (see Section 6.4 of RFC 3550
       [RFC3550]) provides the RTP session participant with the Sender
       Source Identifier (SSRC) of all RTCP senders.  Having all
       participants send these packets periodically allows everyone to
       determine the current number of participants.  This information
       is used in the transmission scheduling algorithm.  Thus this is
       particularly important for new participants so that they quickly
       can establish a good estimate of the group size.  Failure to do
       this would result in RTCP senders consuming to much bandwidth.

Johansson & Westerlund    Expires May 22, 2008                  [Page 3]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   2.  The sender and receiver reports contain some basic statistics
       usable for monitoring of the transport and thus enable
       adaptation.  These reports become more useful if sent regularly
       as the receiver of a report can perform analysis to find trends
       between the individual reports.  When used for media transmission
       adaptation the information become more useful the more frequently
       it is received, at least until one report per round-trip time
       (RTT) is achieved.  Therefore there are most cases no reason to
       not include the sender or receiver report in all RTCP packets.

   3.  The CNAME SDES item (See Section 6.5.1 of RFC 3550 [RFC3550])
       exist to allow receivers to determine which media flows that
       should be synchronized with each other between different RTP
       sessions carrying different media types.  Thus it is important to
       quickly receive this for each media sender in the session when
       joining an RTP session.

   4.  Sender Reports (SR) is used in combination with the above SDES
       CNAME mechanism to establish inter media synchronization.  After
       having determined which media streams should be synchronized
       using the CNAME field, the receiver uses the Sender Report's NTP
       and RTP timestamp fields to establish synchronization.

   Reviewing the above it is obvious that both SR/RR and the CNAME are
   very important for new session participants to be able to utilize any
   received media and to avoid flooding the network with RTCP reports.
   In addition, if not sent regularly the dynamic nature of the
   information provided would make it less and less useful.

3.  Benefits with non-compound packets

   As mentioned in the introduction, most advantages of using non-
   compound packets exists in cases when the available RTCP bit-rate is
   limited.  This because non-compound packets will be substantially
   smaller than a compound packet.  A compound packet is forced to
   contain both an RR or an SR and the CNAME SDES item.  The RR
   containing a report block for a single source is 32 bytes, an SR is
   52 bytes.  Both may be larger if they contain report blocks for
   multiple sources.  The SDES packet containing a CNAME item will be 10
   bytes plus the CNAME string length.  Here it is reasonable that the
   CNAME string is at least 10 bytes to get a decent collision
   resistance.  And if the recommended form of user@host is used, then
   most strings will be longer than 20 characters.  Thus a non-compound
   packets can become at least 70-80 bytes smaller than the compound

   The following benefits exist for the smaller non-compound packets:

Johansson & Westerlund    Expires May 22, 2008                  [Page 4]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   1.  Shorter serialization time, i.e the time it takes the link to
       transmit the packet.  For slower links this time can be
       substantial.  For example transmitting 120 bytes over an link
       interface capable of 30 kbps takes 32 milliseconds (ms) assuming
       uniform transmission rate.

   2.  For links where the packet loss rate grows with the packet size,
       smaller packets will be less likely to be dropped.  Example of
       such links are radio links.  In the cellular world there exist
       links that are optimized to handle RTP packets with speech and
       these packets common sizes, the rationale behind this is to be
       able to increase the capacity and coverage for voice services.
       Compound RTCP packets commonly are 2-3 times the size of a RTP
       packet with compressed speech.  If the speech packet over such a
       bearer have a packet loss probability of p, then the RTCP packet
       will experience 1- (1-p)^x where x is the number of fragments the
       compound packet will be split on the link layer, i.e. 2 or 3

   3.  In fixed links there are also benefits with sending feedback in
       small non-compound RTCP.  One such application is those that use
       RTCP AVPF in early or immediate mode to send frequent event
       driven feedback.  Under these circumstances the use of non-
       compound RTCP minimizes the risk that the RTCP bandwidth becomes
       too high during periods of intense adaptation feedback signaling.

   4.  In cases when regular feedback is need, like in the profile under
       development for TCP friendly rate control (TFRC) for RTP
       [I-D.ietf-avt-tfrc-profile].  The size of compound RTCP can
       result in very high bandwidth requirements for the feedback in
       case the round trip time is short.  For this particular
       application non-compound RTCP gives a very substantial

   In cases when non-compound packets carry important and time sensitive
   feedback both shorter serialization time and the lower loss
   probability are important to enable the best possible functionality.
   Having a packet loss rate that is much higher for the feedback
   packets compared to media packets is not advantageous when for
   example trying to perform media adaptation to handle the e.g changed
   performance present at the cell border in cellular system.

   For high bit-rate applications there is usually no problem of
   supplying RTCP with sufficient bit-rates.  When using AVPF one can
   use the "trr-int" parameter to restrict the regular reporting
   interval to approximately once per RTT or less often.  As in most
   cases there are no reasons to provide regular reports with higher
   density than this.  Any additional bandwidth can then be used for

Johansson & Westerlund    Expires May 22, 2008                  [Page 5]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   feedback messages.  The benefit of non-compound packets in this case
   is limited, but exist.  One typical example is video using generic
   NACK in cases where the RTT is low.  Using non-compound packets would
   reduce the total amount of bits used for RTCP.  This is primarily
   applicable if the number of non-compound packets is large.  This
   would also result in lower processing delay and less complexity for
   the feedback packets as they do not need to query the RTCP database
   to construct the right messages.

4.  Issues with non-compound RTCP packets

   This section describes some of the known issues with non-compound
   RTCP packets

4.1.  Middle boxes

   Middle boxes in the network may discard RTCP packets that does not
   follow the rules outlined in section 6.1 of RFC3550.  The effect of
   this might for instance be that compound RTCP packets makes its way
   through while the non-compound feedback packets are lost.

4.2.  Packet Validation

   A non-compound packet will be discarded by the packet validation code
   in Appendix A of RFC 3550 [RFC3550].  This has several impacts as
   described in the following sub sections.

4.2.1.  Old RTCP Receivers

   Any RTCP receiver without updated packet validation code will discard
   the non-compound packets.  Thus these receivers will not see the
   feedback contained in the these non-compound packets.  The effect of
   this depends on the type of feedback message and the role of the
   receiver.  For example this may cause complete function loss in the
   case of attempting to use a non-compound NACK message (see Section
   6.2.1 of RFC 4585 [RFC4585]) to non updated media sender in a session
   using the retransmission scheme defined by RFC 4588 [RFC4588].

   This type of discarding would also effect the feedback suppression
   defined in AVPF.  The result would be a partitioning of the receivers
   within the session between old ones only seeing the compound RTCP
   feedback messages and the newer ones seeing both.  Where the old ones
   may send feedback messages for events already reported on in non-
   compound packets.

Johansson & Westerlund    Expires May 22, 2008                  [Page 6]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

4.2.2.  Weakened Packet Validation

   The packet validation code needs to be rewritten to accept non-
   compound packets.  One potential effect of this change is much weaker
   validation that received packets actually are RTCP packets, and not
   packets of some other type being wrongly delivered.  Thus some
   consideration should be done to ensure the best possible validation
   is available.  For example restricting non-compound packets to
   contain only some specific RTCP packet types, that is preferably
   signalled on a session basis.  A solution to this is presented in
   Section 6.2

4.2.3.  Bandwidth consideration

   The discarding of non-compound RTCP packets would effect the RTCP
   transmission calculation in the following way; the avg_rtcp_size
   value would become larger than for RTP receivers that exclude the
   non-compound in this calculation (assuming that non-compound packets
   are smaller than compound ones).  Therefore these senders would
   under-utilize the available bit-rate and send with a longer interval
   than updated receivers.  For most sessions this would should not be
   an issue.  However for sessions with a large portion of non-compound
   packets may result in that the updated receivers time out non-updated
   senders prematurely.  A solution to this is presented in Section 6.2.

4.2.4.  Computation of avg_rtcp_size

   Long intervals between compound RTCP packets and many non-compound
   RTCP packets in between may lead to a computation of the value
   avg_rtcp_size that varies greatly over time.  A solution to this is
   presented in Section 6.2.

4.3.  Header compression

   The classifiers for header compression algorithms such as RoHC
   [RFC3095] and its profiles must be aware of the fact that, with the
   proposed non-compound RTCP packets, the first RTCP packet type might
   differ from 200 or 201.  Otherwise they may wrongly classify the
   packets as something else than RTCP.  This may have impact on the
   compression efficiency.

4.4.  RTP and RTCP multiplex on the same port

   In applications that multiplexes RTP and RTCP on the same port, as
   defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to
   ensure that the de multiplexing is done properly even though RTCP
   packets are non-compound.

Johansson & Westerlund    Expires May 22, 2008                  [Page 7]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

5.  Use cases for non-compound RTCP

   Below are listed a few use cases for non-compound RTCP.  It is worth
   notice here that the current use of non-compound RTCP and the
   applications is thoroughly specified in other standardization bodies
   and for services that have a meaning inside each standardization
   forum and is limited to a specific service such as PoC or 3GPP-MTSI.
   A general definition of the use of non-compound RTCP for e.g control
   plane or codec control signaling would probably need to be specified
   inside the IETF.

5.1.  Control plane signaling

   Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC]
   makes use of non-compound packets when transmitting certain events.
   The OMA POC service is primarily used over cellular links capable of
   IP transport, such as the GSM GPRS.

5.2.  Codec control signaling

   Examples of codec control usage for non-compound RTCP is found in

   Another example that can be used with non-compound RTCP are e.g the
   TMMBR messages as specified in [I-D.ietf-avt-avpf-ccm] that signals a
   request for a change in codec bitrate.  The benefit with transmitting
   these messages is that the likelihood that they are transmitted
   successfully in bad channel conditions can in some cases be
   considerably higher than if they are put in larger compound RTCP.
   This is critical as these messages predominantly occurs when channel
   conditions are poor.

5.3.  Feedback

   The feedback scenario is best presented e.g as Video with generic
   NACK.  In cases where the RTT is shorter than the receiver buffer
   depth, generic NACK can be used to request retransmission of missing
   information, thus improving play out quality considerably.  If the
   generic NACK packets are transmitted non-compound the bandwidth
   requirement will be minimal, enabling more frequent feedback.  Like
   in the Codec control case it is crucial that these packets can be
   transmitted as non-compound RTCP and also in some cases with as
   little delay as possible.

   Another interesting use for non-compound RTCP is in cases when
   regular feedback is need, like in the profile under development for
   TCP friendly rate control (TFRC) for RTP [I-D.ietf-avt-tfrc-profile].
   The size of compound RTCP can result in very high bandwidth

Johansson & Westerlund    Expires May 22, 2008                  [Page 8]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   requirements for the feedback in case the round trip time is short.
   For this particular application non-compound RTCP may give a very
   substantial improvement.

5.4.  Status reports

   One idea that is discussed is to transmit small measurement or status
   reports in non-compound RTCP or to be able to split the parts of e.g
   a minimum compound RTCP into its parts and transmit them separately.
   The status reports can be used either by the endpoints of by other
   network monitoring boxes in the network.

   The benefit is that with some radio access technologies small packets
   are more robust to poor radio conditions than large packets.
   Additionally, with small (report) packets there is a smaller risk
   that the report packets affects the channel that it reports upon.

   In principle it is perfectly OK to convey all sorts of information as
   non-compound RTCP by means of e.g. a new RTCP packet type with a new
   payload type.  It is for instance possible to specify a number of
   measurement metrics in separate small non-compound RTCP.  However a
   few issues needs to be considered.

   o  A risk exists that it opens up for a whole set of incompatible
      metrics and reports devised in various standardization fora
      leading to a potential interoperability problems.

   o  Middle boxes or third party network monitoring equipment may fail
      to understand the new reports or even discard these new report

   o  There may arise a need to verify that these "special" reports
      reach the intended recipient in case middle boxes in the network
      discards unknown reports.

6.  Rules and guidelines for non-compound packets in AVPF

   Based on the above analysis it seems feasible to allow transmission
   of non-compound RTCP under some restrictions.  First of all it is
   important that compound packets are regularly sent to ensure the
   feedback reporting works.  The tracking of session size and number of
   participants is also important as this ensures that the RTCP
   bandwidth remain bounded independent of the number of session
   participants.  As the compound packets also are used to establish the
   synchronization, any newly joining participant in a session would
   need to receive a compound packet from the media sender.  In summary
   the regular usage of compound packets must be maintained throughout

Johansson & Westerlund    Expires May 22, 2008                  [Page 9]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   the complete session.  Thus non-compound packets should be restricted
   to be used as extra feedback packets sent in cases when a regular
   compound packet would not have been sent.

   The usage of non-compound RTCP packet SHALL only be done in RTP
   sessions operating in AVPF [RFC4585] Early RTCP or Immediate feedback
   mode.  Non-compound packets SHALL NOT be sent until at least one
   compound packet has been sent.  In Immediate feedback mode all
   feedback messages MAY be sent as non-compound packets.  In early RTCP
   mode a feedback message scheduled for transmission as an Early RTCP
   packet, i.e not a Regular RTCP packet, MAY be sent as a non-compound

6.1.  Verifying the delivery of non-compound packets

   If an application is to use non-compound packets it is important to
   verify that they actually reaches the session participants.  As
   outlined above in Section 4.1 and Section 4.2 packets may be
   discarded along the path or in the end-point.  The end-points can be
   resolved by introducing signaling that informs if all session
   participants are capable of non-compound packets or not.  The middle
   box issue is more difficult and here one will be required to use
   heuristics to determine if the non-compound packets are delivered or
   not.  However in many cases the feedback messages sent using non-
   compound packets will result in either explicit or implicit
   indications that they have been received.  Example of such are the
   RTP retransmission [RFC4588] that result from a NACK message
   [RFC4585], the Temporary Maximum Media Bit-rate Notification message
   resulting from a Temporary Maximum Media Bit-rate Request
   [I-D.ietf-avt-avpf-ccm], or the presence of a Decoder Refresh Point
   [I-D.ietf-avt-avpf-ccm] in the video media stream resulting from the
   Full Intra Request sent.

   A proposed algorithm to detect consistent failure of delivery of non-
   compound packets needs to be written.  The details of this algorithm
   is application dependent and therefore outside the scope of this

   If the verification fails it is strongly recommended that only
   compound RTCP according to the rules outlined in RFC3550 is

6.2.  Modified bandwidth computation

   In order to make the best possible use of the non-compound RTCP and
   also to enable a stable estimate of avg_rtcp_size it is necessary to
   modify the bandwidth computation in Appendix A of RFC 3550 [RFC3550].

Johansson & Westerlund    Expires May 22, 2008                 [Page 10]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   The concept behind the algorithm modifications is to treat small and
   large RTCP packets separately.  There are a number of reasons to this

   o  More stable estimate of avg_rtcp_size.

   o  Easier to allocate bandwidth between small and large RTCP packets.

   One question that arise is how to distinguish between small (non-
   compound) and large (compound) RTCP.  A few alternatives:

   o  Payload type: A non-compound RTCP may have a (first) PT number
      that differs from the PT numbers for SR or RR.  This may be a weak
      alternative as some interest to be able to split minimum compound
      RTCP is expressed, see Status reports (Section 5.4).  A possible
      problem here is also that this distinction does not actually tell
      the size of the RTCP.

   o  Fixed size, set in specification.  For instance one may base the
      distinction on the likely minimum size of a minimal compound RTCP.
      Assuming that such a packet will contain at least an SR (32 bytes)
      and a SDES CNAME (likely 16 bytes or more) one can conclude that
      48 bytes (+IP/UDP overhead) is probably the smallest realistic
      size of a compound RTCP.

   o  Fixed size, set in session setup : Some sessions may e.g use
      RTCP-XR or some other RTCP reporting on occasions that may give
      very large packet sizes, it may be desirable to adjust the

   o  Variable size: As non-compound RTCP is by definition RTCP that
      does not follow the rules for compound RTCP as they are specified
      in RFC3550, the size can be determined "on the fly".

6.2.1.  Bandwidth allocation

   The distinction between compound and non-compound RTCP opens up for a
   possibility to allocate the available RTCP bandwidth between compound
   and non-compound RTCP.  There are two alternatives how to solve this.

   o  SDP attribute "trr-int": The combination of the total allocated
      RTCP bandwidth and the "trr-int" attribute allows non-compound
      RTCP to use the remaining RTCP bandwidth, thus a separate minimum
      transmit interval is computed for the non-compound RTCP.

   o  ncp-share: A new attribute that tells how much of the total RTCP
      bandwidth should be allocated for non-compound RTCP.

   It is possible to combine the two methods above.

Johansson & Westerlund    Expires May 22, 2008                 [Page 11]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

6.2.2.  Temporary immediate mode

   From the discussion about possible use cases in Section 5, one can
   see two extreme scenarios for the use of non-compound RTCP.

   1.  Sparse transmission : For example generic NACK

   2.  Dense transmission : For example TFRC

   In use case 2 the algorithm outline in Section 6.2.1 gives optimal
   use of the available RTCP bandwidth.  In use case 1 however the
   available RTCP bandwidth will be underutilized.

   This opens up for the option to temporarily allow immediate
   transmission of non-compound RTCP as long as the used RTCP bandwidth
   stays under the allowed RTCP bandwidth measured over a given time
   span.  The proposed algorithm outline below describes how immediate
   transmission in scenarios where non-compound RTCP is sparse can be
   allowed without a risk of over consuming RTCP bandwidth in scenarios
   where non-compound RTCP is dense.

   o  Let allow_immediate_ncp_ok be a flag that signals that immediate
      transmission of non-compound RTCP is possible.

   o  When a regular (compound) RTCP is transmitted.

      *  Compute the bandwidth consumed by compound RTCP

      *  Compute the bandwidth consumed by non-compund RTCP

      *  Compute the allowed number bytes for immediate non-compound
         RTCP (max_immediate_bytes_TX_ncp) as based on the total
         available RTCP bandwidth, actual_rtcp_cp_bw, actual_rtcp_ncp_bw
         and the time since the last regular RTCP

      *  The variable allow_immediate_ncp_ok is set to true as long as
         the number of transmitted bytes belonging to non-compound RTCP
         (immediate_bytes_TX_ncp) is below the

      *  The variable immediate_bytes_TX_ncp is set to zero each time a
         regular RTCP is transmitted.

      The proposed algorithm outline has the benefit that it allows for
      a large portion of immediate non-compound RTCP in scenarios where
      the non-compound RTCP is sparse while the allowed portion is

Johansson & Westerlund    Expires May 22, 2008                 [Page 12]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

      almost zero when non-compound RTCP is dense.  This gives an
      algorithm that allows both for fast feedback and safe RTCP
      bandwidth utilization.

   To conclude, the collection of modifications gives a few benefits.

   o  More stable avg_rtcp_size as compound and non-compound RTCP are
      handled separately.

   o  Shorter transmission interval for non-compound RTCP further
      leading to:

      *  Fewer skipped non-compound RTCP.  A non-compound RTCP can be
         skipped (or replaced) if it is still scheduled for transmission
         when a new non-compound RTCP of the same type is put on the
         queue.  As the min transmission interval calculated with the
         proposed modification is lower (especially when transmission of
         non-compound RTCP is sparse) the risk of skipped non-compound
         RTCP is smaller.

   o  Sensitive feedback can be transmitted with no transmission delay
      in cases when feedback is sparse.  Unlike the AVPF immediate mode
      which does not concern about the bandwidth utilization and thus is
      not apt for larger groups, the proposed use of allow_immediate_ncp
      allows for immediate transmission of feedback (non-compound RTCP)
      as long as the bandwidth utilization stays below the designated

   o  The algorithm does not impose any requirement that other clients
      in a session implements the modifications.

6.2.3.  Open issues

   The proposed algorithm has been verified with Matlab simulations and
   the results look promising.  There are however a few open issues that
   needs to be addressed.

   o  Varying RTCP size: Especially compound RTCP may vary quite a lot.
      So far a fixed size for non-compound and compound RTCP has been

   o  Number of members in session might vary: This may affect the
      bandwidth estimation algorithms in a negative way.

   o  Very high bitrates: So far only relatively small RTCP bandwidths
      are tested.

Johansson & Westerlund    Expires May 22, 2008                 [Page 13]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   o  Feedback suppression: For large groups the proposed use of
      allow_immediate_ncp_ok may lead to a feedback implosion.  The
      dithering rules in RFC4585 may be applicable here.

   o  Feedback flooding: The proposed algorithm outline does not prevent
      the application from sending feedback at a very high rate as long
      as allow_immediate_ncp_ok is true, this may affect the media
      stream negatively, this is related to the feedback suppression

   o  A general mapping to the rules and function in RFC4585 is missing.

6.3.  SDP Signalling Attribute

   We request to define the a "a=ncp" [RFC4566] attribute to indicate if
   the session participant is capable of supporting non-compound
   packets.  It is a required that a participant that proposes the use
   of non-compound RTCP itself supports the reception of non-compound
   RTCP.  Also it is possible that we request to define the "a=ncp-
   share" attribute.

7.  IANA Considerations

   IANA will be required to register the SDP signalling attribute
   defined in Section 6.3.

8.  Security Considerations

   The security considerations of RTP [RFC3550] and AVPF [RFC4585] will
   apply also to non-compound packets.  The reduction in validation
   strength for received packets on the RTCP port may result in a higher
   degree of acceptance of spurious data as real RTCP packets.  This
   vulnerability can mostly be addressed by usage of an security
   mechanism that provide authentication, e.g.  SRTP[RFC3711].

9.  Acknowledgements

   The authors would like to thank all the people who gave feedback on
   this document.

   This document also contain some text copied from RFC 4585 [RFC4585]
   and we take the opportunity to thank the author of said document.

10.  References

Johansson & Westerlund    Expires May 22, 2008                 [Page 14]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

10.1.  Normative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [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.

10.2.  Informative References

              3GPP, "Specification : 3GPP TS 26.114 (v7.1.0
              Specs_update_after_SA36/", March 2007.

              Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback  (AVPF)", draft-ietf-avt-avpf-ccm-10 (work
              in progress), October 2007.

              Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port",
              draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
              August 2007.

              Gharai, L., "RTP with TCP Friendly Rate Control",
              draft-ietf-avt-tfrc-profile-10 (work in progress),
              July 2007.

   [OMA-PoC]  Open Mobile Alliance, "Specification : Push to talk Over
              Cellular User Plane,
              November 2006.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

Johansson & Westerlund    Expires May 22, 2008                 [Page 15]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

Authors' Addresses

   Ingemar Johansson
   Ericsson AB
   Laboratoriegrand 11
   SE-971 28 Lulea

   Phone: +46 73 0783289
   Email: ingemar.s.johansson (AT)

   Magnus Westerlund
   Ericsson AB
   Torshamnsgatan 21-23
   SE-164 83 Stockholm

   Phone: +46 8 7190000
   Email: magnus.westerlund (AT)

Johansson & Westerlund    Expires May 22, 2008                 [Page 16]

Internet-Draft      Non-compund RTCP in RTCP profile            Nov 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Johansson & Westerlund    Expires May 22, 2008                 [Page 17]