Subject: RTP spec questions

From: Stephen Casner <[email-masked]>
Date: Wed, 20 Oct 1999 13:14:45 -0700 (Pacific Daylight Time)

AVT working group:

I have a few questions regarding changes to the RTP spec.  I'm
interested in any comments you may have now, and we can discuss these
at the upcoming meeting as well.

1. At the Oslo IETF meeting, and as reported in the minutes of that
meeting, we agreed to change the representation of the loop/collision
detection algorithm to pseudo-C.  This was part of the question, when
a new source transport address is seen for a known SSRC id, whether
packets from the old address should be kept and from the new address
ignored, as is currently specified, or vice versa.  The motivation for
changing the spec is to accommodate mobile hosts that may change their
address.  Since following the new source requires hysteresis in case
there really are two sources colliding, I propose to not add any
additional complexity to the pseudo-code algorithm, but to add in the
text the following statement:

    For applications in which sources may change addresses, the RTP
    implementation SHOULD modify the collision detection algorithm to
    accept packets from the new source transport address.  To guard
    against flip-flopping between addresses if a genuine collision
    does occur, the algorithm should include some means to detect this
    case and avoid switching.

2. As discussed in August, if a source has not been sending data for a
while, so it is sending RR's with a fairly large interval according to
the receiver fraction of the RTCP bandwidth, and then it begins to
transmit, it may be quite a while before the RTCP interval expires and
the first SR is sent.  The change is to add a statement to 6.3.8 that
a transition of we_sent from false to true SHOULD trigger a "reverse
reconsideration" recalculation of the RTCP interval.

3. In scenarios with one or a small number of data senders and many
receivers, the sender's RTCP interval may be much shorter than that of
the receivers.  Therefore, 6.3.5 on timing out an SSRC needs to be
based on the RTCP interval using the receiver fraction rather than the
sender fraction, even for senders.

4. In Oslo we decided _not_ to change the calculation of avg_rtcp_size
to include only the RTCP packets being transmitted and exclude those
received from other sources, even though there is a potential for
unfair use of RTCP bandwidth, because it would complicate many parts
of the algorithm without a clear gain.

A related question has occurred to me just recently:  If an RTCP
compound packet includes information from more than one host, as in
the case where an RTP mixer aggregates SDES information from multiple
sources, should the size of that packet be divided by the number of
sources before being figured into the average?

The scenario which tiggered this question was the idea we discussed in
Oslo for a possible new one-to-many RTP profile in which RTCP packets
are sent via unicast from receivers to the sender which then reflects
them back out to all receivers using multicast.  Packets from multiple
receivers could be aggregated, which would perturb the existing
average size calculation.  For a new profile, it would be possible to
specify a modification to the calculation for that profile.

							-- Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Oct 1999 00:36:14 -0400

>     case and avoid switching.

The problem is that your RTP implementation above may not be mobile. It
may be just a normal host talking to a mobile. In this case, the normal
host does have to implement this modified collision detection algorithm.
So, how would a non-mobile host know which algorithm to implement?

> reconsideration" recalculation of the RTCP interval.

Yes.

> sender fraction, even for senders.

Yes.

> of the algorithm without a clear gain.

Agree again.

> sources before being figured into the average?

Good catch; I believe it does need to be divided in this way. Otherwise,
if the packet size is more than 5 times the average size, there will be
constant timeouts. Basically, the inverval between appearances of data
from a particular user in the mixer must be the same as if they were not
being mixed. So, if a mixer mixes 3 people, the interval between RTCP
packets containing data for user 1 should be the same as if user 1 were
not in the mixer.

Hmm; another way to divide this is to actually allocate N times the
bandwidth if N users are being mixed, but don't divide the packet size
by N. I think this is more or less equivalent to what you suggest.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Stephen Casner <[email-masked]>
Date: Thu, 21 Oct 1999 21:52:23 -0700 (Pacific Daylight Time)

> So, how would a non-mobile host know which algorithm to implement?

Right.  I was attempting to distinguish by using "application" and
"implementation" that all nodes, both mobile and non-mobile, which
participate in an application like IP telephony where addresses might
change on the fly are affected by this consideration.  Would
"scenarios" do better than "applications"?

> constant timeouts.

I'm not sure that's true.  Everyone should be averaging over the same
set of packets, so the intervals should be roughly consistent.  Well,
execept that the estimator gain is 1/16 so it could bounce around if
the big packet was only one out of many.  My concern was more that the
average would be wrong -- too large, which means intervals longer than
they should be, which is the safer direction.
							-- Steve

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Oct 1999 11:51:38 +0100

>they should be, which is the safer direction.

I'd be more tempted to follow Jonathan's other suggestion, and allow a
mixer which is mixing N sources to use N times the single source RTCP
bandwidth. This would also let you get away with the naive implementation
of sending an RTCP packet on the mixed side each time a packet is received
on the non-mixed side (ie: rewrite the SR/RR but forward SDES packets as
soon as they are received).

Colin