All things related to multicast

[ken lindahl <>]

On Thu, 5 Aug 1999, Bill Fenner 
<>
 wrote:
>Well, if you're sourcing in a sparse mode domain then you don't flow into
>dense domains unless the Sparse->Dense border router knows of group
>members inside the Dense domain, right?  (Border routers can know of
>group members inside Dense domains via the sender-is-member hack or
>Domain Wide Reports)

yes. a single user (i'm assuming sender-is-member hack fwiw) can cause
the packets to flow into a dense domain, and the entire domain will see
flood-and-prune.

>Why do we care so much about unsuspecting users in the multicast case
>when we don't in the unicast case?  As far as I know, there's no
>mechanism to prevent someone on a dialup line from clicking on
>http://www.broadcast.com/broadband/* and getting 300kbps or more of
>audio/video.

on a dialup line, they're likely only to hurt themselves. most folks who
hit themselves with a hammer are likely to stop using the hammer that way.
a more interesting case would be the unsuspecting user on a shared 10Mbps
ethernet (or a switched 10Mbps ethernet with mcast-unaware switches)
who joins a 2Mbps session. it _might_ not cause problems for other devices
in that broadcast domain, but i've certainly seen cases where it has.
the I2 demo floor in SF last year being one example.

but to address your fundamental question of why we care more about unsu-
specting users in the multicast case vs the unicast case -- i don't have
a good answer. i'm concerned that the unsuspecting user may cause problems
for others in the multicast case, but of course, that could happen in the
unicast case also.

based on your comments, should we consider a proposal C: all of the
MiG sessions get addresses in 233.0.25.0/24, with no admin scoping, and
we let the bits flow where they may?

thanks,
ken