Re: PIM : detecting duplicate packet

John Zwiebel <[email protected]>
Newsgroups gmane.ietf.magma
Message-ID <[email protected]>
On Dec 9, 2006, at 9:27 PM, tajay wrote:

> Hi,
> Most of the opimization algorithms in PIM depends on detecting  
> duplicate packets.
> e.g
> (1) sending register stop once RP starts receiving duplicate packets
> (2) DR @ source sends prunes (S,G) from RPTree whenever it receives  
> duplicate
> packets from source.
>
> Is there any specific way to identify duplicate packets? And how  
> feasible it
> is to detect duplicate packets at very high rate traffic?

To correct a slight misunderstanding, it isn't "duplicate" packets  
that are
being detected, but the arrival of packets on an alternate network  
path.  It is
'assumed' that this will ensure there is no loss of data when  
switching from
the RP-tree to the shortest-path, or from pim registration to the  
shortest-path.

And you have #2 wrong, it isn't the DR at the source, but it is the  
last-hop router,
which may or may not be the DR, that joins to the spt.

To be honest, it has never been clearly shown that the complications  
of such
a data-path switch are really useful.  In fact, some applications  
have been
shown to croak (or at least not handle well) reception of duplicate  
packets.

You might consider:
   -- On the last hop router, as soon as receipt of a mpacket down  
the shared-path
	creates (S,G) state, immediately sending (S,G,R) prunes while at the  
same
	time sending (S,G) joins for the SPT.  You will lose some mpackets, but
	your application probably hasn't had the chance to figure out that  
there
	really is data available.

   -- On the RP, as soon as a PIM-register is received sending a  
register-stop at the
	same time you send an (S,G) join.  Again, you will lose some  
mpackets, but
	it hasn't been shown that applications would recognize this loss.

These two suggestions do not comply with the PIM RFC.  Its your  
choice whether or not
you think its important enough.

z
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.