Subject: RE: draft-ietf-pim-dm-new-v2-04.txt

From: "Nicholas, Jonathan" <[email-masked]>
Date: Fri, 20 Jul 2001 14:28:31 -0500

> This looks nice.  Unlike most folks, I do believe that
> a requirement for dense-mode will develop.  I look forward
> to going over your spec in more detail.

Thanks.  We worked hard on it.

> A couple of immediate observations...
> 
> One of the issues I don't see addressed though is the TTL problem
> for expanding ring searches.  There is a problem in cisco's
> where if a packet is received with a TTL of 1 and its
> destination address isn't the router, that packet will have the TTL
> decremented and thrown away.  This causes assert problems and 
> duplicate traffic on the lan.  I'll grant you that this could
> be considered a cisco specific problem, but I wouldn't be 
> surprised to find it in other routers also.  I don't have
> a "good" solution for the problem, but you may want to address it.

I think you have a good point here.  The spec should clearly state
processing precedences in conditions like this.

> > It was stated at the Minneapolis IETF that for pim-dm to be
> > the most useful, the specification should incorporate the
> > state-refresh work. This draft doesn't yet incorporate that work.
> >
> 
> FWIW: without state-refresh there's no need to look further into
> this spec.  There are way too many protocol problems with the
> periodic flooding of data to refresh state, resulting in long
> blackholes of data and/or flooding of excessive data on to a lan.
> 
> Perhaps you intend to make the document "most useful" at sometime,
> but, seriously, without state refresh dense-mode shouldn't be 
> deployed.
> (the only exception is in the case of a network that has a member on
> every subnet, ie auto-rp, and this is a poor exception.)

I understand this is a problem, but it isn't clear to me why.  Could you (or
someone) send me a brief description or example?  I really would like to
resolve it to everyone's satisfaction.

> > 2. Should Assert processing depend on Prune status?
> >    Pros:
> >      Consistent with PIM-SM.
> >      Less processing required.
> >    Cons:
> >      Graft actions more complicated.
> >      More frequent Assert Negotiation.
> >
> 
> Do state-refresh and the frequent assert problem goes away.
>  
> 
> I've been working on PIM since Dino first coded it.  Dense-mode
> without state-refresh is a non-starter.  
> 
> While I'm "on a role" (ie bitching), I'd also like to encourage
> this group to require the source to ask for permission to send
> to the network.  Every IETF the same discussion comes up about
> how difficult it is to implement a protocol that allows the
> source to just dump traffic on to the network and then expect the
> routers to handle it.  I keep saying "CTS/RTS".  Then I'm told
> the host vendors will take too long to incorporate such a change in
> their OS so "its too hard".  Now 5 years later we still have the 
> same stupid problem with customer's demanding that multicast
> be more stable and that no data be lost.  That's impossible 
> as long as the source can just dump traffic on to the net.
> 
> Of course, I can be accused of "just bitching", after all, if 
> I thought it was so important, I'd write a draft myself.  :-)

Sadly, this is probably outside the scope of just PIM-DM.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

---

From: Andrew Adams <[email-masked]>
Date: Fri, 20 Jul 2001 16:58:37 -0400

> resolve it to everyone's satisfaction.

I'd like to see more discussion on this as well.

-Andy

---

From: John Zwiebel <[email-masked]>
Date: Sat, 21 Jul 2001 18:00:20 -0700

> resolve it to everyone's satisfaction.

Let me restate the "problem" so we're all on the same page.

PIM-DM without state-refresh requires periodic flooding
of data to maintain state for a given (S,G).  This results
in several problems because for networks with few (sparsely 
populated) members data if flooded to the boundaries of the 
network resulting in:
  -- wasting bandwidth.
  -- reprocessing of asserts
	o waste of router CPU
	o waste of host CPU (MAC level filtering doesn't
		always work or isn't turned on)
	o asserts are complicated enough and prone to error.
		Should be avoided.  
		Many network problems I've seen have been related
		to asserts.  Granted many of these are because of
		implementation problems, but if you do the assert 
		1 time and then keep that information alive with
		state-refresh, it may be "wrong" (from a RFC
		perspective) but at least it won't keep breaking
		everything.
  -- extremely difficult to debug.  Sparse-Mode olists are
	"correct" as long as there are receivers.  Dense-mode
	can come and go and still be "correct".  One time you'll
	look at the mroute table and the interface will be there,
	seconds later it will be pruned.  You can't trust the 
	information.  To recreate many problems, I found it
	necessary to think of what "might" be happening and then
	see if I could design a test that had very elaborate 
	steps that could be duplicated precisely.  It was impossible.
  -- state doesn't time out along a very long path "nicely".
	If you have (for example) 10 hops leading to a receiver
	who hasn't joined the group, each hop can delay processing
	the prune received from the downstream PIM neighbor for
	up to 10 seconds to correctly process JOIN overrides.  That's
	100 seconds that the source-first hop router may have been
	forwarding data before it receives a prune.  If your receiver
	decides to join the multicast group 1 second after the
	(S,G) times out on its last-hop router, it will have to
	wait as long as 99 seconds for the first-hop router to
	time out that (S,G) and reflood data to the edge of the 
	network.  This is avoided if you have a member on every 
	subnet in your network.  For something like the auto-RP
	mapping agent, since the messages to 224.0.1.39 are sent
	1/minute and the information is "the same", this generally
	isn't a problem.  For other applications though, its
	a guarantee that data will be lost.

FWIW, state-refresh advertises a source to the boundaries of 
the network forever.  This is a "good thing" if you are thinking
of using dense-mode instead of sparse-mode (maybe OK) or SSM (not
a good idea).  It isn't clear to me how it can or should be 
effectively used for something like an expanding ring search.

There are now 4 modes in PIM.  SSM is the _obvious_ choice for
interdomain multicast which (appears) will be the dominent
use of multicast because it will be one to many.  SSM is also
useful for many-to-many -- if the application figures out a way
of doing RP functionality (meaning the receiver has to know
the specific source address, not so different from unicast
where the source has to know the receiver address.  It's very
important to note that DNS is _NOT_ part of a routing protocol
(like ospf) so one questions why multicast ever went down the
"RP" path and why, once SSM was proposed, it was received so
negatively (mea culpa).

Bi-dir PIM is an obvious choice for many-to-many within an
enterprise.  How many applications can you think of _really_ are
many-to-many?  What I mean hear is so_many-to-so_many.  TIBCO
is, but that is hundreds of computers sharing information with
one another.  Any application that includes "people" that goes
beyond 10 participants will have to require a "master of 
cerimonies" to arbitrate who's going to talk when.  In those
apps, a 1-to-many SSM session with unicast from the receivers to
the SSM source relayed down the SSM distribution tree is the
answer.  (RTCP "failed" because it created so much state in
the routers the multicast session -- and the entire network --
died.  "reflecting" RTCP packets from the "master" source
has a much brighter future.)

Sparse-mode is "dead".  My comments on the RP being inside of
the routing protocol I think support its "death".  (Although
it may be long and painful and I'm certainly not saying
to abandon it today since it does work.)  

That leaves dense-mode.  I believe that with state-refresh it
offers a necessary capability.  The "rp-functionality" (where
receivers discover sources) is extremely simple.  As long as
a source is sending, receivers know it.  But it isn't clear that
this is all that much better than putting the source
information into a web-page (ala SSM).  

So, the fabled "expanding ring search" is all that's left for
dense-mode.  Now the question is, does such a search require
continued communication via multicast once the "service" is
found?  IMHO, no.  But there may be some charaturistics I'm 
missing.

Hope you find this helpful.