Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion

From: "Bandi, Sarveshwar" <[email-masked]>
Date: Thu, 22 May 2003 11:12:04 -0400

Hi John,
I have heard this opinion of yours already, Just one observation about your
comment...
--------------------------------------
" Assert 
processing is
	extremely difficult to do without incurring huge CPU costs -- unless

you are
	talking about a very low-end router.  If your product is such a 
router, you may
	think that you don't care about the problems of the high-end
vendors.  
But the
	high-end -must- move away from ASM.  If you (the low-end) don't move

the
	same way, multicast will spend another 10 years not realizing its 
potential."
-------------------------------------

Assert mechanism is used to detect duplication of data on both the SPT and
RPT as well. Even if you do (S,G) join you still can have duplication of
data. And the assert operations would be equally costly both on the RPT or
SPT.
If not for the assert mechanism, one would need to come up with  some way of

solving (if possible) this problem. And probably that solution could be
applied to RPT as well.

Sarvesh

-----Original Message-----
From: John Zwiebel [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 10:23 PM
To: bharat_joshi
Cc: Bandi, Sarveshwar; [email-masked]
Subject: Re: [pim] about the (*,G),(S,G) entry creation and deletion

There seems to be some confusion...
Please listen to me when I tell you "ASM is dead"
Long live SSM
Long Live Bidir.

My point here is, much of the discussion on this list is about
nitty details on how to implement the PIM-SM draft.  This is, of course,
necessary to be able to interoperate with legacy multicast deployments
and to allow users the opportunity to see how SSM and Bidir might
benefit them.  HOWEVER, you need a "good enough" ASM implementation
and you should be concentrating on developing a superior SSM and
Bidir implementation.  (Of course, if you don't want to go that route, 
that's
fine with me, we'll be happy to sell into that market.)

After 10 years of looking at this stuff, here are some points to 
consider.

  -- For ASM: When an RP receives a PIM register, it -should- create 
(S,G) state
	whether or not there are receivers.  Receivers may join after the 
source
	has started to send and you don't want to have to wait for 60
seconds 
for
	the first packet to come down the shared tree.

-- The shared-path and the shortest-path are two different entities.  
In ASM 
	the -only- reason for the shared-path is to deliver the first data 
packet to
	the receiver so the last-hop can join to the shortest-path.  BEFORE,

you
	all say, "but what about staying on the shared-path", yes it is 
possible
	to do this, but let's be very clear, if you elect to stay on the 
shared-path
	it is impractical to switch to the shortest-path when/if the data
rate 
of
	a particular source rises above a given threshold.  Yes, some 
implementations
	do this.  But it -does-not- work.  Therefore, if you are going to
stay
	on the shared-path, the spt-threshold -must- be set to infinity.
And 
if
	you are going to do that, why aren't you using bidir.

-- If you think of the shared-path and shortest-path as separate 
entities, it
	becomes easier to figure out what's suppose to happen when they
	intersect.  There are -tons- of things that the spec does not
specify.

	For example: if you are a transient router, and you haven't received
	a PIM (S,G) join, but you do see multicast traffic on a non-RPF 
interface
	what are you suppose to do?  From the specs perspective: nothing.
	From a practical perspective though, doing nothing may be very, very
	costly depending on the size of the data pipe (ie is it a 10gig 
interface
	with 9gig of multicast traffic -- of which every multicast packet
must
	be examined by the router to determine whether or not the router
	is suppose to deal with it.)  (SSM and bidir reduce these problems
	considerably)

-- WRT SSM, the only router that requires anything different from ASM 
SPT
  	code is the last-hop.  The last-hop needs to be informed of the
source
	in some way so it can join to the shortest-path.  Whether it is
IGMPv3
	or data delivered down the ASM shared-tree or Cisco's URD, or
whatever
	new receiver-to-router protocol you might want to implement, once
	the router knows the (S,G) it triggers a join toward the source and
the
	forwarding path is brought up.  BEFORE you say "what about the
	keepalive timer", remember users don't care as long as the data is
	getting received.  Yes, in SSM the receipt of a PIM (S,G) join is 
suppose
	to update the keepalive timer and this does not happen with ASM.
	This is a very minor difference that isn't going to be noticed if
data
	is being forwarded down the SPT.

-- The biggest mistake we made in developing PIM was to believe that it 
was
	impossible to change the multicast model.  It is silly to think that

we will
	ever be able to develop fast enough routers that the network will
ever
	be reliable enough to "just handle" delivery of the first packet
data 
packet
	to every receiver in the internet.  Some sort of 
"request-to-send/cleared-to-send"
	mechanism is required.  Right now that mechanism defaults to, "go
ahead
	and send, if I (the receiver) miss something I won't care" because 
most multicast is
	audio/video.  Something better is required if we are going to be
able 
to
	deliver file transfer via multicast.  (PGM not withstanding.)  It 
appears
	to me that this RTS/CTS mechanism is probably application specific,
or 
is
	at least, a layer-4 problem.

-- PIM-SM is extremely complicated because of the switch between the 
shared-path
	and the SPT.  It is non-deterministic because one never knows where 
these
	two paths will diverge or intersect with one another.  Assert 
processing is
	extremely difficult to do without incurring huge CPU costs -- unless

you are
	talking about a very low-end router.  If your product is such a 
router, you may
	think that you don't care about the problems of the high-end
vendors.  
But the
	high-end -must- move away from ASM.  If you (the low-end) don't move

the
	same way, multicast will spend another 10 years not realizing its 
potential.

-- SSM is simple to understand and implement.  Routes can be set up 
prior to the
	first data packet being sent.  It interoperates "almost perfectly" 
with the deployed
	ASM routers.  I encourage you all to make whatever noise is required

to get
	the internet community to move in that direction.  Windows supports 
IGMPv3.
	That alone "should be" a large enough installed base to move 
applications
	in that direction.  (I don't suppose there are any application 
developers on this
	list <sigh>).

-- Bidir is simple to understand and implement.  It is presently 
limited to inside of
	an enterprise, but it isn't clear that a many-to-many application
that 
spans
	the internet with thousands of participants is a realistic
possibility 
right now.

-- Neither Bidir nor SSM require BGMP.  BGMP isn't going to go anywhere.

-- Interdomain ASM requires MSDP (or BGMP).  No one has figured out how 
to make
	MSDP work yet.  It barely works "good enough".  IMHO, it is one of
the
	major stumbling blocks to multicast deployment.

So, I'd like to encourage you to "move on".  Your ASM pim is probably 
"good enough"
now.  If it isn't, well, you are implementing yesterday's technology.  
Its kind of like
deciding that you need a really good X.25 implementation in your router 
now.  (or
ATM ;-)

2cents

On Wednesday, May 21, 2003, at 12:49 AM, bharat_joshi wrote:

> Hi,
>
> *,G state will be there when IGMP hosts have not been updated to IGMPv3
> and the desginated rotuers doesn't support IGMPv3.
>
> Lets say we have IGMPv2 on a LAN, the DR will always generate a *,G
> join/prune for a IGMP join/leave message.
>
> S,G state will come in picture when DR start switch to SPT but in this
> case you will need to maintain *,G and S,G both becuase the router will
> never come to know that the hosts connected to LAN wants packet from
> which all sources.
>
> If hosts are running IGMPV3 than a *,G entry may not be created.
>
> Thanks,
> Bharat
>
>
>
> -----Original Message-----
> From:	Bandi, Sarveshwar [mailto:[email-masked]]
> Sent:	Wed 5/21/2003 12:13 PM
> To:	'Zhang Yanxing'; [email-masked]
> Cc:	
> Subject:	RE: [pim] about the (*,G),(S,G) entry creation and deletion
>
> One comment, I dont think the spec says explicitly that a (*,G) should 
> exist
> when (S,G) exists. If someone were to have only SSM routes in a 
> network,
> having (*,G) routes would not make any sense. I think creation of (*,G)
> route when (S,G) routes are created is an implementation issue. We 
> have an
> implementation where (*,G) routes created as and when needed.
>
> Would love to hear others comments on this
>
> Regards,
> Sarvesh
>
> -----Original Message-----
> From: Zhang Yanxing [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2003 8:06 AM
> To: [email-masked]
> Subject: [pim] about the (*,G),(S,G) entry creation and deletion
>
>
>       I think it maybe one implementation problem, I want to speak out 
> my
> thought to see if it is correct.
> Multicast Route entry is created when some interfaces receive the 
> (*,G) or
> (S,G)  join message.
> When all the joined before interfaces recieve prune message(after the 
> prune
> override interval) or
> the join timer expires, the entry will be deleted. This mechanism 
> shows the
> difference between the DM and
> SM.
>      But at the DR with the directly connected senders and the RP, I 
> think
> the (S,G) entry creation is something
> like the DM, it is built by the traffic driven.
>      Another point is that does the specification imply that if (S,G) 
> exist,
> the (*,G) should exist too?
>      Welcome comments, Thanks.
> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim
> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim
>
>
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Thu, 22 May 2003 11:48:28 -0700

> solving (if possible) this problem. And probably that solution could be

I never meant to indicate any differently, nor do I think I said
"don't implement an assert mechanism".

I said it was very expensive to do in high-end routers.

Where is it that most asserts happen?  Two places:
   1) on LANs that use non-congruent routing where downstream routers
	choose different upstream forwarders.  Not much one can do about
	this, and yes the assert mechanism is required here.  OTOH, one
	might suggest to network architects that this is not a "good thing"
	and it should be avoided so they don't have to worry about
	asserts.
   2) when the SPT and the RPT cross on a LAN.  I'd suggest that this 
situation
	is 90% of the asserts that happen in the "real world".  And the
	situation is even worse than one might think because the spec also
	states that when a downstream router switches from the RPT to the SPT
	it is suppose to send a prune to the RPT.  But, if there is more
	than one downstream router, they may not all switch to the SPT at the
	same time.  The net result is a flurry of join-override messages
	followed by prune messages and then also asserts.  Everything
	eventually gets fixed and it all works, but "is this any way to
	run a railroad"?

The "assert problem" isn't just duplicate traffic, but also includes 
how to
handle mpackets just seen on an interface.  What about non-RPF traffic 
that
the router is suppose to just ignore.  How do you drop those packets 
fast
enough?  We're talking Gigabits worth of multicast traffic.  Setting up 
the
forwarding path in advance with SSM and bidir -- avoiding all the 
problems
inherent in ASM, is an excellent start toward eliminating many of these 
problems.

(OTOH, it may be like Ipsilon's TAG switching and technology may soon
overcome this problem.  But it hasn't happened yet, and I don't see it 
happening.)

Now, rather than argue how best to implement ASM -- especially how 
IGMPv3
is suppose to interoperate with ASM, I'd rather have a discussion on 
what
ASM buys you that SSM and bidir don't.

I think the current PIM-SM draft does an excellent job of attempting to
describe how the protocol should work.  Yet, there continues to be 
numerous
of comments on its deficiencies.  And there continues to be problems
with deployment of PIM in the internet.  Doesn't this point to a 
systemic
problem that needs to be solved?  Doesn't this indicate that ASM is just
"too hard"?  Shouldn't we concentrate on simplifying multicast routing?

I'd love to hear your experience in PIM deployment.  Where is your 
implementation
running?  What are the results?  Am I naive to think that there are only
3 router vendors?  (I don't mean to insult anyone, but I am trying to 
bring
some perspective to this -- Oh, and I confess that saying "3" is 
including
Procket so I hope you are all getting a big laugh.)  My desire is for 
interdomain
multicast, that means the internet, that means large ISPs like ATT, 
Sprint,
UUnet etc.  Who do they get their routers from?

Here's your opportunity to try to sell me (and perhaps others -- please 
don't
think I'm trying to say anything like "if you don't sell me it ain't 
going
no-where".)  I want to know the -specific- customer requirement that 
says
we have to have ASM.  In all the mailing-lists I've been on, I've heard 
of
only one.  And that one seems to be more about the fact that the current
application works "good enough" in the environment it is currently 
deployed in.
I haven't heard a single customer or application developer say, "ASM is 
the
only way I'll ever use multicast."  Nor have I heard anyone say, "I
will use IGMPv3 to deny specific sources while listening to the rest of 
the
group."  Yes, one -can- do that, but why?  How does that encourage 
multicast
content delivery from any source in the world to any receiver in the 
world.
In other words, one sender to potentially millions of receivers.  Let's
consider how audio/video is delivered now over the internet.  Its all 
unicast.
Where's the incentive to go to multicast?

So, please provide me with examples of how you expect to deploy 
multicast.
How are you going to use it.  Who is going to use it.  What is the 
content.
Who are the receivers.  How do you envision the traffic getting across 
the
internet.  Without answers to these questions, it may be that multicast 
will
be no more than a niche.  And if that's the market you are going after, 
great.

---

From: Bill Nickless <[email-masked]>
Date: Thu, 22 May 2003 15:01:08 -0500

-----BEGIN PGP SIGNED MESSAGE-----

At 11:48 AM 5/22/2003 -0700, John Zwiebel wrote:

>The "assert problem" isn't just duplicate traffic, but also includes how to
>handle mpackets just seen on an interface.  What about non-RPF traffic that
>the router is suppose to just ignore.  How do you drop those packets fast
>enough?  We're talking Gigabits worth of multicast traffic.

<sarcasm>

You get the underlying Layer 2 infrastructure to not forward you traffic 
that doesn't belong to you.  IEEE 802.1 bridges do that just fine, happily 
running at line rate with parallel 10 Gigabit Ethernet links.

Oh sorry, I forgot.  Except for IP multicast, because IP multicast packets 
are put into IEEE 802 frames with the MAC multicast bit set.  I guess that 
engineering decision made in 1989 for Metcalfe-style single-wire Ethernets 
is good enough for today's IEEE 802 networks.

</sarcasm>

>Setting up the forwarding path in advance with SSM and bidir -- avoiding 
>all the problems inherent in ASM, is an excellent start toward eliminating 
>many of these problems.

How about these prophetic words from Deering & Cheriton in 1985 (RFC 966), 
referring to the decision to make Host Groups open?

    The sender need not be a member of the destination group.  We refer
    to such a group as open, in contrast to a closed group where only
    members are allowed to send to the group.  We chose to provide open
    groups because they are more flexible and more consistent as an
    extension of conventional unicast models (even though they may harder
    to implement).

Yup, I agree.  Allowing unknown senders to transmit to the destination 
group has turned out to be a little hard to implement in the Internet.  I 
think we refer to this as the "bursty source" problem.

SSM is a sneaky way to get around the Deering/Cheriton Host Group model 
definition, and the problem referenced in the above quote.  The 
receiver-driven (S,G) joins explicitly define (to the network) the 
membership of the group--specifically, the identity of the only permitted 
source.

In other words, SSM creates closed host groups, identified by (S,G), where 
S is the only permitted sender.

>Now, rather than argue how best to implement ASM -- especially how IGMPv3
>is suppose to interoperate with ASM, I'd rather have a discussion on what

Existence.

Access Grid 2.0 Release Candidate 1 is now available.  There are over 200 
Access Grid nodes in the research and education community, worldwide.  It's 
open source and free (as in beer).  Go download it and try it on your Linux 
or Windows XP box for yourself:

http://www-unix.mcs.anl.gov/fl/research/accessgrid/software/2.0-rc1/index.html

Access Grid 2.0 already has a notion of "venues" and "venue servers" that 
keep track of all the participants in a collaboration.  There's a whole 
Globus-based authentication environment with X.509 certificates and 
everything.

So why doesn't AG 2.0 support SSM?

Because SSM requires IGMPv3.  IGMPv3 snooping puts *massive* requirements 
on a site's IEEE 802.1 bridges.  MLD snooping is even worse.

If I were an IEEE 802.1 bridge manufacturer, competing on price, I would be 
insane to implement a whole IPv4/IGMP stack (and later an IPv6/MLD stack) 
just to constrain IP multicast flooding.

If I were in charge of an institutional network that still uses the same 
IEEE 802.1 bridges for IP traffic that used to be used for IPX and Apple 
Ethertalk, I would push back *VERY* hard when someone wanted me to 
forklift-upgrade all of my IEEE 802.1 bridges to support IGMP/MLD snooping.

SSM is easy (trivial!) in today's IEEE 802.1-free IP network cores.

SSM is horrifically hard in today's IEEE 802.1-based edge networks.

Oh, and bidir?

It's probably not possible to define a general bidir RP <--> group mapping 
in today's Internet.  There are too many interconnected networks, and they 
simply don't follow any hierarchy that can do (for example) provider-based 
group address delegation.

>I haven't heard a single customer or application developer say, "ASM is the
>only way I'll ever use multicast."

The people down the hall who develop the Access Grid software routinely say 
something very close to that:  "ASM is the only multicast out 
there."  Every six months or so they ask me about SSM, I explain what's out 
there, and they go back to programming to the ASM model.  Or even worse, 
developing their own application-level overlay multicast forwarding 
infrastructure.

(They want the network to trans-code high bandwidth video to something 
lower for sites that don't have fat pipes.  I try to tell them that they 
should use different SSM group addresses at the source for 
differently-encoded video streams, but it's a tough argument to make in the 
context of how hard it is to do IGMPv3 end-to-end.)

>So, please provide me with examples of how you expect to deploy multicast.
>How are you going to use it.  Who is going to use it.  What is the content.
>Who are the receivers.  How do you envision the traffic getting across the
>internet.  Without answers to these questions, it may be that multicast will
>be no more than a niche.  And if that's the market you are going after, great.

The first thing we have to do is make IP Multicast run on today's IEEE 802 
networks as well as it did on 1989's 10Base5 networks.  Not tomorrow's IEEE 
802 networks with IGMP/MLD snooping, but today's IEEE 802 networks.

The second thing we may have to do is figure out a business model for the 
service providers to reap some financial reward for managing the extra 
complexity and state of multicast forwarding.

Perhaps this is related to the problem of big unicast routing tables that 
we hear so much about.  Today's ISP business model is to charge for the 
bandwidth but give away the state management (routing table entries) for 
free.  As any first year economics student will tell you, a commodity that 
incurs zero cost will be abused.  (See a recent NANOG thread for more 
discussion on this.)

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]