ietf
[Top] [All Lists]

Re: Multicast

2001-03-08 04:40:03

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(_dot_)main(_dot_)ntu(_dot_)edu(_dot_)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(_dot_)CHALMERS(_dot_)SE]
Sent: Thursday, March 08, 2001 4:13 PM
To: idmr(_at_)CS(_dot_)UCL(_dot_)AC(_dot_)UK; ietf(_at_)ietf(_dot_)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



<Prev in Thread] Current Thread [Next in Thread>