[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Final edits to RTP spec and A/V profile
My comments below....
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]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
>
>
> 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.
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
>
> -- Steve
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt