Subject: RE: Progressing IDMR items

From: Arlie Davis <[email-masked]>
Date: Thu, 27 Feb 1997 16:25:01 -0500

Simply tossing RTCP packets toward the source is not a good idea at all.
 The source may be a machine with minimal intelligence, whose sole
responsibility is to read digital video and multicast it, for example,
or a stream server who could care less about membership.

Also, there would be a huge flood of RTCP packets toward the source.

So, there are two issues that I have with this: The source may not be
interested, and the flood of packets may be too great.  There are two
relatively easy ways to deal with this.

Let "session watcher" mean a machine which is interested in the RTCP
reports for a given multicast source or session, and "session source"
mean the machine which is actually sourcing the data, such as video or
audio.

The session source could periodically multicast a list of preferred
session watchers.  (How this information is conveyed is irrelevant -- it
could be in-band RTP data with a specific, reserved payload type, or any
number of ways.  The only important thing is that the data is multicast
to the exact same set of machines who are receiving the data multicast.)
 Each RTCP-aware client would receive the list of session watchers and
randomly decide on which one to use.  (If the list of session watchers
changes (watchers arrive, go away), the clients just re-decide.)  Then,
the client unicasts it's RTCP data to the session watcher.

This would allow for very simple and very complex implementations.  The
simplest implementations would announce a fixed list that just points
toward the session source.  The more complex ones would manage a
distributed database of all of the session listeners, their
quality-of-service statistics, etc.

Also, in the same place that specifies the list of session watchers, the
session source could simply indicate that clients are to send their RTCP
the "old fashioned way" -- multicast it to the same group as the session
data.  This would be a good choice for small- and medium-sized group
conferences.  The above model makes sense mostly for traditional
broadcast-style multicasts (few sources, many many listeners).

As we all know, the higher the group membership, the lower the rate at
which the members announce themselves.  As we approach Large numbers of
listeners, the rate essentially approaches zero, which makes RTCP pretty
much useless.  In a large session, usually there are only a few people
truly interested in who is listening.  Why not have the session
watcher(s) collect this information, index it, and (for example) make it
available via a web query.

-- arlie

>-----Original Message-----
>From:	[email-masked] [SMTP:[email-masked]]
>Sent:	Thursday, February 27, 1997 2:10 PM
>To:	[email-masked]
>Cc:	[email-masked]
>Subject:	RE: Progressing IDMR items
>
>I think it might make sense to, by default, automatically drop 
>individual RTCP transmissions back to the source at a certain point.
>[And, certainly, there should be an option to do so.  See below].  
>
>OTOH, RTCP has proven useful [to me] in cases where there are on 
>the order of 1000 listeners.  But, at a certain point, individual 
>RTCP listener reports would seem to no longer make sense.  I'm not 
>suggesting that no feedback to the source be given.  It would often 
>be extremely useful to know how many people are watching.  But, long 
>before one got to TV/radio-sized audiences- 10^^6 listeners- you 
>would only want to know about how many people are watching, not who.
>[Unless "you" are the secret police, or something [e.g. Advertisers].  
>See Privacy below.]  
>
>Given the example above, how many listeners does it take before 
>the RTCP transmission interval drops to below the timeout threshold?  
>Maybe that is ~about a logical place to switch.  Likewise, if the 
>average time someone tunes in to an Internet Radio program is short 
>relative to the average retransmission time, the statistics would 
>no longer be valid anyway.  Maybe there is a better way to estimate 
>the number of listeners when large-scale broadcasts are involved.  
>
>|> >> Also, truly, RTCP data isn't always that interesting.  Do I really care
>|> >> that much who is listening to the same radio broadcast?  If it's a
>|> >> conference, yes.  If it's a broadcast, usually no.  
>
>As above, for small broadcasts, yes, it is useful.  I don't think
>one should take the TV analogy too far - for purely TV-like
>functions, with on the order of 10-200 possible "channels",
>you already have: FM radio, AM radio, broadcast TV, cable TV,
>DirecTV [and other satellite TV companies], and so on.  Does
>anyone think that "The Mbone" is going to be able to deliver
>MPEG1/2/HDTV quality video into the home worldwide in direct 
>competition to DirecTV and/etc.????  For little more than the
>cost of connecting to an ISP with a 28.8 modem, today you can 
>already get MPEG1/2 quality [ie, better than VCR, better than
>most cable] satellite TV.  Even when the entire Internet is 
>higher-bandwidth, multimedia, multicast enabled, I still don't 
>see the Internet in direct competition with existing systems.
>
>I see the "broadcast market" for mbone-like capability to be 
>analogous to the Shuttle broadcasts- smaller, "niche" markets 
>and communities too small and geographically diverse to get 
>air time on a cable or satellite system with a few hundred 
>channels.  In other words, the same as the internet today, 
>but multicast/multimedia enabled.  The appeal of the internet 
>has always been individual and "niche" communication, not 
>"mass" communication, for which efficient channels have already 
>long existed.  Sure, we need to make sure everything scales up
>to a large number of internet users, maybe even 6 billion, but, 
>I doubt if they want to be internet users so they can "watch TV".
>People can already do that, *more cheaply*, just by watching TV.  
>
>In fact, this diversity, from a routing point of view, 
>represents one of the challenges: millions of daytime 
>professional internet users now want their own personal 
>class C home networks, and they want routes to similar 
>people.  Now, add multicast.
>
>Anyway, getting back to RTCP and "niche" broadcasting, assuming 
>a larger number of smaller, niche sources:  If we are talking 
>about 1000-10000 listeners to one of 10,000 different multicast 
>broadcast sources, then, yes, RTCP would be very useful, including 
>the information on how well "most people" are receiving the broadcast.
>
>                                                      Do we really want to
>|> >> burden precious router resources with (S,G) state that is of dubious
>|> >> value?
>
>As Steve Casner above, and Dino Farinacci below, point out, 
>this concern is (now) invalid.  A shared tree will handle the
>RTCP listener report flow, and the traffic will scale back
>to a proportionately small amount.
>
>I *am* still concerned about the total amount of (memory) 
>state routers have to carry, but, not for *this* case.  
>If 5 million of people are watching the same broadcast, 
>so what if there are a few router bytes allocated for multicast?  
>We just need to make sure that everything scales up for
>this exceptional case, but, frankly, I doubt seriously
>whether this will be a constant widespread problem any
>time soon.  
>
>[Of much larger concern is the amount of router memory consumed 
>by 10^^5 DIS-like ~100-person multiuser games along the lines 
>of what Intel described at their interactive multimedia/etc. 
>presentation last summer.  If you want to worry about something,
>worry about that.  I really don't think RTCP is much of a problem.]
>
>In short, RTCP could be enhanced to scale to millions 
>of people who are listening over asymmetric- bandwidth 
>media [e.g. cable modems], and also for Privacy.  
>
>|> At the AVT meeting, we concluded that there should be additional RTP
>|> profiles specifying alternative RTCP behavior.  It is likely that one
>|> of those would specify that receivers would not send RTCP at all, for
>|> use in scenarios where privacy of reception or other factors outweigh
>|> the value of RTCP's reception feedback.
>

---

From: Petri Helenius <[email-masked]>
Date: Fri, 28 Feb 1997 10:07:05 +0200 (EET)

> Also, there would be a huge flood of RTCP packets toward the source.

I should have been more clear here. I'm not suggesting that this
should be done without indication from the source to do so. The source
should tell the receivers either send the RTCP packets to the group,
send them to the source or not send them at all.
 > the client unicasts it's RTCP data to the session watcher.

This is a good optimization of what I propose above.
Pete