Re: Multicast

[Jon Crowcroft <J.Crowcroft at CS.UCL.AC.UK>]

again, i don't know if the WHOLE IETF list wants to see this
discussion, nor if IDMR (which now looks at a fairly small piece of
the multicast picture) wants to be cc:d - the right place for this
discussion is probably pim, and possibly ssm, - idmr is about ready to
close down 

the right solution (imho) is a two protocol world
1/ PIM SSM for 1-many apps with IGMPv3 for join/leave
2/ PIM bidir/BGMP (basically equiv. to hierarchical PIM) for many sender with
some smart inter-domain RP assignment done as part of the
brokering/peering arrangements between providers - this latter needs
lots of work
i) PIM bidir needs finishing
ii) the interdomain part needs implementing (not hard) and detailed
specification

as ISPs get use to intradomain SSM, they may start to comtemplate some
PIM SM, then PIM bidir customers/applications (a while off, but
slowly) - then,when they understand traffic engineering internally for
these applications, they may start to consider how to do inter-domain
peering and traffic engineering 

on any plausible timeframe for this, routers maybe able to handle the
state for the many-sender protocols (certainyl they wont be today or
tomorrows routers), so as long as state scales linear or sublinear in
#many-sender flows, it is not out of the question (not great, but not
out of the question) - hierchical approaches based on bidir trees can
do some aggregation to get it better than s,g (if we believe we will
have a lot of apps anyhow with genuine inter-domain, globally visible
state required. ... it aint obvious - a lot of apps we are thinking
about can be global, but stay mainly within a single tier 1 provider,
until they say auto-tunnel thru the access provider. some apps can
just use small numbers of SSM flows from the server site. lots of
alternatives ....

anyhow, as i say, this discussion is already ongoing in the relevant
groups (including mboned) and direcrorates...not on idmr and ietf:-)

In message <3BC5217C8E6D9E498F4F682CD7FF75460F9E44 at mail10.main.ntu.edu.sg>, #PA
THIK GUPTA# typed:

 >>Hi,
 >>
 >>It is true that there are certain scalability issues with Multicast. However
 >>the solution of this is to have a very good InterDomain multicast routing as
 >>well as Intra Domain multiast routing protocols. With that the problem of
 >>host affecting the entire routing core is greatly reduced.
 >>The protocols like CBT and PIM-SM were developed because it was found that
 >>protocols like DVMRP and PIM-DM cannot scale. It is also neceesary to note
 >>the fact that PIM-SM is only efficient for the sparesely disributed hosts
 >>and it is a Receiver initiated protocol. This has significant advantage over
 >>flood and prune protocols like DVMRP.
 >>
 >>If you think of the scenario where there are very less hosts receving the
 >>session and why dont we just send data directly, then this solution cannot
 >>scale. The whole purpose of multicast is lost. The server will be burdened
 >>and each unicast stream will contribute more to a single multicast stream.
 >>
 >>Cheers,
 >>Pathik Gupta
 >>
 >>-----Original Message-----
 >>From: Gunnar Lindberg [mailto:lindberg at CDG.CHALMERS.SE]
 >>Sent: Thursday, March 08, 2001 4:13 PM
 >>To: idmr at CS.UCL.AC.UK; ietf at ietf.org
 >>Subject: Re: Multicast
 >>
 >>
 >>Please explain what's wrong with my take on multicast scalability:
 >>
 >>Every time a new sender shows up, the entire multicast core (RPs,
 >>right now those running MSDP in the default free zone) has to be
 >>informed. To "show up", the host just starts sending data.
 >>
 >>Every time a new receiver shows up, its nearest RP has to initiate
 >>a data distribution path (tree) torwards the sender(s). This is
 >>likely to involve at least some of the core routers.
 >>
 >>Scalability problems:
 >>
 >>    1)	An indivivual sender - host, my Linux PC - affects routing
 >>	information in the entire router core. Just send data.
 >>	There are a few hosts on the Internet.
 >>
 >>    2)	As if his wasn't enough, consider the potential for DoS-
 >>	attacks. The recent Ramen worm was the first(?) example;
 >>	who can claim it was the last?
 >>
 >>Assume technology evolves fast enough to solve 1). We still have 2).
 >>
 >>My claim is that it doesn't scale to allow individual hosts to affect
 >>the Interet core routing system. What do I miss?
 >>
 >>	Gunnar Lindberg
 >>

 cheers

   jon

), in memory of lowell george