Subject: RE: [pim] register messages vs. the SPT

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Fri, 6 Feb 2004 18:22:29 -0600

> So, I submit to you that sending a single register to the RP 
> and having  
> the
> RP join to the SPT (X-line) would be "good enough".  Not 
> according to  
> the
> spec, but definitely "good enough".
> 
> Arguments about how this decision will result in lost packets to the  
> receiver
> are valid, but considering how horrible PIM ASM is at delivering all  
> the packets
> anyway -- who cares.

From what I understand, you are suggesting that Sender's DR should be sending just one Null Register packet and no further Null/Encap Registers at all. This would be ok with the receivers who are ready to miss few initial packets (for the time duration of getting native path established - (S,G) Join reaching Sender's DR from the RP). Moreover, if this Null Register packet gets dropped, then RP will not be aware of the new source at all. 

What is the gain in doing this ? I believe that sending Registers encapsulating data is worth the effort and overhead for minimizing lost packets for the receivers.

> NOTE, the spec specifies that NULL registers are sent as a "probe"
> and that if a register-stop isn't received that an encapsulated
> register is sent.  In practice this "should" mean that the
> encapsulated register should never get sent.  It isn't clear to
> me why an RP that receives a NULL register but doesn't respond
> with a register stop will do any better with an encapsulated
> register, but I suppose an implementation might drop NULL registers
> (because of CRC errors or whatever) and not drop encaped registers.

That's true. If RP is not responding to Register-Stop, then it is highly likely that it will not respond to encapsulated register also. Only advantage in doing this could be that receivers can get decapsulated data (that also is based on the assumption that native tree is broken).

--
Sonum

> -----Original Message-----
> From: John Zwiebel [mailto:[email-masked]] 
> Sent: Thursday, February 05, 2004 3:40 PM
> To: Mathur Sonum-CSM109
> Cc: John Zwiebel; 'Rahul Bahadur'; [email-masked]
> Subject: Re: [pim] register messages vs. the SPT
> 
> 
> 
> 
> On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote:
> 
> >
> > No, after register-suppression timer expires, DR should send Null
> > Register packet to the RP (it is to inform RP that Sender is till  
> > active and to refresh the (S,G) state on RP without sending data).  
> > Moreover, SPT should not have been built as there are no 
> receivers so  
> > far (hope that's what you meant). Even if the receiver had joined,  
> > then also DR should just send Null Register packet to RP after the  
> > reg-suppression timer expires. In that case, (S,G) state on RP and  
> > PIMrtr would be constantly refreshed by data.
> >
> > --
> 
> First the spec then reality...
> Not quite true or there would be no need for the N-bit:
> 
>    N    The Null-Register bit. Set to 1 by a DR that is probing the RP
>         before expiring its local Register-Suppression timer. Set to 0
>         otherwise.
> 
> However, this is a case of following the spec to the letter vs doing  
> somthing
> that is "good enough" to accomplish the job.
> 
> By this I mean that the spec defines a "rp-probe time"
> 
> 
>    Timer Name: Register Stop Timer (RST(S,G))
> 
> 
>     
> +---------------------------+----------------------
> +--------------------+
>    |Value Name                 |Value                 | 
> Explanation       
>    |
>     
> +---------------------------+----------------------
> +--------------------+
>    |Register_Suppression_Time  |Default: 60 seconds   | 
> Period during     
>    |
>    |                           |                      | which 
> a DR stops  
>    |
>    |                           |                      | sending  
> Register-  |
>    |                           |                      | encapsulated  
> data  |
>    |                           |                      | to 
> the RP after   
>    |
>    |                           |                      | 
> receiving a       
>    |
>    |                           |                      | 
> RegisterStop      
>    |
>     
> +---------------------------+----------------------
> +--------------------+
>    |Register_Probe_Time        |Default: 5 seconds    | Time 
> before RST   
>    |
>    |                           |                      | 
> expires when a  
> DR  |
>    |                           |                      | may 
> send a Null-  
>    |
>    |                           |                      | 
> Register to the  
> RP |
>    |                           |                      | to 
> cause it to    
>    |
>    |                           |                      | 
> resend a          
>    |
>    |                           |                      | 
> RegisterStop      
>    |
>    |                           |                      | 
> message.          
>    |
>     
> +---------------------------+----------------------
> +--------------------+
> 
> 
> But what is the register used for?  To create state in the PIM-RP.
> 
> I'm going to cover lots of possibilities but not recommend anything in
> particular, However, if I were implementing a new PIM, I'd 
> want to make  
> sure
> I met all the following.
> 
> So back to creating state on the RP, that can easily be done 
> with just a
> NULL register to create (S,G) state.  Yes, that means that 
> there will  
> not
> be a data packet to send down the shared-path, but consider 
> that if the
> RP does not have (*,G) state you'll have done all that 
> encapsulating for
> no reason.  How expensive that encapsulating is, I don't care 
> to debate.
> 
> OK, if you -do- have (*,G) state, what is the first-thing the RP is  
> suppose
> to do?  Yes, decapsulate and send the packet down the 
> shared-tree, but  
> then
> -also- join immediately to the shortest-path to create the X-line  
> getting
> data to flow up to the RP.
> 
> Now, you have to worry about sending your register-stop.  If 
> you wait as
> required by the spec for data to arrive natively, you could 
> end up with
> the first-hop and the rp having full forwarding queues in 
> their Route  
> Processor
> (since data encap and decap happens on the route processor -- 
> let us not
> get into worrying about whether or not a vendor can install a separate
> processor to take care of this encapsulation since I agree it can be  
> done,
> but I would question why one would want/need to do it as you 
> will see.)
> 
> So, I submit to you that sending a single register to the RP 
> and having  
> the
> RP join to the SPT (X-line) would be "good enough".  Not 
> according to  
> the
> spec, but definitely "good enough".
> 
> Arguments about how this decision will result in lost packets to the  
> receiver
> are valid, but considering how horrible PIM ASM is at delivering all  
> the packets
> anyway -- who cares.
> 
> Now, there is the question about whether or not an encapped 
> data packet  
> is
> required in the register.  Remember the RP is going to join to the SPT
> and once the X-line is set up packets will get forwarded down 
> the shared
> tree at all intersections with the X-line.  (ie, all these turn-around
> routers are going to get set up).  This happens according to 
> the spec  
> now
> so it isn't like its an either/or situation.
> 
> So, I submit that including an encapsulated packet could be considered
> another over-engineered aspect of PIM-SM.
> 
> Now, remember that the last-hop router is going to join to the SPT  
> anyway.
> It has been shown that PIM-ASM, although designed to do so, can not
> effectively switch between the shared-tree and shortest-path in a
> manner that is reliable enough to not drop packets (or deliver
> duplicate packets, if not both).
> 
> The PIM-RP is used for source discovery.  In a more well-developed
> protocol and if we hadn't been on drugs for the last 10 
> years, we would
> have realized that having the network do source discovery -- 
> especially
> when talking about interdomain multicast -- is insane.  (Now is when
> this discussion will drift off into the SSM/Bidir vs Sparse mode  
> argument.
> Do understand that we -must- get there and we have to do whatever it
> takes to get there and all objections to the contrary which 
> insist that
> ASM is working are moot because ASM requires too many resources from
> the network and it always will -- but that doesn't mean that we can
> drop ASM today.
> 
> So we need to keep (S,G) alive on the PIM-RP for source discovery.
> PIM registers are the only way this can be accomplished.
> 
> AFAIC, I don't care if they are encapsulated, or NULL registers
> just as long as they get there every 3 minutes.
> 
> NOTE, the spec specifies that NULL registers are sent as a "probe"
> and that if a register-stop isn't received that an encapsulated
> register is sent.  In practice this "should" mean that the
> encapsulated register should never get sent.  It isn't clear to
> me why an RP that receives a NULL register but doesn't respond
> with a register stop will do any better with an encapsulated
> register, but I suppose an implementation might drop NULL registers
> (because of CRC errors or whatever) and not drop encaped registers.
> 
> So, bottom line, NULL registers _should_ be "good enough" for most
> implementations.  Make sure your NULL registers work.  Make sure
> that you can deal with a checksum over just the pim header and
> over the entire packet since some implementations do one and
> some do the other.
> 
> Now your ASM is "good enough" and you can move on to getting
> SSM/Bidir developed and deployed and use your political skills
> to get switches to support IGMPv3 snooping (or get GARP developed)
> and get applications to support SSM and Bidir and get some reliable
> source discovery system that doesn't require the network to store
> those sources.
> 
> Oh, and finally, find a way to deal with Beau's SSM DOS attack.
> 
> Pretending that ASM is going to work to get multicast to move beyond
> what it is now is putting our heads in the sand.
> 
> (Caveat, certain equipment vendors have a bounded network problem
> for which ASM may quite nicely meet all their requirements and for
> which SSM and Bidir may not add any functionality.  Great.  No
> argument.  But if your multicast is suppose to run across the internet
> or even in a large enterprise with large BW requirements, its time
> to move on.)
> 
> 
> > Sonum
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of  
> > Rahul Bahadur
> > Sent: Thursday, February 05, 2004 12:15 PM
> > To: [email-masked]
> > Subject: [pim] register messages vs. the SPT
> >
> >
> >
> > Hello,
> >
> > I have a question about register-encapsulation vs. the SPT. 
> Assume the  
> > following topology:
> >
> > source - DR - PIMrtr - RP -------- receiver(s)?
> >
> > The source is constantly sending traffic.
> >
> > Initially the DR has no state and sends a register packet 
> to the RP  
> > that replies with a register-stop. The DR stops 
> encapsulation starts  
> > the
> > register-suppression timer.
> >
> > Now (for some reason) the SPT gets built, i.e., the DR receives an  
> > (S,G) join from PIMrtr. The DR starts forwarding data natively.
> >
> > When the register-suppression timer expires, should encapsulation  
> > re-start?
> >
> > Thanks,
> > Rahul
> >
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pim
> >
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pim
> 

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Fri, 6 Feb 2004 17:09:08 -0800

On Feb 6, 2004, at 4:22 PM, Mathur Sonum-CSM109 wrote:

>
> What is the gain in doing this ? I believe that sending Registers 
> encapsulating data is worth the effort and overhead for minimizing 
> lost packets for the receivers.
>
>

5 years ago I would have completely agreed with you.

Things have changed.

I gave a presentation to I2 in Hawaii 2 weeks ago outlining the
problem since they are (were?) happy with ASM since they had
spent a lot of time getting it to work.

In summary, which hopefully provides you with all you need to
understand my point, when PIM was first thought up it was suppose
to address all the different multicast forwarding models that
anyone had ever thought of.  (Sparse, Dense, Shortest-Path, Shared)
When every packet had to be examined by the CPU anyway, there was
no additional cost to making this happen.

Now, experience has shown us that dense-mode just isn't all that useful.
Experience has shown us that RFC1112 which expects the network to
"just handle it" is not realistic -- especially when talking about
multicast around the world.  Experience has taught us that ISPs
love to blame each other for any problems (actually, that is
rather harsh.  Its more like they just don't want to have to
explain to their customers that something that they have no
control over is broken and they have to wait for some other
ISP to fix it before it will work.  I can't blame them for that
since I have the same attitude.)

And technical advances have allowed routers to separate the 
control-plane
from the data-forwarding plane.

Well, -right-now- (meaning next year it may change) even though
high-end routers can do a good job of making PIM work, it takes
a lot of router resources.  Those resources could be used for lots
of other things (even MPLS if you really want to be retro -- this
is an opinion and should be overlooked if you really want to get
where I'm going)

So, shortest-path trees and shared-trees have shown themselves to
be useful.  Having a combination of SPT and shared has -not- shown
itself to be useful.  (ie, the idea that a last-hop might put
low bw sources on the shared-tree but join to the SPT for high bw
source has proven to be a nightmare.  It does not work.)

Its time to apply the KISS (keep it simple stupid) principle to
multicast.  SSM and Bidir PIM.  One laments the fact that EXPRESS
was never deployed, but then the recognition that it would have
made shared-trees difficult comforts one.

So this is a long way of saying, PIM registers are left-overs from
the last decade.  The idea of making the network responsible for
source discovery needs to have a wooden stake driven through its
heart.

Now, please understand that I'm much more concerned with interdomain
multicast or large enterprise multicast.  In this environment, 
registering
with the RP, delivering data down the shared tree, switching to the
shortest-path, and -not- dropping a packet is impossible.  Your
deployment and your application may be completely different.

You may have found that ASM works extremely well for you.  I am not
advocating that you dump something that works for something that
will work just as good.  (I have a dim feeling of what
motorola is doing with multicast and given the small diameter of
the network I think you are dealing with, ASM will work just great.)

Finally, WRT PIM registers, I wasn't advocating changing the spec
nor am I telling you to avoid dealing with the spec.  Its a good
spec.  They put a lot of work into it and should be proud of it.

With ASM, the PIM-RP (note I have to say PIM-RP because RP is often
mistaken for the Route Processor which is the brains of a high-end
router.) -must- be able to maintain (S,G) state for every source
that is sending.  You can use NULL (data-header) registers or
encapsulated registers to keep this state alive.  My point was that
as long as the state is alive on the RP, you shouldn't have to
implement all the different parts of the spec to be able to
deliver mpackets.

And since the only way to ensure you don't drop packets is to
use SSM/Bidir (well, actually I should say that ASM is nearly
guaranteed to drop packets in the environment I'm interested in)
I am trying to encourage you to say "my asm is good enough, its
time to figure out how to do SSM/Bidir".

SSM needs IGMPv3 in the host.  That means we need lots of folks
banging on the OS guys asking for their IGMPv3.  Heck, you might
want to spend time getting IGMPv3 into your favorite OS.

A new directory system that lets hosts discover sources without
having to depend on sdr and PIM registers is another area that
needs some new ideas.

Making your PIM implementation comply totally with the current
PIM spec isn't necessarily a bad idea.  Its just an idea that has
passed.  (Like ATM, and MPLS -- OK maybe MPLS hasn't died yet, but
its just another way to do ATM so I believe it will.)

I want to encourage you to solve the big problem, not show that
you can comply with an old wet-dream that's 10 years old.

See my point?

---

From: John Zwiebel <[email-masked]>
Date: Fri, 6 Feb 2004 17:09:08 -0800

Things have changed.

See my point?

---

From: Bill Nickless <[email-masked]>
Date: Mon, 09 Feb 2004 12:28:14 -0600

At 05:09 PM 2/6/2004 -0800, John Zwiebel wrote:

>multicast around the world.

<snip>

>want to spend time getting IGMPv3 into your favorite OS.

(Thwapping the expired equine one more time....)

Fixing router code to do SSM is easy.  It's merely a software upgrade to 
tell the router *not* to do PIM Registers and (*,G) joins within certain 
group address ranges.  OK, adding IGMPv3 support on the edge, perhaps.

Fixing operating systems to do SSM is moderately difficult.  There are more 
operating systems deployed out there than routers.  But the good news is 
that operating systems are a lot more extensible than in years past.  Also, 
applications can do things that traditional operating systems 
couldn't/wouldn't do--just look at the Microsoft model where application 
writers distribute Microsoft-written .DLL files to get new functionality or 
fix bugs in Windows itself.  Heck, when I install Visio from Microsoft, it 
installs a complete SQL-based relational database!

Fixing edge IEEE 802 networks to do IGMPv3 snooping properly is simply not 
going to happen, especially when the only driver is that SSM absolutely 
requires it.  And do you really think that the commodity IEEE 802.1 vendors 
are going to do MLD snooping at all, much less MLDv2?  I'm not privy to 
Linksys's product roadmap, but don't have much hope it's there.

>you can comply with an old wet-dream that's 10 years old.

SSM will not take off until applications can take advantage of it without 
requiring massive fork-lift upgrades of IEEE 802 edge/customer networks or 
adding much more IP routing smarts to their networks.

This probably means re-engineering the mapping of IP packets to IEEE 802 
frames, perhaps to the point of not trying to leverage the IEEE multicast 
facility to do IP multicast replication on the LAN.  (The message-passing 
supercomputing software community has been doing collective operations 
without a LAN multicast facility for many years.)

It also means automatic transition mechanisms (like the IPv6 community is 
having to build and deploy).

And finally, it means applications taking responsibility for providing 
whatever facilities are needed, even if that means carrying along little 
bits of code that we would wish were already in the underlying operating 
systems.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP: 021D EB98 03B3 2E83 3D71  0397 251D 819A D0BE EA32 [email-masked]

---

From: Bill Nickless <[email-masked]>
Date: Mon, 09 Feb 2004 12:28:14 -0600

<snip>

===

---

From: John Zwiebel <[email-masked]>
Date: Mon, 9 Feb 2004 13:37:22 -0800

Bill:

I can not disagree with any of the points you make.
> adding much more IP routing smarts to their networks.

Let me ask a stupid question...
GARP?  Would it make things happen faster?  There are GARP switches out
there, are there enough that if routers and hosts all took advantage of
it that we could move to the SSM/Bidir without having to snoop IGMPv3?

Or, can we just turn off all the snooping and layer2 filtering for
multicast packets and have multicast packets sent to every port.

I only ask these questions to transition to another question that we 
need
to look at.  We can't 'push' multicast on anyone.  If they don't want 
it they
won't take it.  If they do want it, then its a question of how badly 
they
want it and how much it costs to make that transition.

In other words, if GARP or flooding aren't viable alternatives and
a fork-lift upgrade is required, then if folks want it they will bite
the bullet and they will upgrade.  It will happen, it just may not
happen as fast as we would like it to happen.

Switches have -never- been very good at handling multicast.  (If someone
wants to spin off a separate discussion on this so I might learn 
something,
I'd appreciate it.)  They've always assumed that they could just 
broadcast
it everywhere.  And when you talk about a lynxsys, well, I don't care if
its capable of doing IGMPv3 snooping or not as long as it passes
the multicast packet to the receivers.

I'm not trying to suggest that there is no need for CGMP/RGMP or 
snooping,
I'm saying that customers have to make a choice.  Do they want
multicast or not?  Allowing a dumb switch to be the barrier to realizing
the full potential of multicast will cause the deployment to be delayed,
but it isn't going to stop it completely.

> facility to do IP multicast replication on the LAN.
>

I may not understand what you are suggesting, but I don't believe this 
is
going to happen.  It -sounds- to me like you are suggesting something 
which
is similar to the way ATM implements multicast by opening a separate VC
from the head-end to each tail end.  Having watched that fail over and
over again (well, it was never "good enough" for me -- I don't mean you
weren't successful to a limited extent) I wouldn't go down that path 
again.

> having to build and deploy).

It isn't clear to me what you mean here.  6to4 tunnels?
AMAP is being proposed to provide a way of transition a multicast 
stream to
a unicast stream and setting up this tunnel automatically.  However, 
this
is going to require application development and there are objections to
how to deploy it also.  (Not saying we shouldn't, but UDLR didn't go
anywhere.)

finally, there is IGMPv2 to v3 translation.  The host joins just the
group, but the router translates that join to a (S,G) and sends a pim
join for that specific channel.  Lots of problems here also.

> bits of code that we would wish were already in the underlying 

And obviously, that is what we need to do.
For too long now, separate organizations have been waiting for the 
"other guys"
to solve the problem.  Certainly a lot of that is understandable since
each group gets their part to work within their limited environment and
no one has the global responsibility for making this all work.

We can argue forever about whether we need content first or 
infrastructure first.

The NANOG presentations I'm watching right now just said something about
how the most efficient networking can be accomplished by
making sure that the router was directly connected to the fiber without
anything in the way.  Folks are upgrading routers, perhaps they won't
buy switches.

My point in this discussion is to get folks to recognize that there is a
problem, that if they want to solve the problem they need to look beyond
the limited area over which they currently have control and recognize 
the
problems that the other areas are having.

ie, switches need to do -something- to deal with multicast as it is.
GARP was their solution, but is it "good enough"?
If it is, why isn't it being implemented in routers and hosts?

I tried to outline the problem from a router perspective.  Routers
-can- do ASM and they do it well, but ASM is difficult to get right
and because it is data-driven and -not- just control plane driven,
it uses tons of resources on the router that could be used more
efficiently for other functions.  You have a choice in how you want
to allocate that processing power.

So the question for you is, what are we going to do about it?

I want efficient and reliable distribution of multicast packets.
For routers, that means dumping ASM and moving on to Bidir and SSM.

Routers have already done ASM, and things aren't moving forward.
Part of the problem is because of the nature of ASM.

I'm beginning to repeat myself so I'll see ya later.

---

From: John Zwiebel <[email-masked]>
Date: Mon, 9 Feb 2004 13:37:22 -0800

Bill: