Subject: [pim] Abt : PIM DM periodic nature

From: "Rajib" <[email-masked]>
Date: Mon, 19 Apr 2004 23:57:58 -0400

Hi,

I will be very happy if someone spare some time and give me some suggestions on the following issue.

As per PIM DM- 

Prune state has a finite lifetime.  When that lifetime expires, data will again be forwarded down the previously pruned branch.

In order to minimize repeated flooding of packets and subsequent pruning associated with a particular (S,G) pair, PIM-DM uses a state 
refresh message.  This message is sent by the router(s) directly  connected to the source and is propagated throughout the network.  When
received by a router on its RPF interface, the state refresh message causes an existing prune state to be refreshed.

1. My question is what was reason of  giving finite lifetime to Prune ? 

2. In the version 2 it was overcome by the state refresh message. It seems that version1 was wrong and version 2 corrects it without making any major change in the protocol. Why not any major change like the following ways-

What I am proposing-

1. There will be no periodic timer enable in any router except for the router directly connected to the source. I mean, when a router gets any data from it's directly connected  source (not from any other router) only then it will enable a timer for that particualar (S,G).

2.  When a particular (S,G) state is created in all routers after arriving multicast data. This (S,G) state for a particular source and group will not timeout and hence will not be deleted unless the router gets and proposed "Multicast session end" message from the router directly connected to the sender.

3. Pruned branches will never timeout. These pruned branches will only become active "Dense" when they get grafts.While the multicast session is in process.

4. When there is no (S,G) data (data for particular source and group) from the source to directly connected router, for more than a particular time (say 6  minutes) then this router will assume that the source has finished or discontinued the session and the router will flood the proposed "Multicast session end" message for particular (S,G) through out the network and all those particular (S,G) states in differnet routers will be deleted.

These make the protocol-

1. Very simple.

2.Makes the protocol suitable for both dense and sparse mode.

3. No unnecessary timers in routers.

4. No periodic flooding.

5.No concern regarding prune or any other thing time out. 

I know my proposal goes far away from PIM DM. But it is PIM DM based. Is it ok to use ? 

I will be very happy if you please let me know is there any problem with my proposal. 

Rajib Bashir

---

From: "Nicholas, Jonathan" <[email-masked]>
Date: Tue, 20 Apr 2004 09:46:26 -0400

Hello,

One problem with your proposal is it assumes reliable links. 

Suppose on a link a router sends a Prune(S,G) upstream and another router wishes to retain membership in (S,G) on that link.  If the responding Join(S,G) is not received by the upstream router and the upstream router's subsequent Prune(S,G) message is lost, there is no recovery.  Other failure scenarios can be conceived with similar consequences.

Beyond that, we really want to retain interoperability with existing implementations, which isn't really compatible with your proposal.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Rajib
Sent: Monday, April 19, 2004 11:58 PM
To: [email-masked]
Subject: [pim] Abt : PIM DM periodic nature

Hi,

As per PIM DM-

What I am proposing-

These make the protocol-

1. Very simple.

4. No periodic flooding.

Rajib Bashir

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************

---

From: "Rajib" <[email-masked]>
Date: Wed, 21 Apr 2004 03:40:30 -0400

Hi  John Zwiebel,

Thanks a lot for the discussion. I like to add following points.

I am not saying PIM-DM is wrong or anything like that but what I want to say

that, there was problem with PIM DM V1 regarding periodic flooding and that

was overcome by version 2, introducing " State refresh". But still version 2

faces some challenges. Even my proposal may also face many challenges now or in future. 

And the age of my idea is fairly 3-4 months, it is far away from being a

draft, let alone a "Standard" or any implementation. But I like to work on it.

When I am working on it, at first  I am trying to give it a basic structure. The

matter of "reliability" will come later.

 As you mentioned earlier -  "The fact that you may be able to save a few timers on

each router isn't that much of a save."

But I think it saves not only some timers but many other things-

1. In version1, there was a massive flood in every 3 minutes. It was

overcome by version2's  "state re-fresh" message that appears in every 60 seconds and

resets the clocks. But I think you have not noticed in version2 , in order to overcome a

periodic " massive flood" a new periodic " tiny flood" is introduced with the state refresh .

It may be a tiny flood but it is a flood. Now you can tell me that I have

also introduced a tiny flood with my "multicast session end " message. Yes,

I am also introducing a tiny flood like version2's "state refresh". But "multicast session end" 

will flood the network only 1 time, I mean when the multicast session  will be over. 

But version2's "state refresh" will create a tiny flood in every 60 seconds. 

So if  there is a 60 minute multicast session, version2 needs - 

1 (massive flood at the beginning) + 59 (tiny flood due to state refresh)

and for  my proposal, it needs-  

1 (massive flood at the beginning) + 1 (tiny flood at the end of session)

So, with the increase of session duration version2  faces overhead in terms of  number of tiny floods.

2. Now what happens if the number of (S,G) states increases ? Think that there are 70 (S,G) states in your network now.  

And all the sessions are of 60 minutes duration or greater.

Then  for a 60  minutes time period-   with version2 , your network will face- 

{1 (massive flood at the beginning) + 59 (tiny flood due to state refresh)}  x  70     numbers of  floodings. 

I think it is not a very small figure. And will make an overhead anyway.

But the network with proposed "multicast session end"  will face- 

1 (massive flood at the beginning) + 1 (tiny flood at the end of session) x 70   numbers of floodings. 

This is much smaller and tolerable.

So, again with the increase of number of (S,G) states version2 faces overhead.

So, you can  see that in version2 number of control signalling increases and still it is

"periodic" in "true sense". Although it overcomes the problem of massive flooding in every 3 minutes. 

While with "multicast session end" it becomes "non- periodic" in "true sense".

3. Thirdly, when there will be no periodic timers, definitely it will create

less processor load. A router may be associated with  70-80 different (S,G)

states and if there is one timer for every state, definitely it will cause

too much processor load.

4. You also mentioned about some other bugs, thanks a lot for those. As I have

told earlier, I have not worked on the reliability issues yet, but one thing

I can tell you, most of them will be overcome when I will introduce

acknowledge messages with the control messages like Prune, graft and

others, specially with  proposed "multicast session end" message. When

there will be acknowledging messages associated with these control messages

surely the reliability will increase.

5. Finally, it is very simple and it is "PIM - DM" based. 

Really, the discussion with you and others are helping me  a lot to

understand the whole thing .

Thanks again.

Rajib Bashir

Graduate student

Concordia university, Canada.

----- Original Message -----
From: "John Zwiebel" <[email-masked]>
To: "Rajib" <[email-masked]>
Cc: "Nicholas, Jonathan" <[email-masked]>; <[email-masked]>; "John
Zwiebel" <[email-masked]>
Sent: Tuesday, April 20, 2004 6:35 PM
Subject: Re: [pim] Abt : PIM DM periodic nature

On Apr 20, 2004, at 1:15 PM, Rajib wrote:

> Hi Nicholas,
>
>
>
> Thanks a lot for your suggestion. But I am not very clear about what
> you have mentioned. May be I have misinterpreted. So, can you please
> describe me the problem with a diagram or any other way?
>
>
>
> Yes, I am considering reliable links as it is only at the early stage.
> But can you please also suggest me any recovery for the problem you
> mentioned. Can I implement acknowledge messages for every Prune
> and Graft to overcome this problem?
>

Raib:

You can do what you want, but consider that you have not included a
proposal
for unreliable links so no one else is going to implement your
suggestion until
you do.

FWIW: many people have spent a lot of time with state-refresh and
dense-mode
and even so, there are many PIM implementations which do not support
dense-mode at all.
And of those that do, it isn't clear that it is in wide general use.

So, then there is a subset of those few systems that do support
dense-mode which support state-refresh.  (ie, not everyone does)

My point is that you are proposing interoperability problems and/or
configuration problems.

saying that version 1 was 'wrong' would be incorrect, it was an
implementation choice.  State-Refresh appeared to offer benefits
but AFAIK, was never widely deployed so that those apparent benefits
could be studied.  version 1 worked and was "good enough" for a while.

Likewise, PIM-SM (ASM) is "good enough", but after it was widely
deployed, many problems started showing up in the interdomain space,
which
is why we have defined SSM and Bi-Dir PIM.  One can't say that PIM-SM
was "wrong".

WRT point 1: what happens when the first-hop router fails?  No
   "session terminated" message will be sent so (S,G) state will
   never be timed out in the downstream routers.  If you want to
   overcome this with a timer, then what is the advantage of your
   proposal.

WRT point 3:  How does the host signal the last-hop which
   specific (S,G) it is interested in listening to?  If the host
   already knows the (S,G) and it sends an IGMPv3 host report,
   what is the advantage of having pruned state in the last-hop
   since this sounds a lot like SSM to me.

WRT point 4: How do you reliably signal the session end message
   all the way down the tree?  The upstream routers would have to
   get an ack back from each of the downstream routers, ie every
   PIM neighbor.

How do you decide which upstream router will send the 'session
terminate' message on a LAN that has determined the forwarder
via the assert process?  Is it OK that 5 upstream routers send
such a message?  Does the downstream router have to receive a
"terminate" from every upstream or is any upstream router
"good enough"?

WRT making the protocol suitable for both sparse-mode and
dense-mode, I don't think so.  Sparse-mode wants to instantiate
state in only those routers where it is required.  Dense-mode
creates state in every router in the domain.  in the case of
the Internet, that could mean every router in the world.

Dense-mode with state refresh already deals with the periodic
flood-and-prune problem that was in the original Dense-mode spec.
The fact that you may be able to save a few timers on each router isn't
that much of a save.

2cents

>
>
> Rajib
>
> Graduate student
>
> Concordia University, Canada
>
>
>
> ----- Original Message -----
>  From: Nicholas, Jonathan
> To: Rajib ; [email-masked]
> Sent: Tuesday, April 20, 2004 9:46 AM
> Subject: RE: [pim] Abt : PIM DM periodic nature
>
> Hello,
>
> Suppose on a link a router sends a Prune(S,G) upstream and another
> router wishes to retain membership in (S,G) on that link. If the
> responding Join(S,G) is not received by the upstream router and the
> upstream router's subsequent Prune(S,G) message is lost, there is no
> recovery. Other failure scenarios can be conceived with similar
> consequences.
>
> Beyond that, we really want to retain interoperability with existing
> implementations, which isn't really compatible with your proposal.
>
> Jonathan Nicholas
> Network Systems Engineer
> Prune state has a finite lifetime. When that lifetime expires, data
> will again be forwarded down the previously pruned branch.
>
>
>
> In order to minimize repeated flooding of packets and subsequent
> pruning associated with a particular (S,G) pair, PIM-DM uses a state
> refresh message. This message is sent by the router(s) directly
> connected to the source and is propagated throughout the network.
> When
> received by a router on its RPF interface, the state refresh message
> causes an existing prune state to be refreshed.
>
>
>
>  2. In the version 2 it was overcome by the state refresh message. It
> seems that version1 was wrong and version 2 corrects it without making
> any major change in the protocol. Why not any major change like the
> following ways-
>
>
>
> What I am proposing-
>
>
>
> 1. There will be no periodic timer enable in any router except for the
> router directly connected to the source. I mean, when a router gets
> any data from it's directly connected source (not from any other
> router) only then it will enable a timer for that particualar (S,G).
>
>
>
> 2. When a particular (S,G) state is created in all routers after
> arriving multicast data. This (S,G) state for a particular source and
> group will not timeout and hence will not be deleted unless the router
> gets and proposed "Multicast session end" message from the router
> directly connected to the sender.
>
>
>
> 3. Pruned branches will never timeout. These pruned branches will only
> become active "Dense" when they get grafts.While the multicast session
> is in process.
>
>
>
> 4. When there is no (S,G) data (data for particular source and group)
> from the source to directly connected router, for more than a
> particular time (say 6 minutes) then this router will assume that the
> source has finished or discontinued the session and the router
> will flood the proposed "Multicast session end" message for particular
> (S,G) through out the network and all those particular (S,G) states in
> differnet routers will be deleted.
>
>
>
>
>
> These make the protocol-
>
>
>
> 1. Very simple.
>
> This email and any files transmitted with it are proprietary and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email
> in error please notify the sender. Please note that any views or
> opinions presented in this email are solely those of the author and do
> not necessarily represent those of ITT Industries, Inc.
> The recipient should check this email and any attachments for the
> presence of viruses. ITT Industries accepts no liability for any
> damage caused by any virus transmitted by this
> email.

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

---

From: "Rajib" <[email-masked]>
Date: Wed, 21 Apr 2004 03:40:30 -0400

Hi  John Zwiebel,

too much processor load.

Thanks again.

Rajib Bashir

Graduate student

----- Original Message -----
From: "John Zwiebel" <[email-masked]>
To: "Rajib" <[email-masked]>
Cc: "Nicholas, Jonathan" <[email-masked]>; <[email-masked]>; "John

Raib:

2cents