Subject: RE: Progressing IDMR items

From: [email-masked]
Date: Thu, 27 Feb 1997 11:09:49 -0800 (PST)

[ "Arlie Davis" <[email-masked]> wrote:]

|> >> Imagine 5 million people watching a single multicast of the NFL Super
|> >> Bowl.  Instead of N routers maintaining state for a single (S,G) pair,
|> >> they have to maintain 5,000,001 (S,G) pairs, _no matter how infrequently
|> >> the receivers advertise_.  Aggravating, isn't it?
 
["Dino Farinacci" <[email-masked]>:]

|>     One would also argue that the RTCP backoff as the group gets larger is
|>     more of a detriment to routers, since the (S,G) timeout will occur
|>     more frequently than the RTCP transmission interval. Therefore, in a
|>     dense-mode router, there is a malloc() for every transmission of the
|>     5,000,001 sources to create (S,G) state. This can't be good in any
|>     router both from a memory fragmentation point of view and a switching
|>     point of view.

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.  

----

[Dino Farinacci:]

|>    This is why SPT thresholds were created in PIM. If you set the SPT
|>    threshold in a cisco to say 8kbps, only the active "speakers" get an
|>    (S,G), everyone else uses the (*,G).

And, Steve Casner also replied:
["Stephen Casner" <[email-masked]>:]

   [Arlie Davis:]
|> > RTCP puts a much greater strain than is necessary on (S,G)-state
|> > implementations.  This is rather unfortunate.
|> 
|> Both on the rem-conf list and in the last AVT meeting, we have had
|> significant discussion of the use of RTCP in large broadcast
|> scenarios.  I'll attempt to move this discussion back there [bcc to
|> mbone].
:

|> With a shared-tree routing protocol, there is only (*,G) state for the
|> receivers because the RTCP data rate is low enough not to trigger the
|> formation of a source-rooted tree.

|> > 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.
|> 
|> 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.
|> 
|> BTW, at the AVT meeting I invited the submission of proposals for
|> additional profiles, but I don't think any such proposals have been
|> submitted yet.  (Not to neglect Bernard Aboba's I-D on the issues and
|> the useful email on this topic.)

---

One of the things which several people at IETF requested,
after a similar discussion to this mailing list discussion,
[I guess nobody has responded with anything concrete] 
was some method to [reliably] estimate the number of 
listeners without actually getting individual reports.
Normally, it is a Bad Thing to ask Routers to do
something other than Route, so, this method likely 
should be something driven by the multicast source itself,
to which [some of] the receivers can [randomly] respond, 
if asked.

Also, if we are talking about millions of viewers and
commercially significant advertising dollars possibly based
on viewership, then, there probably needs to be some kind
of difficult-to-spoof authentication built in, too.  After all, 
what is there, today, to prevent a single source from falsifying
non-existent-listener reports?  So, we need a statistically
valid, authenticated, but private, low-upstream-bandwidth,
router-independent method for estimating viewership.  Ideas?

-Hugh LaMaster

---

From: Petri Helenius <[email-masked]>
Date: Thu, 27 Feb 1997 22:26:34 +0200 (EET)

> competition to DirecTV and/etc.????  For little more than the

I'm in for this one. Many companies in US and abroad have announced
*DSL offerings in the sub-$100/month range. That's in the ballpark
what you pay for your cable, phone and 28.8 ISP connection.
(but does or is going to do you much more than that)

 > see the Internet in direct competition with existing systems.
I don't want to talk about competing either, I would call it
replacement. After you have the bits flowing you don't need to have a
wire per purpose. You can have it all from the same wire. 

 > long existed.  Sure, we need to make sure everything scales up

The issue here that the incremental cost of doing both is extremely
small. (if going from the "small" market content to mass market, the
other direction is more expensive)

 > People can already do that, *more cheaply*, just by watching TV.  
I disagree with the cost argument here. With the digital television
technology, all is going to be bits anyway, so I don't think consumers
are going to really care what delivers their bits. As long as they get
the bits. Also there is huge forces behind on the integration on
computing devices and larger screens (read: PC and TV) to provide
multimedia content to the couch potatoes.

 > people.  Now, add multicast.
Remember CIDR? An average home does not need eight bits address space (yet).
I used to have a C-class network at home but swapped it to 4 bit
subnet some while back (just to be a good citizen).

 > the information on how well "most people" are receiving the broadcast.
You can build your apps to send the RTCP messages to the source, not
to the multicast group. This way the RTCP "problem" goes away.
Regardless of the routing protocol. I for myself wouldn't care of my
neighbor knowing what I watch on my "internet television" nor I would
like you to know.

 > worry about that.  I really don't think RTCP is much of a problem.]

Exactly :-) In a game everybody is a source. That's going to be the
greater challenge.
 > media [e.g. cable modems], and also for Privacy.  
Glad that you mentioned privacy as an issue too.
 > router-independent method for estimating viewership.  Ideas?
I think the keyword here is "estimating". The figures need to be in
the ballpark but they do not need to be exact. However, no clever
technical ideas come into mind right now :-(

Pete