Subject: [AVT] Final edits to RTP spec and A/V profile

From: Stephen Casner <[email-masked]>
Date: Tue, 7 Jan 2003 13:05:36 -0800 (PST)

I am making the final edits to the RTP specification
(draft-ietf-avt-rtp-new-11) and the RTP A/V profile
(draft-ietf-avt-profile-new-12) to incorporate the comments made by
the IESG during their review.  During the period that these documents
were under IESG review, there have been a few requests for
clarifications from WG members and other RTP implementers.  I have
prepared edits to try to provide more clarity.  These edits do not
make any change to the intended meaning of the documents, but they are
significant enough (and tricky enough to get exactly right) that I
want to review them with the WG first.  I will send several messages,
each with one edit so that they can be discussed individually.  This
is the first one.

This edit is a revision/expansion of the definition of an RTP session
to try to remove the ambibuity that Mike Taylor explained in his
message to the list last October (message appended below).  Others
before him have also found the original definition insufficient.

The new version is longer, but is it better?  Might it trigger other
potential misconceptions as it tries to remove the ones I knew about?

                                                        -- Steve

Old:
        RTP session: The association among a set of participants
             communicating with RTP.  For each participant, the session
             is defined by a particular pair of destination transport
             addresses (one network address plus a port pair for RTP and
             RTCP).  The destination transport address pair may be
             common for all participants, as in the case of IP
             multicast, or may be different for each, as in the case of
             individual unicast network addresses and port pairs.  In a
             multimedia session, each medium is carried in a separate
             RTP session with its own RTCP packets.  The multiple RTP
             sessions are distinguished by different port number pairs
             and/or different multicast addresses.
New:
        RTP session: An association among a set of participants
             communicating with RTP.  A participant may be involved in
             multiple RTP sessions at the same time.  A single RTP
             session is defined by a particular pair of destination
             transport addresses (one network address plus a port pair
             for RTP and RTCP).  The destination transport address pair
             may be common for all participants in the session, as in
             the case of IP multicast, or may be different for each, as
             in the case of individual unicast network addresses and
             port pairs.  In a multimedia session, each medium is
             carried in a separate RTP session with its own RTCP
             packets.  The multiple RTP sessions are distinguished by
             different port number pairs and/or different multicast
             addresses.  Each RTP session defines a distinct space of
             SSRC identifiers (defined next) because the session is
             received by a participant on a distinct pair of destination
             transport addresses (RTP and RTCP).  One RTP session
             includes the set of participants that can receive an SSRC
             identifier transmitted by one of the participants either in
             RTP (SSRC or CSRC) or RTCP.  That may be only two
             participants in a point-to-point unicast RTP session, or a
             larger number connected by IP multicast, multi-unicast to
             shared destination transport addresses, or through an RTP
             mixer or translator.  (Definitions of CSRC, mixer and
             translator follow.)

> Date: Fri, 11 Oct 2002 16:25:14 -0700
> From: Mike Taylor <[email-masked]>
> To: [email-masked]
> Subject: [AVT] What is an RTP Session?
>
> Hi,
>
> I'm an RTP newbie and I'm trying to understand just what constitutes
> an RTP session when the participants are using unicast rather
> than multicast.  I find the description in RFC 1889 quite ambiguous.
>
>    "RTP session: The association among a set of participants
>         communicating with RTP. For each participant, the session is
>         defined by a particular pair of destination transport addresses
>         (one network address plus a port pair for RTP and RTCP). The
>         destination transport address pair may be common for all
>         participants, as in the case of IP multicast, or may be
>         different for each, as in the case of individual unicast network
>         addresses plus a common port pair.  In a multimedia session,
>         each medium is carried in a separate RTP session with its own
>         RTCP packets. The multiple RTP sessions are distinguished by
>         different port number pairs and/or different multicast
>         addresses."
>
> Perhaps this paragraph would be clearer if the definition of
> "participant" was made clear.  The use of participant in the 1st
> sentence might be interpreted to mean a participant in a conference
> consisting of multiple RTP sessions.  But the very next sentence
> refers to "the session" which suggests that indeed there are
> multiple participants in a single RTP session.  This makes sense for
> multicast, but my problem is I find it confusing in a multipoint
> unicast scenario (I'm assuming its peer-to-peer which might be part
> of my problem, but read on).
>
> Dissecting the paragraph we have:
>
>         "For each participant, the session is
>         defined by a particular pair of destination transport addresses
>         (one network address plus a port pair for RTP and RTCP). "
>
> This would seem to suggest that the triplet <dest_network_addr,
> rtp_port, rtcp_port> defines a session from the perspective of a
> given participant.  But then it seems to me that with unicast RTP
> can never be more than two participants in a single session
> (assuming each participant is using a different computer and hence
> has a different network address).  Each participant sees the session
> as defined by its peer's IP address and the RTP and RTCP ports it
> uses to send RTP and/or RTCP to the peer.
>
> But the same paragraph goes on to say
>
>         "The destination transport address pair may be common for all
>         participants, as in the case of IP multicast, or may be
>         different for each, as in the case of individual unicast network
>         addresses plus a common port pair. "
>
> This latter sentence seems to contradict the former and suggests
> that for each participant in a multipoint unicast session the
> session is defined by an array of triplets of the form:
>
>         <net_addr_1, port>
>         <net_addr_2, port>
>         <net_addr_3, port>
>         .....
>
> I suppose that the author of the RFC would have assumed that for a
> multi-party conference using unicast there would be an RTP mixer
> terminating all sources, combining them, and sending them to all
> participants.  Thus, for each participant there would only be a
> single session, and it would be defined by the net address and port
> pair of the mixer node. Still, I'd like to know if anyone is aware
> of whether any consensus has been arrived at on this issue of what
> defines the session in the multi-point unicast case, with no mixer.
>
> Furthermore, does anyone know of any commercial or public domain
> voice conferencing apps that can create multipoint unicast
> peer-to-peer conferences?  I've been experimenting with MS
> NetMeeting and have found that it only supports audio between 2
> parties in a multi-party conference.  Perhaps this issue hasn't been
> viewed as important because nobody is supporting a peer-to-peer
> multi-party conference?
>
> Thanks in advance,
>
> Mike Taylor

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Jan 2003 23:54:56 -0500

I also think clarification is much needed on this point. I personally 
remain confused :(. Comments inline.

Stephen Casner wrote:

>              for RTP and RTCP). 

This definition differs fundamentally from the old. It says that a 
session is unique to a particular destination address. Previously, each 
participant in a session could potentially have the same destination 
address (multicast) or different ones. Now, different ones would imply 
different sessions. I will note that this new definition is more 
consistent with my understanding, but it isn't entirely consistent with 
text that follows:

  The destination transport address pair
>              port pairs. 

This directly contradicts the previous sentence.

  In a multimedia session, each medium is
>              RTP (SSRC or CSRC) or RTCP.

This is consistent with the one destination IP/port = one session view.

   That may be only two
>              participants in a point-to-point unicast RTP session,

But this, to me, contradicts the above statement. In a point-to-point 
case, only one user receives the media that is transmitted. By the above 
definition, this RTP session therefore includes this one participant.

  or a
>              mixer or translator.  (Definitions of CSRC, mixer and

Is multi-unicast ever defined elsewhere? I don't think so. Anyway, I do 
not understand what "multi-unicast to shared destination transport 
addresses" means. My definition of multi-unicast was a "full-mesh" of 
connectivity. If there are N participants, each one would be listening 
for RTP traffic on N separate addresses, one for each sender. That 
corresponds to a total of N(N-1) RTP sessions based on the 
session=destination IP/port definition. Each user using a common 
destination address to receive all the media would constitute N RTP 
sessions based on this definition. However, that configuration is not 
what I would expect. You would lose the ability to correlate a media 
stream (that is, a sequence of RTP packets with a single SSRC) with the 
SIP dialog which set it up, a key capability I believe. This would also 
constitute "SSRC multiplexing" (see another message sent by Steve on 
this subject) which anyway seemed to still be discouraged.

So, I am still confused, I'm afraid.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Koji Hino <[email-masked]>
Date: Wed, 08 Jan 2003 16:28:48 -0800 (PST)

From: Stephen Casner <[email-masked]>
 Date: Tue, 7 Jan 2003 13:05:36 -0800 (PST)
:> New:
<snip>
:>              The multiple RTP sessions are distinguished by
:>              different port number pairs and/or different multicast
:>              addresses.

When I read this first time, I feel some ambiguousness about
'and/or'. Just after that, I think it is obvious that in multicast
case, two sessions with different multicast address and same port
number should be distinguished, because of existence of 'or'. Is this
correct?

If so, I think it is better to separate the sentence to point-to-point
case and multicast case, for smooth understanding. Ex.

For point-to-point unicast case, the multiple RTP sessions are
distinguished by different port number pairs. For multicast case, the
multiple RTP sessions are distinguished by different port number pairs
or different multicast addresses, or both of them.

Just my thought...

Koji

Best regards,
====================================================================
Koji HINO(HINO is my family name)
NEC Laboratories America, Inc.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Wed, 8 Jan 2003 17:03:42 -0800 (PST)

Jonathan (and everyone),

As I said in my intro, these definitions are tricky to get exactly
right.  Your comments confirm that.  One problem I recognize now is
that some people read this text thinking about "participant" from the
receiver perspective, and others from the sender perspective: how many
ports do I receive on in one session, vs. how many ports do I send to
in one session.  We realized a long time ago that these two different
viewpoints was a fundamental problem in SDP descriptions of unicast
sessions.

On multiple occasions, the question has been asked: how many RTP
sessions are there in a conference of more than two participants
implemented with with unicast "connections".  But we've never really
discussed this question in detail in the WG (that I recall, anyway).
Maybe that is because we (at least some of us) were pushing hard to
make IP multicast work.  Anyway, here's how I view it:

  - The key determining factor is that SSRC identifiers must be unique
    within an RTP session.

  - The parameters that define an RTP session must be such that a
    receiver can tell to which session an incoming packet belongs, so
    it knows in which space to look up the SSRC identifier.  The
    source IP address and port are _not_ candidate parameters because
    they may be modified by intermediate devices.  (We included the
    SSRC in the RTP header to keep RTP independent of lower-level
    addressing even before NAT occurred.)

So, one could implement a full-mesh unicast conference where a
receiver uses the same local (destination) port number to receive
packets from all the other participants.  This is what I meant by
"multi-unicast to shared destination transport addresses".  In
response to Mike Taylor's original message, John Lazzaro described how
sfront does this for MIDI, but also cautioned about problems with this
design.  In this design, the receiver depends upon the SSRC to
distinguish the other participants, just as it would in a conference
implemented with IP multicast.  Therefore, there is only one SSRC
space and only one RTP session.

Alternatively, one could implement the conference such that each
receiver uses N-1 different ports to receive from the other
participants.  Since the destination port number distinguishes each
sender, this implementation could be defined as N(N-1)/2 RTP sessions
each with a distinct SSRC spaces.  Each pair would be treated as a
point-to-point call, and RTCP would carry a reception report for
traffic from the other end.  HOWEVER, if we want to use reception
reports to diagnose distribution problems in the same way that we
imagined for IP multicast, then each participant would send reception
reports about all N-1 other participants to each of them, and the RTCP
interval would be calculated based on N participants.  Clearly then
the SSRC space is shared, so it has to be one RTP session.  It seems
like this mode should be allowed, but it conflicts with both the old
and new definitions of an RTP session being defined by a particular
pair of destination transport addresses.

Also, I imagine that only a subset of these modes may have been
considered in SIP.

Should the definition of "RTP session" be further modified so that it
covers this multi-unicast-with-separate-ports mode?  Or is that mode
"wrong" in some way?  It doesn't seem wrong to me.  On the other hand,
at the RTP level, we can't tell the application anything about how it
should know that the N-1 peers should be associated into one session.

I have some specific responses to your points inline.

> different sessions.

That was not my intent.  I removed the initial phrase "For each
participant" because that seemed to be contributing to the ambiguity
for Mike Taylor, but that may have been a mistake.  Of course, now in
my intro above, I am questioning this sentence even futher.

> I will note that this new definition is more

No, I meant for the two sentences to work together.  This one
generalizes the first in that the particular pair of addresses may be
different for each participant.  But you are right that this needs to
be written better.

Also, this sentence can mean two different things:

  - Sender perspective:  To each of the participants in a
    multi-unicast session, I send to a different port number.

  - Receiver perspective: From each of the other participants in a
    multi-unicast session, I receive on a different port number.

Maybe this sentence only works when N = 2.

> This is consistent with the one destination IP/port = one session view.

The last of the sentences in this group was my attempt to capture the
notion that the key determining factor is that SSRC identifiers must
be unique within an RTP session.  It might not be clear enough.

> definition, this RTP session therefore includes this one participant.

No, the SSRC is also sent back in an RR so the sender receives its own
SSRC, too.  My intention was the union of the N sets considering each
of the N participants as the sender of an SSRC.  I thought the union
was implied in that sentence by the inclusion of SSRCs in RTCP.

> Is multi-unicast ever defined elsewhere? I don't think so.

No, that term does not appear anywhere else in the document.

> Anyway, I do
> sessions based on this definition.

I mentioned both scenarios in my intro.  I think it is N(N-1)/2
sessions rather than N(N-1) for the first case and 1 rather than N for
the second because the SSRC identifiers get returned in RTCP.

Maybe we need to make sure we have a common understanding for the
simplest case first: a point-to-point call between two participants is
only 1 RTP session because we share RTCP sender and receiver
information in the same packet (obviously therefore sent to the same
port).  That ties the two directions together.  Does the definition
conflict with that?

> However, that configuration is not
> SIP dialog which set it up, a key capability I believe.

This is an important question.  SIP is not the only means to establish
an RTP session, and we want RTP to be general enough to implement the
media communication requirements of a variety of control protocols,
but that means we have to define terms and concepts within RTP without
depending upon concepts of the control protocols to help us.

> This would also

I don't see any of these scenarios as "SSRC multiplexing" because they
are only implementations of the IP multicast model when the only tool
you have is unicast.  The intention is that all of the audio streams
received by one participant should be mixed, for example.  The kind of
"SSRC multiplexing" that I have objected to is when totally
independent streams are multiplexed in one session.  Some might see
that distinction as arbitrary, but the idea is that if you force those
streams together this way, you won't be able to separate them
somewhere when you figure out later on that you want to do so (e.g.,
for the reasons in the last bullet of Section 5.2).

> So, I am still confused, I'm afraid.

Probably even more now.  Perhaps it was unwise for me to open this
question, but sweeping ambiguity under the rug isn't right, either.

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Wed, 8 Jan 2003 17:25:14 -0800 (PST)

That's a good suggestion, thanks.

                             -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Thu, 9 Jan 2003 20:19:20 -0800 (PST)

Here's another crack at the RTP session definition.  The existing
definition in RFC 1889 contains the following sentences:

   For each participant, the session is defined by a particular pair
   of destination transport addresses (one network address plus a port
   pair for RTP and RTCP).

   The multiple RTP sessions are distinguished by different port
   number pairs and/or different multicast addresses.

Considering my discussion in email yesterday of full-mesh
multi-unicast conferences, perhaps the first sentence was too
restrictive.  Perhaps the salient point from these sentences is the
following:

   Different RTP sessions will not have the same destination address
   and port pair, but a single RTP session may be composed of multiple
   destination addresses and/or port pairs.

My intention in all of the edits I proposed was not to change the
meaning of any of the text (or our collective understanding of what
the text failed to say), but only to clarify.  It is important not to
do so since the IESG has approved the drafts in their current state.
Well, if something is broken, we should fix it, but then the IESG
needs to agree with the fix, and a big change would require cycling at
Proposed Standard rather than advancing to Draft Standard.

So, would it be an incompatible change to say an RTP session may be
composed of multiple addresses/ports?  I think if you consider RTP
translators and mixers, then you realize that the original definition
was already too restrictive.

For example, consider an N-party audio conference implemented as an
RTP mixer with one unicast connection to each participant.  The mixer
is also a participant in the teleconference because it has an SSRC of
its own that it uses to transmit the mixed audio to the other
participants.  This conference is all one session: the SSRC
identifiers are distributed among all the participants in the CSRC
list and therefore must be in one space.  Yet, for the mixer, the RTP
session is composed of N different ports (the addresses may all be the
same or may not, depending on whether the mixer has multiple
interfaces).

So, how about the following revised definition:

        RTP session: An association among a set of participants
             communicating with RTP.  A participant may be involved in
             multiple RTP sessions at the same time.  In a multimedia
             session, each medium is carried in a separate RTP session
             with its own RTCP packets.  The multiple RTP sessions are
             distinguished by reception of each using a distinct pair of
             destination transport addresses, where a pair of transport
             addresses comprises one network address plus a pair of
             ports for RTP and RTCP.  The destination transport address
             pair may be common for all participants in a session, as in
             the case of IP multicast, or may be different for each, as
             in the case of individual unicast network addresses and
             port pairs.  In the unicast case, a participant may receive
             from all other participants using the same pair of ports,
             or may use a distinct pair of ports for each.

             The distinguishing feature of an RTP session is that each
             defines a distinct space of SSRC identifiers (defined
             next).  The set of participants included in one RTP session
             consists of those that can receive an SSRC identifier
             transmitted by any one of the participants either in RTP
             (either as the SSRC or a CSRC, also defined below) or in
             RTCP.  For example, consider a three-party conference
             implemented using unicast UDP with each participant
             receiving from the other two on separate port pairs.  If
             each participant sends RTCP feedback about data received
             from one other participant only back to that participant,
             then the conference is composed of three separate point-
             to-point RTP sessions.  If each participant provides RTCP
             feedback about its reception of one other participant to
             both of the other particpants, then the conference is
             composed of one multi-party RTP session.  The latter case
             simulates the behavior that would occur IP multicast
             communication among the three participants.

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Fri, 10 Jan 2003 15:47:25 -0800 (PST)

Attempt number three on the definition of an RTP session.  David Leon
made some suggestions, and I fixed some typo problems.  Is this clear?
And even more important, do you agree with what it specifies?

        RTP session: An association among a set of participants
             communicating with RTP.  A participant may be involved in
             multiple RTP sessions at the same time.  In a multimedia
             session, each medium is carried in a separate RTP session
             with its own RTCP packets.  A participant distinguishes
             multiple RTP sessions by reception of different sessions
             using different pairs of destination transport addresses,
             where a pair of transport addresses comprises one network
             address plus a pair of ports for RTP and RTCP.  All
             participants in an RTP session may share a common
             destination transport address pair, as in the case of IP
             multicast, or the pairs may be different for each
             participant, as in the case of individual unicast network
             addresses and port pairs.  In the unicast case, a
             participant may receive from all other participants using
             the same pair of ports, or may use a distinct pair of ports
             for each.

             The distinguishing feature of an RTP session is that each
             defines a distinct space of SSRC identifiers (defined
             next).  The set of participants included in one RTP session
             consists of those that can receive an SSRC identifier
             transmitted by any one of the participants either in RTP as
             the SSRC or a CSRC (also defined below) or in RTCP.  For
             example, consider a three-party conference implemented
             using unicast UDP with each participant receiving from the
             other two on separate port pairs.  If each participant
             sends RTCP feedback about data received from one other
             participant only back to that participant, then the
             conference is composed of three separate point-to-point RTP
             sessions.  If each participant provides RTCP feedback about
             its reception of one other participant to both of the other
             participants, then the conference is composed of one
             multi-party RTP session.  The latter case simulates the
             behavior that would occur with IP multicast communication
             among the three participants.

                                                        -- Steve

---

From: Chuck Harrison <[email-masked]>
Date: Fri, 10 Jan 2003 16:41:18 -0800

Hi, Steve,

Breaking out the following short definition in section 3 might
help first-time readers:

    Multimedia session: A set of concurrent RTP sessions among a
       common group of participants. For example, a 
       videoconference connection (which is a multimedia session)
       may contain an audio RTP session and a video RTP session.

I remember once finding RFC1889 confusing because there are several
ways "session" is used in the text but only the RTP session had
an explicit definition.

Cheers,
  Chuck

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 15 Jan 2003 20:20:24 +0200

>And even more important, do you agree with what it specifies?

	What is the difference between an RTP cloud (a la section 7) and
	an RTP session?

>             address plus a pair of ports for RTP and RTCP.  

	Don't we have multiple mediums in a single RTP session, for
	example, with some MPEG4 packetization? So, s/medium/RTP media
	type/, or is it then a circular definition?

>All

	I'd drop this text away, as a RTP session can consist of two
	multicast group connected via a translator or a mixer.

	I also think translators and mixers that forward CSRCs and SDESs
	should be mentioned in the definition.

						Pekka

---

From: "Mike Taylor" <[email-masked]>
Date: Fri, 24 Jan 2003 09:05:31 -0800

My comments below....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Stephen
> Casner
> Sent: Friday, January 10, 2003 3:47 PM
> To: AVT WG
> Subject: Re: [AVT] Final edits to RTP spec and A/V profile
>
>

The above statements about multi-point unicast hit on a nerve for me,
so pardon me if I rant just a bit.  But having just completed an
implementation
of RTP/RTCP which I attempted to make very general purpose, and thus tried
to
support point-to-point unicast, multi-point unicast, as well as multicast,
I have to say that the major problem with this RFC is that it mentions the
concepts
of unicast RTP sessions, and in particular multi-point unicast sessions, but
really
does little to offer requirements or even guidance about how RTCP should
operate in
these circumstances.  I believe that the draft, and presumably next
standard,
should not attempt to address multi-point unicast especially, but rather
should
acknowledge that the RFC only really covers multicast RTP sessions, and that
a
separate RFC will be needed to address multi-point unicast. Why?

For example, so much of the complexity of RTCP revolves around keeping
track of the  numbers of session members so as to compute the RTCP reporting
interval that will maintain the desired bandwidth constraints on RTCP
traffic.

But is it not the case that the algorithm offered in the RFC for this
purpose
breaks down in the multi-point unicast case?  Isn't the assumption that
a given session participant never sends more than one stream of RTCP
packets -
either receiver reports only, or sender reports only - the latter possibly
containing
RR blocks?  So in a multicast session each participant generates at most one
RTCP
packet per reporting interval.

But as correctly suggested above, in a true multi-point unicast sessions all
receivers would have to send RTCP reports about ever stream being received
to every
other receiver.  Otherwise, even in the simplest case of a multi-point
unicast session
where only one member transmits and all others receive, there will be a
gross
underestimation of the number of session participants, and thus for a large
unicast
conference of this type (which one would think in the current multicast-less
commercial
internet would be the most common scenario) there would be far more
bandwidth consumed
by RTCP than intended.

But if all receivers sent RTCP RRs to all other receivers (I don't know how
they find out
about one another to achieve this... more later) then unlike the multicast
case this implies
there will be N*(N-1) RTCP packets sent per reporting interval!  Certainly
the algorithm
in the RFC for computing the RTCP reporting interval doesn't take this into
account.

So it seems to me that in reality the original, and current draft RTP RFCs,
are
both really about multicast RTP, and that the new draft should admit this
fact
and there should be additional RFCs to specify the correct operation of RTP
for unicast
sessions, and especially for multi-point unicast sessions.  Perhaps
point-to-point unicast
is simple enough that its operation can be covered in an appendix to the
current draft.
But even there, I think the RFC should explicitly address the fact that the
entire
algorithm for computing RTCP bandwidth is overkill and unnecessary for a
simple
point-to-point unicast RTP session.

I suggest a separate RFC to deal with multi-point unicast only because I'm
sure nobody would
want to hold up the advancement of the current draft long enough to deal
properly with
this scenario.

It seems rather difficult for me to believe that in a commercial broadcast
style
deployment of this technology that anyone would want all receivers sending
receiver
reports to one another.  So I'm thinking that a more realistic scenario for
multi-point
unicast would involve some centralized control.  Obviously, in a broadcast
TV scenario
where a single transmitter sends unicast RTP to a large number of receivers,
then the
receivers should learn about how often to send receiver reports back to the
transmitter
from the transmitter.  Why would most of them even care about the other
receivers, and
security considerations would seem to dictate that they shouldn't be aware
of them
(I'm sure I want to send my RRs to my nextdoor neighbor's hacker kiddie!).

The entire calculation for the reporting interval could be carried out at
the transmitter,
with some addition RTCP message type being defined that the transmitter
would use to tell
the receivers the reporting interval.  Based on the transmitters knowledge
of the estimated
RTT to each receiver, it could give different receivers different reporting
intervals.

Besides, as stated above, even if one took the approach of sending RRs to
all other
receivers, how would one know how to address these reports without
centralized
session control anyway?

Anyway, nuff said.  I feel in summary that the RFC should acknowledge that
much of the
RTCP content in the current RFC and draft is intended for multicast
sessions, and that
further work is needed to define proper operation in a multi-point unicast
scenario.

- Mike

---

From: Stephen Casner <[email-masked]>
Date: Fri, 31 Jan 2003 00:41:59 -0800 (PST)

On Fri, 24 Jan 2003, Mike Taylor wrote:

> The above statements about multi-point unicast hit on a nerve for
> me, so pardon me if I rant just a bit.

Considering that I added the text about multi-point unicast as a
result of your query in October, I guess that means I was not very
successful in addressing your questions.

> But having just completed an implementation of RTP/RTCP which I
> attempted to make very general purpose, and thus tried to support
> point-to-point unicast, multi-point unicast, as well as multicast, I
> have to say that the major problem with this RFC is that it mentions
> the concepts of unicast RTP sessions, and in particular multi-point
> unicast sessions, but really does little to offer requirements or
> even guidance about how RTCP should operate in these circumstances.

As the introduction of the RTP spec states, we view RTP as a framework
that may be used in different ways for different applications.  That
is why in my example I described multiple ways that three participants
might use RTCP.  The space of options may be narrowed by an RTP
profile, but more likely it will be an application choice that may
also be affected by the capabilities of the control protocol.

> I believe that the draft, and presumably next standard, should not
> attempt to address multi-point unicast especially, but rather should
> acknowledge that the RFC only really covers multicast RTP sessions,
> and that a separate RFC will be needed to address multi-point
> unicast. Why?
>
> For example, so much of the complexity of RTCP revolves around
> keeping track of the numbers of session members so as to compute the
> RTCP reporting interval that will maintain the desired bandwidth
> constraints on RTCP traffic.

That's true, but we felt that the interval calculation is not really
that complex, and therefore it is reasonable to specify its use for
all modes so that an implementation would not be written with fixed a
RTCP interval for unicast only and then be redeployed for multicast
without adding the necessary interval calculation.  Granted, adding
timer reconsideration in the new draft does make it more complex than
the interval calculation is in RFC 1889.

> But is it not the case that the algorithm offered in the RFC for
> this purpose breaks down in the multi-point unicast case?

No, I don't think so (more below).

> Isn't the assumption that a given session participant never sends
> more than one stream of RTCP packets - either receiver reports only,
> or sender reports only - the latter possibly containing RR blocks?
> So in a multicast session each participant generates at most one
> RTCP packet per reporting interval.

Yes and yes.

> But as correctly suggested above, in a true multi-point unicast
> sessions all receivers would have to send RTCP reports about ever
> stream being received to every other receiver.  Otherwise, even in
> the simplest case of a multi-point unicast session where only one
> member transmits and all others receive, there will be a gross
> underestimation of the number of session participants, and thus for
> a large unicast conference of this type (which one would think in
> the current multicast-less commercial internet would be the most
> common scenario) there would be far more bandwidth consumed by RTCP
> than intended.

Depends how you look at it.  The scenario you describe is really just
a collection of point-to-point unicast sessions that all happen to be
carrying the same data at the same time.  There are N copies of the
data.  On each point-to-point session, the combined RTCP traffic from
the sender and receiver is constrained to 5% of that data bandwidth.
The travesty is having to use unicast rather than multicast for the
data, but this is a different story.

> But if all receivers sent RTCP RRs to all other receivers (I don't
> know how they find out about one another to achieve this... more
> later) then unlike the multicast case this implies there will be
> N*(N-1) RTCP packets sent per reporting interval!  Certainly the
> algorithm in the RFC for computing the RTCP reporting interval
> doesn't take this into account.

Each receiver will be sending N-1 RTCP packets, but the RTCP interval
will be roughly N times as long as it would have been in the
point-to-point case, so the total bandwidth across the interface
to/from the receiver is still what it should be.  Remember, the data
is N times as much as it would be in the multicast case, too.
Granted, if the method used to implement multi-unicast is to send all
N-1 packets back-to-back, that is still a problem.  But if they are
spread out over the interval, it works fine.

Here again, it depends upon the scenario.  For the situation with one
data sender and N receivers, it may not make sense to implement a
system this way.  On the other hand, for a 3 or 4 party
teleconference, it seems perfectly fine, and meets the objectives.

> So it seems to me that in reality the original, and current draft
> RTP RFCs, are both really about multicast RTP, and that the new
> draft should admit this fact and there should be additional RFCs to
> specify the correct operation of RTP for unicast sessions, and
> especially for multi-point unicast sessions.  Perhaps point-to-point
> unicast is simple enough that its operation can be covered in an
> appendix to the current draft.

I don't agree.  I think point-to-point is covered.  Multi-unicast is a
variation that we didn't explicitly mention until I added these
details in the RTP session definition, but it was always part of the
intended coverage of the protocol.

>  But even there, I think the RFC
> should explicitly address the fact that the entire algorithm for
> computing RTCP bandwidth is overkill and unnecessary for a simple

It may not be necessary, but I claim it is still a good idea and not
too hard.

> I suggest a separate RFC to deal with multi-point unicast only
> because I'm sure nobody would want to hold up the advancement of the
> current draft long enough to deal properly with this scenario.

I would expect other documents that describe _applications_ that use
multi-unicast, with coverage not only for the way in which RTP is to
be used, but also how the control signaling is to be done.

> It seems rather difficult for me to believe that in a commercial
> broadcast style deployment of this technology that anyone would want
> all receivers sending receiver reports to one another.  So I'm
> thinking that a more realistic scenario for multi-point unicast
> would involve some centralized control.  Obviously, in a broadcast
> TV scenario where a single transmitter sends unicast RTP to a large
> number of receivers, then the receivers should learn about how often
> to send receiver reports back to the transmitter from the
> transmitter.  Why would most of them even care about the other
> receivers, and security considerations would seem to dictate that
> they shouldn't be aware of them (I'm sure I want to send my RRs to
> my nextdoor neighbor's hacker kiddie!).

That may well be.  The idea for multicast with a scenario of
cooperative receivers is that being able to know that your reception
is worse than most peoples lets you know that there is a distribution
problem near you.  The same applies to some extent with
multi-unicast.  The rate control still applies to keep the number of
packets hitting the sender to be constant independent of session
size.

Also, there are DoS risks in central control that are avoided by the
distributed algorithm.  A lot of thought went into this.  See
draft-ietf-avt-rtcpssm-02.txt for some discussion of the security
issues in a related context.

> Besides, as stated above, even if one took the approach of sending
> RRs to all other receivers, how would one know how to address these
> reports without centralized session control anyway?

It is more likely to make sense in an application such as
teleconferencing which has explicit session control (which may be
implemented in a centralized or distributed manner).

                                                        -- Steve