Subject: RTCP usage in RTSP

From: Rob Lanphier <[email-masked]>
Date: Tue, 15 Oct 1996 12:27:21 -0700

One of the things that we don't take head-on in the RTSP protocol document is
the bandwidth use of RTCP.  We have worked very hard to understand the
importance of RTCP, and I think we need an explanation of the importance of
RTCP in the low-bandwidth, one-to-many model.  We fully understand the
importance of it in a multi-member conference, and we understand the
*general* need for RTCP or something like it.

However, in low-bandwidth broadcasting situations, RTCP becomes a very
problematic requirement for RTP complience.  We understand that RTCP was
designed to function well in a peer-to-peer environment, in which all
participants are both clients and servers at once.  Therefore, in a
multicast setting, RTCP messages are multicasted to all members of a
members of a multicast group.

Let's say you have the client-server topology shown in Figure A

Client A----+         +-----Client E
            |         |
            |         |
Client B----+----+----+-----Client F
                 |
              Server
                 |
Client C----+----+----+-----Client G
            |         |
            |         |
Client D----+         +-----Client H

              Figure A

As I understand it, the idea behind RTCP is that Client A may need
information about Client B's reception, so that it can determine if any
reception problems are specific to it, or are a problem in Subnet 1 as a
whole.  Likewise, Client A may also need to receive samples from Client E
or even Client H to do more diagnostics.

In an effort to compensate for the fact that every client sending reporting
packets could consume the bandwidth of a connection, a 5% limit is imposed
on RTCP traffic by the suggested algorithm used to determine the reporting
interval at each client.  Furthermore, 25% of that (1.25% of the total
bandwidth) is reserved for RTP senders (i.e. the server).  In
high-bandwidth situations, this scales reasonably well, because the RTCP
portion of the communications channel is substantial enough to send
meaningful statistics through.

However, in a low-bandwidth situation (for instance, 2 kilobytes per
second, as is common with modems), this portion of the communications
channel only equates to 100 bytes per second.  Of that, 75 bytes per second
may be used by the clients to multicast RTCP packets through.

That 75 bytes per second must be shared by all clients.  In a situation
where one is broadcasting to 1000 clients, this means that each client may
only send one minimal (80 byte) packet once every 17 or 18 minutes, which
is virtually useless.  Furthermore, since it is client-driven, it won't
necessarily be an evenly controlled 75 bytes per second, so the guarantee
that it stay under 5% is not a rule but merely a guideline.

Even if it is possible to guarantee that the RTCP bandwidth stays under 5%,
what we have found is every byte matters, and even the smallest savings in
overhead can result in much better quality.

Now, another important function of RTCP is jitter calculation, which is
essential to conferencing applications.  In two-way conferencing, keeping
this delay low is essential, since even small delays can make a
conversation unpleasant.  In a one-way broadcasting model, though a start
up delay is unpleasant, it is easier to trade this off for better audio or
video quality.  Removing the 5% overhead caused by RTCP can dramatically
improve quality, so this argues heavily against using RTCP.

Another reason to broadcast RTCP packets is to make it easier for routers
and monitors to monitor quality of service of a local network relative to
the rest of the network carrying the RTP session.  However, I'd like to ask
the members of this list a couple of things:

*  What compelling applications have been built around RTCP monitoring?
*  Why not do this through SNMP?

I'm not arguing against the use of RTCP for high-speed connections.  But
building pragmatic solutions for today's Internet (i.e. still with a large
population accessing it via modem) is a very big concern for us, as it is
for anyone who is trying to squeeze as much performance out of 14.4 and
28.8 connections.

The final reason for using RTCP is for associating CNAME info with SSRCs,
and resolving conflicts between SSRCs.  This is a legitimate need, but
this opens up a whole 'nother can of worms that I would like to address as
a separate issue.  Bandwidth-wise, this presumably makes up such a small
percentage of the RTCP stream that we should be able to give it separate
treatment.

This isn't explicitly stated in the document, but I feel that the RTCP
requirement should be dropped in "compressed RTP".  If no one feels
comfortable calling the resulting transport "RTP", that's fine.  We can
come up with a different name for this varient.  The important thing is
that we have a standard format designed for broadcast to low-bitrate
connections.  This will make the transition to RTP much less painful:

Anticipated Migration:

+-------------+       +-------------+       +-------------+
| Proprietary |       |             |       |             |
|   Control   |       |     RTSP    |       |     RTSP    |
|   Protocol  |       |             |       |             |
+-------------+  -->  +-------------+  -->  +-------------+
| Proprietary |   ^   | Compressed  |   ^   |             |
|  Transport  |   |   |     RTP     |   |   |   RTP/RTCP  |
|   Protocol  |   |   |             |   |   |             |
+-------------+   |   +-------------+   |   +-------------+
		  |			|
    Benefits: ----+			+-------  Benefits:
    *  Internet standard		          *  Designed to work
       control protocol                              with upcoming RTP
    *  Frugal bandwidth                              infrastructure
       usage on today's
       Internet

For this protocol to gain widespread acceptance, it *cannot* put companies
adopting it at a competitive disadvantage.  Raw RTP/RTCP imposes a
"standards tax" that companies will avoid.  I fear that forcing this
overhead on them will cause them to balk and continue developing
proprietary protocols that have more favorable performance characteristics.

Please let me know if these fears are unfounded, and why.

Thanks!
Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Oct 1996 22:08:08 -0700

Comments below:

However, in low-bandwidth broadcasting situations, RTCP becomes a very
problematic requirement for RTP compliance... in a low-bandwidth situation
(for instance, 2 kilobytes per second)... this portion of the communications
channel only equates to 100 bytes per second. Of that, 75 bytes per second
may be used by clients to multicast RTCP packets through. 

This problem is not unique to RTCP; it is also encountered with SAP. And it goes
beyond just the usefulness of the receiver reports. Requiring every RTP receiver to
be a source on the RTCP group is also a scalability issue since DVMRP currently
requires (S,G) state in its forwarding tables. 

The conclusion I have reached is that we need one of the following:

1. A "sampling" option where only a fraction of the receivers would multicast a receiver
report at a given time, so that the bandwidth fraction alloted to RTCP could be increased.

2. A unicast option, where the RTCP receiver reports would be sent to one or more 
designated hosts, rather than being multicast to the group. 

Well, speaking of overhead, why does RTSP use 4 octets for the tag field? Given
that you only have a few tags, it would seem that you could use a single octet
Code field. And the Major/Minor version field that currently requires two octets could
be compressed to a single octet. 

However, I'd like to as the members of this list a couple of things:

Using RTCP you can get information on listenership, available user bandwidth, and 
transmission quality. This, along with the extensions mechanism,  is considered 
quite compelling, both by network managers as well as potential server owners.  

SNMP monitoring of receivers is a non-starter, due to privacy concerns.  

This isn't explicitly stated in the document, but I feel that the RTCP
requirement should be dropped in "compressed RTP".  

In my opinion, RTCP is the single most compelling aspect of RTP. Although I feel
there is a need to address the low-bandwidth issue, throwing out RTCP would be
a serious mistake.