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

[Stephen Casner <casner@acm.org>]

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
> point-to-point unicast RTP session.

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt