Subject: RE: [AVT] RTCP question

From: "Mistler, Art" <[email-masked]>
Date: Tue, 4 Sep 2001 13:57:38 -0400

Brian had actually suggested that I refer to an earlier discussion close
to this exact topic.  However when I check the archive, it only goes
back to April 4th of this year.  There are some messages that discuss
dissolution of another list "rem-conf", I can't seem to find that.

So I'd be happy to read the historical discussion on the topic of RTCP
necessity in a unicast environment, however I need some assistance on
either a subject thread name, a pointer to a more extensive archive, or
some other solution.

This way I won't force a discussion about a topic that has already been
covered.

Regards,
- RT

-----Original Message-----
From: Brian Hagar [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 1:07 PM
To: Colin Perkins
Cc: Mistler, Art; [email-masked]
Subject: Re: [AVT] RTCP question

Colin,

My understand from previous discussions on this mailing list is that it
is
mandatory to implement but not mandatory to send except for multi-cast
environments.

Brian

Colin Perkins wrote:

> RTCP is necessary for lip-sync, and useful for other purposes (e.g.
you may
> be interested in the reception quality feedback). I would strongly
urge you
> to implement it.
>
> Colin
>
> --> "Mistler, Art" writes:
> >Hello All,
> >
> >I'm working on integrating RTP into a media server.  And the
engineering
> >team continues to flip-flop on opinions as to whether RTCP is really
a
> >mandatory requirement for the solution.  We will not be using IP
> >multicast in the product, but realize that it is still recommended
for
> >all environments. (Section 6 of RFC1889, just after the 4 function
> >descriptions for RTCP)
> >
> >People here have received private comments, from customer feedback
and
> >engineering peers, that RTCP is not such a stringent requirement, and
> >that it is highly dependent on the actual real time media that is
being
> >transferred.  I was wondering if anyone had any recommendations how I
> >might get closer to an answer.  For instance, what types of
application
> >areas most definitely need RTCP and what types of application areas
can
> >benefit from it, but live without it.
> >
> >Regards,
> >- RT
> >
> >RT Mistler
> >ThinkEngine Networks, Inc.
> >175 Maple Street
> >Marlboro, MA  01752
> >(508) 597-0464
> >mailto:[email-masked]
> >The Network Listens, Understands and Responds
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >http://www1.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 04 Sep 2001 14:11:42 -0400

The rem-conf archives are at ftp://ftp.es.net/pub/mail-archive/rem-conf
Colin

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 04 Sep 2001 14:36:01 -0400

> > >ThinkEngine Networks, Inc.

The thread is called

            RTCP optional ?

And it started on 4/25/2001 and petered out by the end of the month.

My summary / recollection is that the consensus was that RTCP should become a MUST,
however I do not see this reflected in the current draft.

If you can't find the archives I believe that I have the entire thread saved.

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.on-the-i.com

Test your network for multicast : http://www.multicasttech.com/mt/
 Check the status of multicast in real time :
 http://www.multicasttech.com/status/index.html

---

From: Stephen Casner <[email-masked]>
Date: Tue, 4 Sep 2001 18:17:27 -0700 (PDT)

> however I do not see this reflected in the current draft.

The statement "RTCP should become a MUST" is not specific enough,
since it could refer to a requirement that RTCP be implemented or a
requirement that RTCP be sent, and by receivers or senders.  In any
case, I believe we can't require that RTCP always be sent because
there are some environments in which it won't work, such as for
receivers in a unidirectional transmission system.  Furthermore, if
there are environments in which none of the functions of RTCP are
needed by the application or for the health of the network, then I
believe we can't force implementers to use it (no media sync, no need
for quality feedback, no need for aliveness monitor, SSRC collision
precluded, congestion avoided by resource allocation, ...)

And if we can't require that RTCP be sent (or received), then we can't
require that the capability to send or receive RTCP be implemented,
either.  Personally, I argue that an implementation _should_ always
include RTCP because somehow it seems that implementations frequently
get used in different ways and different environments than what the
implementors originally expected.

To give an idea why we can't say RTCP MUST always be sent, I'll relate
an exchange of email with Harald Alvestrand from 6 months ago.  He
expressed concern that RTCP was not feasible to use with multicast
because it turns a multicast group with few senders and many
recipients into an all-senders group that may exceed the scalability
of multicast routing.  If single-source multicast is used to reduce
routing state, then the receivers can't multicast on the same
channel.

One choice is for the receivers to just not send RTCP if quality
feedback is not required.  This is allowed by the following change to
the RTP spec, as listed in the Changes from RFC 1889 section:

        o In Section 6.2 it is specified that RTCP sender and receiver
          bandwidths to be set as separate parameters of the session
          rather than a strict percentage of the session bandwidth, and
          may be set to zero. The requirement that RTCP was mandatory
          for RTP sessions using IP multicast was relaxed.

In AVT WG we are also discussing extensions to RTCP for use with SSM
so that feedback can be provided effectively.  One mode is for
receivers to send RTCP as unicast back to the single source which then
reflects it on the SSM multicast channel.  Harald said this was the
kind of solution he was looking for, but asked if it would be
conformant with the RTP spec.  I replied that it is because RTP is
really a pretty flexible framework, not a very specific protocol.
This kind of activity by the source fits within the functionality of
an RTP "translator" which the spec indicates may take a variety of
forms.
							-- Steve